Scrum vs Waterfall: How to choose

Scrum good. Waterfall bad.

That’s as simple as many sources make it sound these days. Out with the old, in with the new.

But what if we told you it wasn’t so straightforward?

What if we said, for example, that Google uses some of the Waterfall development process — yes, in 2020?

Or that some methodologies actually help Scrum and Waterfall work together?

There’s no such thing as a perfect project management methodology. Here at monday.com, we like to give you the information, then let you choose for yourself.

In this article, we’ll shed light on the differences between a Scrum development process and the Waterfall approach — and help you decide which one could best transform your team.

Scrum vs. Waterfall: What’s the difference?

Waterfall methodology is often presented as the dragon slain by the heroic knight Agile and his faithful steed, Scrum.

The tale goes like this:

Once upon a time, there was an outdated project management philosophy called Waterfall.

On a Waterfall project, each phase had to be completed before anybody could move to the next one. Gathering the requirements had to come first, then design, development, testing, and finally release.

This was very bad, the storytellers say, because it wasn’t flexible.

New versions of software could take a year or more to hit the market. By the time it was out, people didn’t want it anymore.

Then a band of heroes said, “no more!” and published the Agile Manifesto.

This holy document proposed a new kind of project management, built around short shipping cycles, frequent collaboration with stakeholders, and the embrace of constant change.

Soon after, Scrum became the most popular framework for interpreting the Agile methodology.

Each Scrum team would devise a product backlog (list of features and requirements), then work on it in sprints, each lasting 1–4 weeks, and tackling a chunk of the backlog.

If customers didn’t like what they released in one sprint, they’d revise it in the next one. If part of their process wasn’t working, they’d change that too.

The Agile Scrum approach was heralded as the perfect system.

The crusty old Waterfall method couldn’t compete, and it was driven out of the land. And they all lived happily ever after.

It’s a great story…

But how true is it?

Try monday dev

Waterfall: Myth vs. reality

The Waterfall model dominated project management for eons. That’s because, for many products, it’s the only method that makes sense.

Can you imagine a contractor building a house in two weeks, then iterating on it while the residents lived there?

Or a farmer replanting his fields once a month, because people told him they wanted different vegetables?

For some types of projects Scrum just isn’t a realistic solution.

As long as people are still tackling long, complex projects that can be reasonably well-planned in advance (like new construction), don’t expect Waterfall to disappear any time soon.

Scrum: Myth vs. reality

Agile and Scrum started out in the software industry, where teams were tackling projects that could be distributed at the speed of light.

And for fast-moving, rapidly changing environments there’s no contest — Scrum will always slay Waterfall.

But, that’s not to say that the Agile approach and Scrum are only good for software and digital products either.

Waterfall is great for planning a new building. But what about a renovation?

When you never know what you’re going to find behind the drywall or under the flooring, it gets pretty hard to plan the job out in advance.

Anytime you’re walking into the great unknown, regardless of industry, the Agile methodology will trump Waterfall project management.

Of course, there are other routes to Agile project management. Kanban is almost as popular as Scrum. But that’s another story.

Is Waterfall or Scrum right for me?

Here’s the important question for right now: why wouldn’t you want to use Agile methodology and the Scrum framework to manage your software project?

Scrum vs. Waterfall: Winning scenarios

Even in software (the industry Agile was designed for), Scrum is not always the winning answer.

Scrum works best on a single team of developers. The ideal Scrum team is made up of 3–9 talented, driven individuals who are great at organizing themselves.

They don’t need much management — the boss (aka Scrum Master) is only there as an unblocker — if they’re needed at all.

(Our team at monday.com doesn’t use a Scrum Master because we support the Scrum idea that everyone is self managed.)

But it’s hard to give everyone that much freedom at the scale of a major corporation.

For Scrum to work at scale, your communication has to be perfect. Otherwise, you’ll get a shoddy, inconsistent product.

A lot of enterprises turn to SAFe (Scaled Agile Framework) as a better Agile solution for big business. But that is yet another story for another day.

This leads us to another big drawback to the Agile approach:

Agile and Scrum don’t cope well with strict expectations.

Agile is like the free-wheeling teenager that wants to experiment and be creative.

Scrum puts some loose guidelines in place, like daily meetings and short-term commitments, to make sure Agile doesn’t go too far down the wrong path. But as a parent, it’s the one who says, “I’ve taught them all I need to, and now it’s their time to fly.”

That works if all of your major stakeholders (executives, project sponsor, client, etc.) love being that type of parent.

But, what happens if your client is more of a military dad at heart?

You know, the guy who won’t hand over the car keys until he has the names and contact info of everyone you’re meeting up with, has an hour-by-hour itinerary of your evening plans, and has you sign in blood that you won’t be one second past curfew.

With that sort of parent, Agile falls apart.

If your client wants to know up-front exactly what you’ll deliver, down to the last specification, the exact date it’ll be ready by, and how much it’ll cost down to the penny, you need Waterfall.

If your project scope and requirements are vague — e.g. “Build the world’s greatest messaging app” — Scrum is a great way to go about it. If your client knows exactly what they want, when they want it by, and for how much, the Waterfall model is superior.

Try monday dev

Scrum vs. Waterfall: Pricing

After the last section, you might already be sure which project management methodology is the perfect one for you.

But in case you aren’t, let’s take a closer look at some other arenas where the Waterfall method and Agile Scrum compete.

First, there’s price.

Fans of Agile methodology like to say that it’s way cheaper — up to 6x cheaper, according to some reports.

They say Waterfall is costly because you ship fewer products, and win fewer loyal customers with 12-month release cycles.

The truth is that it’s almost impossible to compare the two.

Remember that Scrum is most-often used to build software, while Waterfall methodology is commonly used for big, complex, “old-school” projects.

Building an app is cheap. Building an airplane is a little pricier. And you can only build one of these things using Scrum or the Agile method (Kanban also won’t help you much with the airplane).

Is it a question of either-or?

It’s clear Waterfall is better for some projects, teams, and clients, while Scrum is more well-suited for others.

But, what if you deal with both?

Maybe you run a construction company that does new-builds and renovations. Or you’re a developer who has some care-free clients and others with crystal clear visions.

Do you need to pick just one framework to champion?

In the end, the choice might come down to your tools.

Google adopted a combination of Agile Scrum and Waterfall methodologies, because it let them use procedures they were comfortable with, and switch between methods based on the needs of each project.

You can do the same — but only if you have project management tools that support multiple frameworks, and let you switch back-and-forth without losing valuable information.

You use Waterfall and Scrum, or even a combination of the two, you’ll need a project management system that supports both.

For Waterfall, you’ll need a tool that offers project plans, work breakdown structures, full project schedules, and more.

With Scrum, you’ll require a product backlog, a roadmap, and the ability to break detailed planning down into sprints.

Of course, other features like daily task trackers and change request templates work great with both methods.

If you want to get started with the Waterfall methodology, try playing with the monday.com work plan template. It’s perfect for leaders who like the certainty of advance planning.