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.