Scrum vs Waterfall

Both have their place in their own context

Willem-Jan Ageling
· 5 min read
Two business men in suites fighting with each other
Two business men in suites fighting with each other
https://pixabay.com/users/alles-2597842/

The world knows many ways to create products. In this article I will focus on two that appear to divide the world: Scrum and Waterfall.

What is Waterfall?

There are many versions of this traditional approach to create products. For clarity’s sake I will stick to the easiest explainable version. With Waterfall you break down the project into sequential phases, for example as follows: requirements, analysis, design, coding, testing, operations.

The requirements can be defined and will not change dramatically during the project. Hence you can plan every step upfront, which allows you to monitor the progress of the project to ensure it’s within scope, on budget and in time. The objective is to avoid changes to scope, budget and time and deliver as promised.

With this way of working teams are grouped by functional roles. A functional team will work on one phase of a project, and then hand work off to another functional team when their part is done.

What is Scrum?

“Scrum is a framework for developing, delivering, and sustaining complex products.” — Scrum Guide 2017 by Ken Schwaber and Jeff Sutherland

In order to deliver and sustain complex products Scrum is based on empiricism: transparency, inspection, adaptation. At least once a month (but in many cases once a week or once every two weeks) teams define a goal and plan to meet this goal. At the end of the iteration teams inspect the increment and then adapt to create a new plan based on the findings and other important input.

Servicing different needs

Waterfall and Scrum both have their place. They serve different needs.

Waterfall works perfectly well in product contexts where:

  • it is crystal-clear what needs to be done and how to do it or
  • experts can find a right answer to a problem via analysis of the issue.

Scrum however works best in a product context where:

  • “what will happen is unknown” — Scrum Guide 2017

So you have product contexts suiting Waterfall and other product contexts suiting Scrum.

Where do Waterfall and Scrum Shine?

New houses under construction
New houses under construction
https://pixabay.com/users/paulbr75-2938186/

An example where Waterfall shines is with building a new housing estate. Experts have planned and constructed similar housing estates before and learned from experience. This allows for creating plans that can be followed very well.

A drawing of someone buying items with a smartphone
A drawing of someone buying items with a smartphone
https://pixabay.com/users/mohamed_hassan-5229782/

Scrum is best when you uncover new grounds. An example of this is the e-commerce environment where new developments succeed one and another rapidly and good practices today are out-of-date tomorrow. You need to adapt to survive and uncover new ways to thrive.

Waterfall in a complex context

Picture of someone striking through plan A and plan B and underlining plan C.
Picture of someone striking through plan A and plan B and underlining plan C.
https://pixabay.com/users/742680-742680/

If you choose to do a Waterfall project in a complex product context, you will certainly get into trouble. In these types of environments the duration of a typical project is too long to oversee what exactly needs to be done by when. If you still create that plan and go through the phases, one or more of the following will happen:

  • your requirements are incomplete and/or incorrect;
  • your solution is based on assumptions that will prove to be wrong;
  • your project will be drastically delayed;
  • you need to change your project baseline many times;
  • you need to redo things often;
  • your project will be far more expensive than planned;
  • you will build something that doesn’t meet the users’ needs;
  • you will build something that doesn’t add value anymore.

Instead you need to take small steps, reflect on what was built and then decide what to do next. You need to be able to embrace change instead of avoiding change. You also need to be able to dismiss a certain idea fast if proven not worth it.

Waterfall is not suited for this context.

Scrum outside of a complex context

Bulldog looking bored
Bulldog looking bored
https://pixabay.com/users/ivanovgood-1982503/

If you would choose to do Scrum outside of a complex product context, then you are bound to have events that add no real value. You don’t need to have a Sprint Review to inspect what you have built if this always is exactly what you expected to build. Instead it suffices to update the progress report.

You also don’t need to have planning sessions every iteration, because you only have to check the latest version of the project plan to know what is next. All these inspect and adapt moments are wasteful activities then.

You may also not require cross-functional teams because the work can just as well be done — or done better — in a sequential order, like with building a house.

Scrum is not suited for this context.

Scrum / Waterfall mix — It doesn’t make sense

Two hands chained
Two hands chained
https://pixabay.com/users/sammisreachers-43494/

Many organisations use a mix of Waterfall and Scrum to deliver their products. Scrum is used to execute the coding and testing phase, often combined as one phase. This doesn’t make sense. The practice of having fixed requirements that are sequentially tackled by the Scrum Teams has nothing to do with empiricism.

The worst version of this mix is where the Waterfall project is being executed in a complex context and Scrum is misused as a way to deliver items from a fixed requirements list. This really is twice as hurtful.

End note

It is key to understand what type of product context you are in. Every type of product context requires a different approach. In “non-complex” environments you can exactly plan work months in advance. But in complex environments you need to work in short iterations to learn and then adjust course.

Using an approach that is not suited for in a certain context can be harmful. Waterfall and Scrum can both work, but can also be the wrong choice. It all depends on your product context.

Use Waterfall if you can avoid changes, use Scrum if you want to embrace changes that can’t be avoided. — Maarten Dalmijn

And don’t try to mix Waterfall with Scrum. They simply aren’t complementary.

Picture of Venn diagram of use cases for Waterfall and Scrum, showing they don’t mix.
Picture of Venn diagram of use cases for Waterfall and Scrum, showing they don’t mix.
Venn diagram of use cases for Waterfall and Scrum. They don’t mix!
Serious Scrum footer including Slack logo and invitiation to join Slack community with link
Serious Scrum footer including Slack logo and invitiation to join Slack community with link
Do you want to write for Serious Scrum or seriously discuss Scrum?

Thank you Maarten Dalmijn, Marty de Jonge and Paddy Corry for your help.

Serious Scrum

Content by and for serious scrum practitioners.

Thanks to Maarten Dalmijn, Paddy Corry, and Marty de Jonge

Willem-Jan Ageling

Written by

Interested in ways to work better together. I love the discussion with open-minded people.

Serious Scrum

Content by and for serious scrum practitioners.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade