Scrum vs Waterfall : How do they Compare?
Scrum vs Waterfall
I have recently been asked for advice on how to compare Waterfall (WF) and Scrum VS Waterfall. 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 in Scrum vs Waterfall. 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 (mainly by Business Value), from which one could execute the Pareto Rule.
WF tends to assume the 100% – 100% rule. And tends to order the building of the product 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 (every sprint).
WF does not have working software until very late in the whole dev 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 (a change control board for any requirements changes, for example).
Scrum tries to maximize the benefits of good change (eg, learning), and minimize the negative impact of bad change.
Scrum assumes change is normal, and anyway much of it can’t be controlled usefully.
WF assumes change is bad and can be controlled (usually).
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 clear overall 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 up-front….an easier problem to fix, we think.
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 and budget).
Scrum has strong and frequent controls (e.g., did you all get all those features done this past 2 weeks?)…which enables faster improvement.
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 and Scrum Coaching 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 Scrum vs Waterfall, as much as they remain in real practice, impede progress compared to Agile.
Final comment: These are not all the statements one could make. There probably are other useful comparisons. Your feedback is very welcome.