All developers, project managers, scrum masters, product owners, or anyone who is planning on using agile within an organisation that has previously used a waterfall SDLC needs to view this talk by Mitch Lacey.
In his talk from the Agile 2008 conference he shares candidly about a real life project that was on the verge of being successful, but was deemed as unsuccessful by the customer. Considering that “the true measure of project progress is working software”, Mitch and his team delivered the software, but the client was not satisfied.
Important issues of clarity, understanding, trust, openness, authenticity and honesty really come out in this talk.
Significant early warning signals were not taken seriously by the development team, e.g. business requirements were not defined early enough, and the statement of work took ages to get signed. Also the case study shows how even with good data on burn down, backlog, etc may not assist in clarity.
Clearly the business did not understand the commitments that they were undertaking by agreeing to the use of agile methods. Business product owners were not taking on the role required of them according to the Scrum development method – there was no clear executive level product owner with a wide overview of the end-to-end process. There was a lack of clarity on formal approval processes for outputs.
The business did not understand the agile development process they signed up for – their clear expectation was for a waterfall type process. As with most IT project failures the requirements definition process is the foundation for a project, and poor foundations tend to lead to poor outcomes.
I’ve seen the same thing several times now and am quite sceptical that agile is even possible (let alone desirable) for some businesses. Many businesses seem to think that agile really means ad hoc. With every ad hoc change cost is added to development and with enough ad hoc changes the project tends towards anarchy.
[HT: @mkrigsman for his excellent discussion of this talk on ZDNet that alerted me to Mitch’s talk]
Aide Mémoire 
I completely agree, agile IS 95% misunderstood. Even by expert project management practitioners.Used well, with the right people in the team (including business owners) and for the right project, it is a very powerful way to build something new.If you’re building something that’s been done a thousand times before, maybe a full waterfall or even a front loaded agile then waterfall hybrid may be in order. (Using agile to get the requirements down, then waterfall to deliver).I’d challenge anyone who says agile is perfect for any project. Its another tool just like any other.That said, I am a huge fan of agile, having managed many projects using it. But I just want to express caution at the decision making point in time. Use the right tool for the job. Or the job can make a right tool out of you.
LikeLike
Andrew and I kicked this around 18 months ago. Basically you need to make a choice based on your current cultural, business and technical constraints.Ain’t no such thing as a magic wand and that’s why we get paid the big bucks — to make intelligent decisions. Can’t do that you should be fired.
LikeLike