What's the difference between Waterfall and Scrum?

“But isn’t that just doing mini-waterfalls?”, asked a recent attendee at one of our Agile Essentials courses.
Scrum requires the team do all the same type of activity they used to do in a Waterfall environment — analysis, design, build and testing their product. I showed the person the faster feedback cycles and the anti-patterns of waterfalling Sprints, but it still wasn’t enough for her.

Don't Waterfall your Sprints
A comparison of Waterfalling Sprints versus Scrum’s Sprints

What I needed was a side-by-side comparison that illustrated how each of these two methods handled different aspects of project management and delivery.

Waterfall Scrum
Schedule driven Value driven
Plan creates the cost, schedule, estimates Valued features drive estimates
Development is phase based and sequential Development is iterative and incremental
Focus is predictive Focus is adaptive
Demonstrate progress by reporting on activity and stage gateways Demonstrate progress by delivering valued features every two weeks
Product quality at the end after extensive test/fix activities Quality is built in with upfront standards
Batches are large (frequently 100%) Optimises smaller, economically sensible, batch sizes for speed of delivery of valued features
Critical learning applies on one major analyse-design-build-test loop Leverages multiple concurrent learning loops
Process is tolerant of late learning Work is organised for fast feedback
Handovers between analyse-design-build-test phases with knowledge stored in documents Cross-functional team with knowledge of the product invested in the whole team through shared experiences

For me, the main difference in comparing the two methods is:

  • Scrum is value driven, where the plan is formed around the question “what is the most valuable item we can deliver today”
  • Waterfall produces a plan from which costs, schedule and estimates are created

If I wanted to deliver value to clients and stakeholders, Scrum is the method I would choose.
M

About the author

Related Posts:

How do I run a Retrospective?

The Retrospective is one of five events in Scrum. It’s purpose is to inspect the whole Scrum Team from the perspective of people, process and tools, and then adapt the way the whole team works (including the Product Owner).

READ MORE

Better together: Agile + Lean UX

How do you make Design Thinking, Lean UX, and Agile work together. Sprint 0? Design Sprints? Upfront design and planning tends to delay the delivery of value, so there must be a better way to use Scrum but also engage in discovery work at the same time without devolving into parallel design work. Integrating design, user research, and experimentation into Sprints is the key.

READ MORE

How do I run a Sprint Review?

The Sprint Review is one of five events in Scrum. It’s purpose is to inspect the Increment of work, get feedback, and then adapt the Product Backlog. And while many people refer to the Sprint Review as the “demo” or “showcase”, this is only one aspect of the Sprint Review.

READ MORE

How do I run a Daily Scrum?

Many people use the Daily Scrum to provide a status report to the Product Owner or Scrum Master, and even to stakeholders, but this event plays a more critical part in ensuring that the team continues to stay focussed on their goal and adapt their work so they improve their chance of achieving it.

READ MORE