The principle of “responding to change over following a plan” is considered by many as a strength of agile. But some consider it to be a flexibility that can’t work in practice. They have seen agile projects that had difficulties managing changes and customers who expected too much flexibility, leading to project delays, quality problems and teams that had difficulty delivering value. Can agile not live up to its promises, or is it the way that teams and organizations have adopted agile that is causing the problems?
In the article why agile isn't working on CIO.com, Lajos Moczar states that he thinks the agile methodology is flawed:
Agile promises many things, but the reality in the field is often very far from the expectations.I've concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT.
One of the flaws he discusses is “development over planning”:
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 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.
Shane Hastie reacts on the article from Lajos in his blog post please don’t equate tragile with agile:
The author misinterprets the agile manifesto and takes some of the agile practices completely out of context, using unfounded statements to justify his conclusions. This post is my response, addressing the points he makes and tackling the myths he propagates.
He reacts on the flaw “development over planning” that Lajos mentioned by explaining the problem he sees with up front defined requirements and change management:
The reality of the business environment today is that business needs are volatile. The “half-life” of a business requirement today is approximately 6 months, so if you’ve identified what is needed and it takes 12 months to deliver it then 75% of what was asked for will be wrong, purely because of the passage of time.
Agile addresses the needs of customers in a disciplined and careful way, and doesn’t oppose to planning as Shane explains:
Agile is not an excuse to ignore good design principles, nor to allow massive change without doing impact analysis. Agile is about adapting within boundaries, and recognising that when change is so large that it impacts the business value of the project then it needs to be assessed and evaluated, but not resisted.
There is nothing in the agile manifesto about not planning the overall structure of the product from the beginning, and certainly none of the respected authors and thought leaders in the space recommend starting to write code “like free form poetry” – any project needs SOME design up front, and in agile projects we resist BIG design up front because we know that the world will change around us.
The article why your users hate agile development (and what you can do about it) by Esther Schindler on ITworld talks about the different views that developers and users can have of agile. One of the difference she discusses is “you say iterative, they say disorganized and never-ending”:
Early in Agile's history (…) many shops saw Agile as an excuse for development teams to avoid providing estimates, documentation, and plans. Things are far better, nowadays, but I'd argue that these bad reputations lurk far longer than we prefer -- even in the development community itself.
Agile teams often try to be as flexible as possible towards the needs of the users, but users might expect too much from this flexibility, making it difficult for teams to keep on delivering value:
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?"
Corbin Norman blogged about acknowledging the common good of agile: praising the good of agile and abrogating the minuscule negativity it brings. He recognizes how people sometimes have a negative view of agile:
Critics of Agile say this development methodology is making things worst for some software people by promising solutions it cannot deliver and displays a habit of promoting sloppy requirements, hiding true cost of development and preventing effective management. Their argument is the latter leads to long-running projects, dissatisfied customers and an overall IT ineffectiveness.
Today, there are quite a few arguments to be made on both sides for the practice of agile development but the community should take notice to the amount of good Agile is doing rather than the minuscule negativity it brings.
According to Corbin, one of the good things from agile is it’s flexibility:
With Agile, schedule and cost are the major determining factors and it is scope that changes in order to accommodate acceptable business demands…the client’s needs. For mature Agile teams, this level of flexibility is brought about by years of experience working together. Traditional Waterfall won’t allow this level of flexibility once a project is underway since it strictly adheres to the concept that once a stage/process has ended, one cannot go back to adjust.
