Agile projects don’t run late
Agile projects don’t run over budget
Agile projects don’t have bugs
Agile projects don’t deliver the wrong thing
Agile projects don’t end up just not working
Agile projects do get smaller.
In most software projects there are many things can go wrong. Development taking too long, bugs, features that don’t quite fit the legal requirements. The list is surprisingly long and often feels endless. There are just so many risks to balance, and trade off with each other. It is no wonder that very few projects have a clear handle on their risks, and possible mitigation. This is a root cause of failure for many projects.
When working with agile, there are fixed dates for the end of each iteration, and often a fixed number of iterations. If a project is running behind, less has been done by that date. The timeline normally equates to budget, so the same argument holds. A similar argument applies to bugs. They require time spent fixing them, which is time not spend adding all the features planned for a given iteration. In fact there is a similar argument for anything that can go wrong. Building the wrong things results in time being spent to change it – meaning less is done by the end of iteration.
In an agile project any number of risks get transformed into exactly one risk. That the scope decreases. This is much easier to manage as it leads to a simple binary question.
Has the scope decreased to the point where there is no longer any value in continuing?
Let me be very clear here. I’m not saying that agile reduces the risks in a project. What it does is change them into something that is easier to understand. This makes it easy to communicate. This will make it much easier to have the difficult conversations.
