July 7, 2015 | John Rusk | 2 Comments 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. Waterfall Agile 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.