Is Scrum just a series of Mini Waterfalls?

To many, sprinting through Scrum feels suspiciously like Mini Waterfalls; others state that that is merely a “bad smell” and Scrum is not just a series of mini waterfalls.

Which is correct?

Although the odor may be pungent, to me it seems correct that a Sprint marathon really is just a series of mini waterfalls, at least at the important levels.

Let’s see what they have in common:

1) The delivery date is clearly defined; in Waterfall, that delivery date may be months or years in the future, and in Scrum that delivery date may be the end of the current sprint, but either way, they are fixed. The only difference is the time scale. To me, they are the same in this regard (fixed delivery date)

2) Fixed scope during execution cycle; in Waterfall, the requirements are known up front and don’t change during the execution stage, however long that may be. In Scrum, the requirements for the current sprint is known up front, and change is not allowed (must reset sprint anew). In both cases, changing requirements during execution is unacceptable. Once again the only difference is the length of the execution period. Thus, they are the same in regards to their inflexibilty to incorporate change during an execution phase

3) Status Reports, Meetings, & More In waterfall, there would be weekly staff meetings, progress reports and the like. In scrum, the situation is the same; there are daily status meetings and burndown charts. Once again the only difference is the time scale

4) Sequential Execution In Scrum, (especially “Type A” Scrum), sprints are sequential and build upon earlier sprints. They do not overlap. This is no different from waterfall, where one phase is done before another and they happen sequentially. Either can choose whether to go horizontal or vertical during these phases.

5) Retrospectives In Waterfall, after a project there is a “post mortem” at the end of the execution phase to reflect on what went on and what to change in the future; in Scrum, there is a “retrospective” at the end of the execution phase (Sprint) with exactly the same goals. The difference? Once again, none beyond the time scale.

So, we can clearly see, that Scrum is not a radical, innovative, revolutionary approach. It is merely an evolutionary and reactionary approach that optimizes for short term planning, compared to waterfalls longer term planning type approach.

Scrum as a series of Mini Waterfalls? Yes, that does seem to be the case.

The relabelling of titles and frequent lip service to intangibles like “empowerment” do not change the overriding mini waterfall nature of the method; waterfall could and often does easily allow for self organization, freedom to choose tasks, etc.

The only tangible difference is short termism versus long termism, and if the waterfalls are “mini”, then they become equal in their short term outlook. To be absolutely clear, “mini waterfall” means one that is 1-4 weeks long.
Please understand that point — some commenters below seem to have missed it — I’m comparing it to a MINI (=short timeframe) waterfall.


About postagilist

Architect, Manager, Developer, Musician, Post-Agile thought leader
This entry was posted in agile, scrum and tagged , , , . Bookmark the permalink.

15 Responses to Is Scrum just a series of Mini Waterfalls?

  1. Pingback: New PM Articles for the Week of November 21 – 27 « The Practicing IT Project Manager

  2. PM Hut says:

    Hi PostAgilist,

    The title of your post is interesting, because this is how I perceive Scrum (I’m not a Scrummer by the way). It’s just an iterative approach that applies the regular waterfall model to each iteration (correct me if I’m wrong)…

    In any case, I think your post is great, and I would like to republish it on PM Hut ( ). Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.

  3. Just on paper with the steps outlined, one could agree they look the same, but with a shorter time scale. Yet, it is in that shorter time scale that things can improve. I’m not saying they “do” improve, just that they “can” improve.

    Keeping in mind that over a long project cycle, things change: the market, the company, the team. The shorter time scale adapts to this. Just to name a couple: The product can be delivered with fewer features earlier if necessary. The team has a chance to remain consistent during several full cycles. It is unlikely the team will be consistent during an entire waterfall, much less after the waterfall and on to the next to apply what they learn in the retrospective at the end of a project.

    If you only hold the retrospective at the end of a full waterfall, you can’t help the project you are on. But by holding it many times during a project it can help your current project which provides much more real value to those working on the project.

    • PostAgilist says:

      Sounds like you are basically agreeing with me. So why not call it “mini Waterfall” instead of Scrum? If all we are doing is changing the length of execution phases, that would be appropriate, and honest. Waterfall could use any project length. All Scrum does is change the project length and muddy the waters with orwellian newspeak.

      Also, waterfall projects already were typically broken up into phases, which align closely with sprints. And they could postmortem after every phase. Once again, I see nothing new here, other than the neologisms and fanatical marketing practices.


  4. Bob Hartman says:


    PostAgilist — Bob, you completely missed the point that “mini waterfall” means one that is 1-4 weeks long. Please try again.

    Maybe I’m a bad writer, but most people seem to have caught this. However, I will edit my original post for clarity to prevent confusion in the future.


  5. Pingback: Is Scrum just a series of Mini Waterfalls? | agile-development |

  6. Pingback: Is Scrum just a series of Mini Waterfalls? | agile-development |

  7. Pingback: Is Scrum just a series of Mini Waterfalls? | Agile in Dev Teams |

  8. Pingback: Is Scrum just a series of Mini Waterfalls? | Innovatus |

  9. I agree with your post.
    Never the less, I think your sentence “in Waterfall, the design is known up front and doesn’t change during the execution stage,” is not correct

    Just read the original paper where Waterfall was presented. There’s nothing like “design up-front and then never change it”.

    See for example:

    • PostAgilist says:

      What I really meant up front is that the “requirements” are known up front, eg by design I meant “the overall design of WHAT it’s supposed to be” (a Facebook clone) not HOW you are going to design the code (MVC/SQL/NoSQL/etc).

      However this is an obvious case of poor clarity on my part and I have edited it to requirements. Is that fine now? In either case, before the coding starts, in Scrum or Waterfall, the Requirements were finalized for that execution phase.


  10. Agilist says:

    I guess the main difference between Scrum and Waterfall is the fact that Scrum would also allow you to work “feature after feature” within a sprint, i.e. design, code, test, etc. a feature before starting to design, code, test, etc. another feature. This is even more evident for the Kanban method. By doing so, you are able to deliver something, even if you fail to deliver the committed scope.

    Waterfall, on the other hand, clearly tells you to work on all features simultaneously, i.e. design all features before coding them, coding all features before testing them, etc. By doinf so, you can only deliver everything or nothing (very often you’ll end up delivering “everything untested” or “everything poorly tested” in order to deliver on time).

  11. Ryan says:

    This article is ridiculous…

    [miscellaneous bleatings deleted for brevity — Ed.]

    These two methodologies are not the same…. Please get your facts straight. I am sure that if you did a basic web search, you would see a list of differences and perhaps begin to understand why you are wrong….

    Thank you,

    • postagilist says:

      Well thanks for the kind words. Not as ridiculous as your reply…..which was made…before reading (or understanding) the article.

      This article demonstrates the SIMILARITIES, not the differences, concluding, that, in a final analysis Scrum is essentially the brain dead version of a process that Royce derided (not championed) in the so called “Waterfall paper”.

      The only difference is the time scale; now if you don’t understand that, then enlarge the type on your browser and read it again until it makes sense.

      If it doesn’t make sense, then it doesn’t make sense to you; that’s not my problem.

      Just to try to make it very clear:

      1) Each sprint is a mini waterfall

      2) Yes, each sprint does in fact learn from preceding sprints

      3) The same would occur, if you took a 3 year “waterfall”, broke it up into 1 week “mini waterfalls”, did the whole waterfall process each time (planning, estimating, executing, testing, delivering) in each weekly sprint.

      4) That is what scrum is. Waterfall done weekly.

      Scrum thinks they are cool kids for doing little waterfalls. I think they are foolish… Stale bread, however thinly sliced, is still, stale bread.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s