I’m always interested in hearing about Agile projects that have failed. So, what do I mean by fail? An overly simplistic answer might be, failing to deliver on release commitments. In other words, customers and stakeholders have an expectation of your team to deliver X, and you end up delivering Y. Not simply a scope change, but something completely different than what was expected. Or perhaps there is a definitive release date and the team fails to meet it. I have encountered many reasons for Agile project failure: lack of people, lack of commitment, unexpected risks, failure to manage dependencies, etc. Arguably however, the most egregious is the failure to embrace the organizational and culture changes of the Agile Manifesto and principles. Many companies believe that simply doing the mechanics of an Agile methodology, such as Scrum (e.g. daily planning, demos, retrospectives, sprint planning, etc.) is all that is needed to be Agile. I submit that doing the mechanics of Scrum, doesn’t make your project Agile. What makes a project Agile is adherence to the principles and values of the Agile Manifesto.
To further illustrate my point, I present the following true story. Names are removed to protect the incompetent:
COO: You suggested we try using Scrum, however we’ve tried it before and it didn’t work for us.
Me: That’s unfortunate but interesting, I’d like to hear more. What happened?
COO: Well, one of our teams read some books on it, then tried to implement it for a couple of days. During that time, we didn’t observe any improvement, meanwhile the rest of the project fell behind.
I wish I could say that the last sentence was the punchline to a joke, but as mentioned previously, it is a true story. More commonly, when I hear about Agile projects that have failed, the methodology being used (FDD, Scrum, Kanban, etc.) is blamed for causing projects to fail; when in reality, the Agile methodology being used is merely exposing existing problems. Thus Agile is blamed for project failure due to the problems it caused.
As a coach, I try to set the expectations that Agile is similar to a spotlight: it is going to expose problems you didn’t even know you had. In addition, simply using an Agile methodology won’t solve your problems. True, Agile methodologies will give you some tools to help you solve the problems (e.g. retrospectives), however you won’t get the benefits of Agile unless you take action and solve the issues that have been exposed.
Agile Business Connect 
The most critical factor to help increase the probability of success in customer/end-user engagement. This should be driven by the PO. They should be at every Sprint Review engaged with the product and the Scrum Team. In addition, a good Definition of DONE to ensure quality practices and a set of 3-5 prioritized OUTCOME goals. Outcome goals define the time-based, measurable goals that will be achieve after the features are in the hands of the end-users.
As for your scenario…no process will cover that level of ignorance. That project is destined to fail due to a lack of leadership.
The one reason I have found for Agile failure is the stakeholders cannot understand 100% what they’re buying into. They want a white paper/requirements document regardless of the amount of inaccurate data, if they don’t have that, they can’t buy into it. I figure it’s a learning curve, but have somewhat been trumped in these circumstances with people wanting a lot of information up front. Overhead understood.
What do you mean by “Agile”? If they don’t embrace the Agile manifesto and principles, how is it an Agile failure? As Lincoln was fond of saying, “If you call a tail a leg, how many legs would a dog have? Four; calling it a leg doesn’t make it a leg.”
Reblogged this on and commented:
Joe Vallone, has been consulting for Eliassen Group as an Agile Coach at one of our Enterprise Transformation Clients for the past two months. Joe has been working in Scrum and XP environments since 2002. He is a Certified Scrum Master, Certified Scrum Professional, and has has helped several large and small companies make their transition to Agile methodologies.
I agree most with trudelle’s comments. Calling it agile does not make it agile. As a veteran of some 3000 agile projects, unless you get buy-in from the top, it’s hard to try to push your business partners to participate fully. Continuous training at the front-end of all agile projects allows newbies to be indoctrinated to the approach. I would also suggest that at the start of adoption, that all agile projects be time-boxed to the same timeline; it removes timing issues for operations/readiness, it establishes clear goals, it commits staff to a timeline; it clearly establishes budget constraints — all of these are tactical issues that can side track agile adoption. By controlling many of the outside impacts and potentials for issues, you can focus on getting folks up to speed and working the user stories/use cases/tasks at hand.
Clearly this is a little simplistic, but wanted to get the ideas across efficiently.