08 Oct 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.


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.


Visitor's picture

Pure Waterfall probably doesn't exist in the real world. It was created as a straw-man by Royce in his paper. Some form of iteration will happen in any project. There may be projects where the Big Thinkers write documents and draw diagrams for months, freeze everything, then throw them to the minions to develop, but it is extremely unlikely that any such project would satisfy real-world requirements at the first release.

Joshua Lewis's picture

I don't think I agree with this. There are plenty of places that do *all* the requirement work, before starting the design work, then do *all* the design work before starting the implementation work etc. They end up changing both the requirement and design work etc anyway, when they eventually get feedback from the downstream customer.

Joshua Lewis's picture

For me, the fundamental problem with Waterfall is the size of the batches of work that move through the system. Waterfall implies that you should do *all* the Requirements work *before* moving to the Design work. This large batch size increases work in progress (inventory), and leads to very long lead times, which decreases feedback, which is an impediment to learning, validation and quality. These problems have been solved in manufacturing for decades (see Toyota Production System and work cells).

Scrum tries to solve this problem by:
i. fixing scope for a sprint, so inherently the batch size is limited, we can do only so much requirement and design work in a sprint
ii. creating cross-functional teams (a work cell) to increase collaboration, reduce lead time and decrease feedback time, ie increasing learning and validation (and hopefully quality).

I firmly believe that the ideal is a truly cross-functional team, who work on only 1 piece of work at a time (single-piece flow).

Robert MacLean's picture

Size of work is a massive point & you are right to bring it up. Once again though, size of work is about people. If you need to design something, you need a mental model. The larger the work - the larger the mental model... having smaller pieces makes it easier to do that mental model and less likely to have issues.

Cross functional teams is also important for similar goals of engineering a team psychology - having one person who does x, leads a team to easily not do work because they are bottlenecked by that person or just ignore work because they do not do that work. A cross functional team pushes the idea that everyone does everything, so no one can avoid work and it forces everyone to accept responsibility.

Joshua Lewis's picture

Your post includes: "When I speak to people about Scrum, I often hear people describe Scrum as: Waterfall but with shorter iterations". I do believe that if people just did this, i.e. decrease their iteration length (and fix scope for that iteration), there would definitely be an increase in quality and learning.

What I left out of my earlier comment, and which is also salient, is that Scrum allows the organisation to change the priority of work when a sprint kicks off, i.e. there isn't a fixed plan for the order of work to be done (which isn't necessarily mandated by Waterfall, but is implied because if we do all the requirement work before starting the design work, there isn't an opportunity to re-prioritise).

Add new comment