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.

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