Saturday, March 24, 2012

Waterfall versus Scrum: How do they compare?

I have recently been asked for advice on how to compare Waterfall (WF) and Scrum.  This is a hard question in some ways: the best way to compare will depend on the person you are talking to.  Another problem is that few people do 'pure' waterfall in actual practice. And the variations of Waterfall are many.

Still here are some thoughts that occur to me.  We think these statements often need explanation, but they can be useful as a start for a discussion, eg, 'should we move from waterfall to Scrum?'


Scrum has a prioritized Product Backlog, from which one could execute the Pareto Rule.
WF tends to assume the 100% - 100% rule.   And tends to order the building mainly by technical dependencies or by what the geeks want to do first.

Scrum uses adaptive planning.
WF tries to keep to the initial plan.

Scrum gets feedback from working software early (first sprint, in 2 weeks) and often.
WF does not have working software until very late in the cycle.

WF assumes we know 'everything' upfront.
Scrum assumes there is lots we don't know (yet), and focuses on maximizing learning throughout the project.

WF tries to minimize change (change control board).
Scrum tries to maximize the benefits of good change (eg, learning).

Scrum assumes change is normal, often good, and anyway much of it can't be controlled usefully.
WF assumes change is bad and can be controlled.

WF puts most responsibility on the PM.
Scrum puts most responsibility on the small dedicated Team.
(WF uses a diffuse work group, with only the PM with serious responsibility.)

WF assumes the PM should plan the work.
Scrum assumes it is best if the Team plans its own work and re-plans.

WF prefers 'planning from the center' (e.g., by the PM).  And the workers just execute what they are given.
Scrum prefers more self-organization, and using the full 'complex adaptive system' (a tight thinking adaptive Team).

Scrum optimizes business value, time to market and quality.
WF optimizes conformance to schedule and budget.

WF's typical problem is analysis paralysis and being late. Scrum addresses these.
People using Scrum often err in not thinking quite enough easier problem to fix.

When people do WF they typically are thinking: "If I just follow the process and the plan, all will be well."
Scrum tries to force the Team to think for themselves, in their specific situation. Hence, it is a bare framework of things that are essential for every effort. Always other things, in addition to Scrum, must be done.

WF has weak controls (eg, conformance to schedule).
Scrum has strong and frequent controls (e.g., did you all get all those features done this past 2 weeks?)...which enables faster improvement.

Waterfall only allows realisation of value only upon completion.
Scrum supports realisation of value earlier, potentially after every sprint.

Unprofessional people often say they are doing 'Scrum'.  Above we are talking about vigorous professional Scrum, not 'cowboy Scrum' or ScrumButt.

Good people forced into WF typically use agile-scrum ideas to make it really work.  Above we are talking about 'true' Waterfall. While 'true' Waterfall rarely exists, we think that one can still see that the ideas and practices of Waterfall, as much as they remain in real practice, impede progress.

Final comment: I am not convinced that these are all the statements one could make. Also, please don't assume I have all the top 5 best comparison statements. Your feedback is very welcome.

No comments: