Scrum vs waterfall: what actually differs

Comparisons between Scrum and waterfall usually turn into a contest between a modern good and an outdated bad. That is neither fair nor useful. Waterfall is a coherent way to run work, with a long history and real strengths. Scrum is a different coherent way, designed for a different kind of uncertainty. The useful question is what each assumes about the work, and whether that assumption is true for yours.

How waterfall works

The waterfall model arranges a project as a sequence of phases, and each phase is finished before the next begins. A typical sequence is requirements, design, building, testing, deployment and maintenance, with the output of each phase becoming the input of the one after it. The name comes from the way progress flows largely in one direction, like water down a series of drops.

The assumptions behind it are reasonable in the right setting. The requirements can be known up front. The design can be settled before building starts. Changes after that point are costly, so they should be rare and controlled. Clear milestones and thorough documentation make progress easy to report and knowledge easy to hand over.

The GOV.UK Service Manual states the cost of this plainly. In a sequential project, it says, you only have one chance to get each part right, because teams do not return to earlier stages, and users give feedback only at the end. The same page says a waterfall project can take a long time and still produce something out of date, because policy, technology and users have moved on.

How Scrum works

Scrum arranges the work as a repeated cycle. The Product Owner keeps one ordered Product Backlog. In each Sprint of a month or less the Scrum Team turns a selection of that work into an Increment of value, then the team and its stakeholders inspect the result and adjust. Planning, building, testing and review all happen inside every Sprint. The Guide describes each Sprint as being like a short project.

The assumptions are different. The problem is complex, so what will work is not fully known in advance. Knowledge comes from experience and from decisions made on what is observed. So the framework builds in inspection at short intervals, and it expects the plan to change.

Side by side

The SBOK® Guide offers a similar table. It describes Scrum as emphasising people over processes, iterative over linear planning, and customer involvement throughout the project instead of at its end. It also observes that traditional project management can lead to a situation where the plan has succeeded yet the customer is not satisfied.

A worked example: six months, two ways

This is an illustrative project. A company wants a customer portal and has six months and a team of eight.

In the sequential version, the first six weeks go on requirements and sign-off, the next six on design and architecture, the next ten on building, four on testing and two on deployment. In week thirteen the business learns that one large customer group needs single sign-on, which was not in the requirements. It is added through the change process. The first time any real customer sees the portal is week twenty-four. They dislike the navigation. Fixing it now touches the design, the build and the tests.

In the Scrum version, the team and the Product Owner spend the first week agreeing a Product Goal and ordering the top of the backlog. Sprint one, two weeks long, ends with a login screen and an account page that a handful of real customers try. Single sign-on comes up in Sprint three review and goes into the backlog, ordered above two nice-to-haves. By Sprint six, a navigation problem has been found and fixed at a cost of a few days. Six months later, the portal is in use, and the first release went live around month three.

This is not a claim that the Scrum version always wins. It might not, if the sequential team had perfect requirements. It illustrates what each approach is exposed to: the sequence is exposed to late discovery, and the cycle is exposed to wasted effort on changing direction. The Guide's bet is that for complex work, the second exposure is the smaller one.

Where waterfall still makes sense

Sequential delivery is a reasonable choice when:

• the requirements are stable and well understood, such as a regulated migration with a fixed specification;
• the cost of change after a phase is very high, such as physical construction, or hardware tooling;
• a contract or regulator requires fixed phases and sign-offs;
• the work is repeatable, and the team has done it many times before.

Even then many teams take elements from Scrum. A mostly sequential programme can use short iterations for the parts with the most uncertainty. We discuss the wider question in when Scrum fits and when it does not.

Hybrids and "wagile"

Teams often blend the two, and the result is not always good. One common pattern is a mini-waterfall inside each Sprint: analysis in week one, build in week two, test at the end. It keeps the handovers and loses most of the benefit, because testers receive work only at the end of the Sprint and the Increment is rarely ready on time. A better approach is to slice the work thin enough that each item moves from idea to tested in a few days.

Another pattern is a waterfall budget with Scrum delivery. The funding model asks for a fixed scope and date, while the team plans to adapt. This can work if everyone is clear about which of scope, date and cost can move, and it fails when the plan is treated as a promise.

Common mistakes in the comparison

• Calling anything with phases "waterfall". Phases are fine. A phase that must be finished before feedback is possible is the issue.
• Calling anything with meetings "Scrum". See how to read the Scrum Guide.
• Judging a method by its worst example. Bad Scrum and bad waterfall both exist.
• Comparing plans with outcomes. A waterfall plan can look better than a Scrum backlog on paper, and the question is how each performs when reality changes.

How to practise it

The clearest way to feel the difference is to run a project where the plan and the facts disagree, and see how early you notice. The simulator gives you situations where an early plan meets a late surprise.