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:

Groupthink: the bane of high performing Agile Teams

What makes an agile team great and why? After coaching a number of teams in Scrum, we’ve now seen a number that, after a some months now, could be considered high performers. Some of these go bad and reject any external criticism regardless of how accurate that might be. Why do these teams go bad? Groupthink might have the answer.

READ MORE
search previous next tag category expand menu location phone mail time cart zoom edit close