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.