It had to happen sooner or later — as much as the Agilistas want to paint a picture of fuzzie bunnies, and shiny happy developers, now that more companies have considerable experience with agile and scrum, they are more than anxious to rid themselves of it.
What’s even better, more people are coming out and telling it like it is, versus being suppressed by agile propagandists and apologists.
A sample of recent blog postings along these lines:
In http://www.impermium.com/blog/breaking-free-from-the-cult-6-reasons-why-agile-doesnt-work/ Talia mentions the following:
“Velocity” is a unicorn. Things are never the same from sprint to sprint: there’s a holiday in the middle, someone takes a vacation, or gets pulled into debugging production issues. Even if everything else were perfect – spot-on estimations and no mid-sprint requirements – you still wouldn’t be able to accurately compare productivity from one sprint to another.
In http://cio.co.nz/cio.nsf/focus/why-agile-isnt-working the author mentions:
The second flaw, development over planning, hits the agile principle of “responding to change over following a plan.” In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes.
Every change has a cost, but agile does not account for this. The result? People often change really big things late in the game using the rationale that since it’s an agile project, it can handle it. The only way the project can handle this is by adding iterations. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.
This principle encourages poor and irresponsible planning while hiding its effects. As iterations continue and the defect list grows, the customer becomes more frustrated-not only because of the lack of quality, but because delivery expectations aren’t being met either. This is much different from more traditional practices, where you have a project based on well-defined requirements and changes are managed through a Change Management process-which, while sometimes byzantine, will at least state time and monetary costs more clearly.
“There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process.”
“Sometimes that “Agile means disorganization” mindset encourages users and clients to interpret the process as “It’s okay to be capricious.” Yes, Agile does permit users to swap priorities even towards the end of a big project. But developer Sorin Costea observed the downside when things worked smoothly: “These users could not believe there are also limits to the delivery power. They could not really grasp velocity or timeboxing, but expected to throw in stories any moment and also get them in time.” With the reasoning that, “Hey, we are Agile aren’t we?”
http://blog.assembla.com/assemblablog/tabid/12618/bid/87899/Seven-Things-I-Hate-About-Agile.aspx is a well known post and definitely worth a read, as is http://lostechies.com/jimmybogard/2012/09/12/why-im-done-with-scrum/