I had a conversation today regarding the relative merits of waterfall and agile software project lifecycles from the perspective of project risk over time. The challenge to me, as an agilst, was to defend agile under conditions that seem to favor waterfall. The situation is set up as follows:
- requirements can be specified clearly in advance,
- architectural risk is low,
- team is highly skilled.
In such a situation the argument is that, by doing all the requirements early, 'gotcha' requirements will be identified and dealt with more quickly, leading to an overall reduction in risk. The low architectural risk means that up-front design is likely to be correct at the first pass. Implementation, verification, and deployment are handled by the "highly skilled" team. Graphically, this risk vs. time graph looks like the following:
The lower line is the one we are to believe true. But, I believe the top line is more likely. Risk remains very high from an outside perspective. Prior to verification, no testing is done and the client will have very little confidence that any requirements, design, or implemented functionality is actually complete. The agile notion of "Done" isn't achieved until everything is delivered at the end.
As a comparison, here is how an agile project's risk graph may look:
Risk is reduced rapidly during the initial iterations. then drops slowly as the full functionality is delivered. I think the early risk reduction can be attributed to things like: (1) every phase of the development cycle, including deployment and test, are completed early, (2) high risk requirements can be tackled early, leaving lower-risk items for later, and (3) a credible, working system is delivered to the client as early as possible. From the client's perspective, I would argue that the agile risk reduction early on is a major benefit, even if we were to assume the optimistic line in the waterfall graph.
And remember, these graphs are working under the assumption that both teams will deliver on time, and that requirements can be completely specified up front. I think that as we relax these assumptions to more realistic conditions, the agile graph will only look better in comparison.