Every software development process is subject to plenty of criticism. Agile methods are no exception.
Regrettably, in most situations where a methodology “failed”, the people following it cut corners. They adopted some but not all of the core ideas. Failure risk always increases when you do that.
At times, people take things too literally. Or perhaps they have selective memory whereby they remember and take advantage of the some of the elements of a process and disregard the rest.
For example, the Agile Manifesto says “Working software is the primary measure of progress.” Does that also imply that documentation, training, data analysis and design are meaningless?
Or consider this agile principle, “The best architectures, requirements, and designs emerge from self-organizing teams.” Does that imply that managers don’t matter? Should the developers be allowed to do whatever they want?
Get serious. The 12 principles behind the Agile Manifesto must be taken in their entirety. They are intended to be consumed holistically. You don’t get to pick and choose the principles you like best.
Agile development really works — when you follow ALL the guiding principles.
There is another perspective on this issue at IBM developerWorks in an article by Scott Ambler called “Agile Reality over Rhetoric”. Take a look.