Scrum vs Waterfall
Both have their place in their own context
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?
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.
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
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
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
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.
Thank you Maarten Dalmijn, Marty de Jonge and Paddy Corry for your help.
