One overlooked aspect of agile is that it fails well. People tend to talk about this obliquely referring to the feedback mechanism as being an important part of the agile process. I suspect the reason is that people do not like to talk about project failure when discussing agile; because, they want to give the idea that agile is somehow innoculated against failure. I believe that agile is instead better at reducing the damage of failure and increasing the chance of recovery from the failure. The goal in agile is to fail fast, when you can still react positively to that failure. Now I would agree that ‘agile engineering processes’ (really just ‘good enginnering practices’) can help reduce the chance of failure, but no project is immune to failure or atl least being considered challenged.
Consider a project that requires six man-months to deliver. Let us presume, for the purpose of argument that this is two months each of analysis, development, and testing regardless of our decision to use a waterfall or agile approach. Under a classic waterfall model we would plan this as two months of analysis, followed by equal periods of development and testing. Under a classic agile model we might plan this as twelve iterations of two weeks. Now assume that we are going to uncover an architectural problem during QA that we do not see in developer testing. Under the waterfall approach the earliest we are going to learn about this would be 4 months into the project when we begin testing. More likely we might find it 5 months in or later. Under an agile project we might find this within two weeks. This is especially true if we plan our iterations with an early release targetted as walking skeleton (Lean calls this a spanning application and the Pragmatic Programmers a tracer bullet). If we had opted for an initial walking skeleton release with agile iterations we could have flushed out architectural failures early.
If I fail within say six weeks as opposed to within five months I dramatically increase my range of options. I could decide to abandon the project. Because my sunk costs are probably lower my capacity to walk away improves.
Early failure is positive for more than just avoiding waste here. It is useful because it modifies my perception of risk. Because my risk is lower I may feel more able to make the decision to begin a project, so I may spend less on ‘due diligence’ up front, increasing my ability to sieze market opportunities. I also have much more ability to assess what is wrong, re-plan and re-commence, because telling the customer this far in advance of any delays or increased costs gives them much more ability to react. Especially if the customer knows that I am trying to get the suprises out of the way up front.
Kent Beck said in an interview with ComputerWorld
No. I think software projects are still going to fail because there
still [will be] the promising ideas that don’t work out in practice.
One thing that agile development can give you is to make sure those
projects fail faster, sooner, cheaper, so you can get on with the next
thing
