I’m seeking feedback on the following comparison of agile vs waterfall(*) The comparison is to be used as background information for a panel discussion on agile contracts, so it emphasizes those aspects which I felt were most relevant to that topic. I’ve tried to keep it agnostic as to the exact flavour of agile to be used.
|Requirements always identified up front||Requirements may be identified up front, in a concise list|
|Users sign off documents||Users try out the software regularly|
|Integrate and stabilize at end||Integrate and stabilize frequently|
|Progress is measured by milestones||Progress is measured by % complete (with continuous testing)|
|Reduce likelihood of bad predictions through planning & signoffs||Reduce impact of bad predictions though fast detection & response|
|Value: delivering on promises||Value: openness|
What are your thoughts? I’m particularly interested in your thoughts on the second-to-last line, about the approach to “bad predictions”. Does that make sense as it stands? Do I need to add text explaining that I’m talking about all kinds of predictions – not only how long things will take to build, but also what should be built?
(*) Yes, I know, presenting agile and waterfall as opposites is logically flawed, since there’s no “opposite of agile“. But we need something as background/context for the panel audience.