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.
The list looks good. However I don’t like comparing *agile* with *waterfall* because they are apples and oranges. Agile is a mindset or an approach to development whereas waterfall is a methodology. So we can meaningfully compare waterfall with, say, scrum or crystal. To compare Agile with something different, I’d choose a “plan centric mindset/approach” – whereas agile is (to me) a change centric approach. And, in agile, progress shouldn’t be measured by %age complete. Progress should be measured by “how much working software do we have in production”. IMHO until we have software in production, we have made no progress. I’m slightly more extreme than Ron Jefferies! https://ronjeffries.com/xprog/articles/jatagileisisnotmaybe/
Hi Tim, Thanks. Good points about which comparisons make sense. I think the panel audience will be interested in the comparison of “how do teams typically behave” (particularly in those aspects of behaviour with obvious relevance to contracts). Re your second point, could you define “complete” as “in production” 😉 Doesn’t work for all teams though. I think there are valid cases for “big bang” deployment of agile products (e.g. replacing an existing system where its not practical to run both systems together with gradual transfer of functionality) and in those cases I’d use “ready for production” as my definition of done.