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 fostering their version of 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. 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 and Lean. Many Agile practitioners don’t like how a lot of 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 Not the best solution for every problem
Agile is best suited to solving certain types of issues. 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 to which Agile is best-suited.
| CONDITIONS | FAVOURABLE | UNFAVOURABLE |
| 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 relatively simple. The Agile Manifesto has only four lines of text, and there are only 12 Agile Principles. The Scrum Guide can be read in under an hour as it is only 16 pages long. But while the concepts and ideas are relatively simple to understand, implementing them can be exceedingly tricky, 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. 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 more rapid 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, there can be some downsides, at least in theory. For example, completed may subsequently have to be refactored in a later time due to changing requirements. Theoretically, in a Big Design Up Front (BDUF), all the various permutations would have been factored in at the start so that refactoring isn’t ever required. It is also arguable that each iteration includes overheads in repeating tasks (such as testing, management and deployment) which in total may outweigh the effort required if the functions were performed just once for a larger piece of work.
#5 Agile is not for everyone
Agile teams are high-performing, self-organising teams which operate 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. Rather than discourage you from adopting Agile practices, the intention has been to verify 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.
