Five Inconvenient Truths about Agile

Five Inconvenient Truths about Agile

It probably won’t come as any surprise that I like Agile. I’ve been using it for many years now and I’ve come to appreciate many of the nuances built into the approach that aren’t immediately obvious on first glance. I find it to be an especially powerful approach to new product development. But like many new tools and practices, Agile has been over-hyped and promoted as a “silver bullet”, particularly by the Agile zealots around, many of whom have a vested interest in promoting Agile as they drive a substantial income from Agile consulting and training. I see myself as an Agile enthusiast rather than an Agile evangelist because I don’t believe that Agile is the solution to every problem. In an effort to balance-out this hype, I am going to present five of the most inconvenient truths about Agile.

#1 Agile is Scrum

Agile is an umbrella term, covering many different practices including Scrum, DSDM, XP, Crystal, Kanban, Lean and so on. Many Agile practitioners don’t like how a lot if people think that Agile is only Scrum, and there is a lot more to Agile than just Scrum. However the reality is that for the majority organisations Agile does only mean Scrum. In the most recent State of Agile survey, 68% of respondents reported that they used Scrum or a Scrum/XP combination, so that means that for two out of every three Agile organisations, Agile = Scrum.

#2 Agile isn’t the best solution for every problem

Agile is best suited to solving a certain types of problems. It is not a panacea that can, nor should be, used to solve all problems. In their article Embracing Agile for The Harvard Business Review, Darrell K. Rigby, Jeff Sutherland and Hirotaka Takeuchi provided the following table to help identify the type of projects that Agile is best-suited to.

Market Environment Customer preferences and solution options change frequently. Market conditions are stable and predictable.
Customer Involvement Close collaboration and rapid feedback are feasible.

Customers know better what they want as the process progresses.

Requirements are clear at the outset and will remain stable.

Customers are unavailable for constant collaboration.

Innovation Type Problems are complex, solutions are unknown, and the scope isn’t clearly defined. Product specifications may change. Creative breakthroughs and time to market are important.

Cross-functional collaboration is vital.

Similar work has been done before, and innovators believe the solutions are clear. Detailed specifications and work plans can be forecast with confidence and should be adhered to. Problems can be solved sequentially in functional silos.
Modularity of Work Incremental developments have value, and customers can use them.
Work can be broken into parts and conducted in rapid, iterative cycles.Late changes are manageable.
Customers cannot start testing parts of the product until everything is complete.

Late changes are expensive or impossible.

Impact of Interim Mistakes They provide valuable learning. They may be catastrophic.

#3 Agile is difficult

Agile concepts are fairly simple. The Agile Manifesto has only four lines of text, and there are only 12 Agile Principles. The Scrum Guide is only 16 pages long and can be read in under an hour. But while the concepts and ideas are relatively simple to understand, implementing them can be exceedingly difficult, especially in companies which have long-established legacy processes and a non-Agile culture. The Standford Group has been surveying IT project success for over 20 years and while their data shows that Agile provides a definite improvement over traditional (waterfall) project management, perhaps the most sobering statistic from them is the fact that 23% of large Agile projects are still unsuccessful! So don’t be fooled. Agile is simple, but not easy.

#4 Agile may not be faster

Many people mistakenly think that Agile means faster delivery, but Agile approaches generally optimise for Business Value – the focus is on delivering the highest Business Value first – rather than for speed of delivery. An Agile process for delivering business value is generally incremental in nature, allowing for the placing of “small bets” during an increment, and for changing of requirements of a subsequent increment based on the result of the previous “small bet”. While an incremental approach has many benefits, one increment may often require rework (refactoring) of already completed work; effort that theoretically wouldn’t have been required under a BDUF (Big Design Up Front) approach, where the various permutations had been factored in at the start. It is also arguable that each iteration includes overheads in repeating tasks (testing, management, deployment etc) which in total may outweigh the effort required if the tasks were performed just once for a larger piece of work.

#5 Agile is not for everyone

Agile is based on high-performing, self-organising teams operating in an environment of trust and autonomy. These last two factors mean that teams, and the individuals within them, must take a much higher level of responsibility then they may have done in the pre-Agile world. The (sad?) fact is that many people don’t want to take this level of responsibility, or to work in such a highly-collaborative manner. Many software engineers, for example, like to work on their own and within clearly defined boundaries, boundaries specified by someone else. So while there are plenty of people who love working in an Agile manner, there are also plenty who don’t.

Choose the right tool for the problem

So there you have it, five inconvenient truths about Agile. These are not meant to discourage you from adopting Agile practice but rather to get you to confirm that the problems you are trying to solve with Agile, are the type of problems that Agile is best-suited to solving. Do you agree with my list, or not?  Let me know. Also feel free to let me know if you have any other inconvenient truths about Agile.


+ There are no comments

Add yours