x

Scrum, it is just shorter waterfall?

Robert MacLean
8 October 2013

When I speak to people about Scrum, I often hear people describe Scrum as: Waterfall but with shorter iterations. That view, imho, is fundamentally wrong and will lead to you not getting any of the benefits from using Scrum.

Waterfall Myths

imageWaterfall provides a structured approach to software development and has a reputation for taking a long time to deliver because each phase must occur and must occur in order. In reality Scrum is very similar and has many of the same steps, in the same order as Waterfall.

So what about the length of time issue? Waterfall seems to be used around massive projects which takes months or years to ship, yet Scrum is great because you have a minimum viable product (mvp) every four weeks. That isn’t true either – a lot of the myth here is because during the scoping of a project using Waterfall, everyone puts the everything in. In reality, nothing stops you having smaller deliverables of a mvp while using Waterfall.

The last myth to dispel is that Scrum is better than Waterfall because it allows the product owner to change the goals as they learn about what is built & the market conditions change. Waterfall does allow that too. In Waterfall it is called change controls and, done right, they work very well.

In addition, if you use smaller iterations with Waterfall, you can use the requirements, design & verification stages as you would sprint planning & retrospectives to adjust the course of the team.

How is Scrum different to Waterfall?

A side thought, is that difference in that ownership could also be why projects using Waterfall seems to fail more than those using Scrum. It isn’t the methodology but rather it is the people doing the work’s commitment which drives the success or failure of the project. For projects using Waterfall where they are successful, I think you will find that they do many things outside the methodology to ensure everyone feels committed to the success.

If Waterfall can offer everything that Scrum does too, how then is Scrum different? The major difference with the two methodologies is around the psychology of the developers involved with the project:

  • Waterfall: Have a single centralised, ownership for the project
  • Scrum: Have a distributed, ownership for the project

That may not make much sense, so let me explain what I mean by ownership of the project. The ownership for the project is made up of a number of things:

  • How much responsibility a person involved has?
  • How much authority a person involved has?
  • How much control and influence a person involved has?

When we look at Waterfall, the developers involved in the project have very little with regards to the above conditions. Those conditions are almost solely handled by the project head and project managers, and because of this lack of authority, responsibility and influence the developers are not invested in the ultimate delivery of the project.

Scrum on the other hand, drives verifying levels of responsibility, authority and influence to everyone involved. For example the product owner has the most responsibility but there is still responsibility shared to the rest of the team. It is impossible in scrum for a developer to bury their head in the sand and say the problems are not their problem.

Conclusion

scrum-pigs-chickensFor me the major difference can easily be summarised using the old fable of The Chicken and the Pig. Waterfall allows developers to be chickens but scrum requires the developers to be pigs.

Choosing between Waterfall and Scrum isn't so much about choosing between methodologies as choosing between designs of ownership and responsibility. That design is vital because how your team is designed directly impacts what you ship.

↑