The Perennial Waterfall Strawman/Myth

Just as the ‘abominable snowman’ never existed, and is merely used to frighten children from playing in the snow too long, “Waterfall” is just as nonexistent and is used by agile coaches as propaganda scare tactics to frighten developers into buying into Agile, Lean, kanban, or whatever the flavor of the month is in project management.

Agilists constantly talk about ‘Waterfall’ in derisive terms, however we can get an idea what this mythical beast is like from the depictions of the Agilists.

  1. Waterfall requires absolute command and control
  2. Tasks are assigned
  3. Testing never happens until after the project is finished
  4. The customer is not involved until it’s too late
  5. Everything must be done in strict phases, the phases must be horizontal in nature (eg, no UI gets done until ALL of the database is done, etc), and once a phase is complete it will never be modified in the future
  6. A huge amount of upfront design is done before coding

These are all myths.  Anyone who has even read Royce’s original paper on the subject would know that.

Let’s look at the reality

  1. Royce’s paper does not even use the word “Waterfall” — hence there is no “Waterfall” method at all
  2. Royce never mentions assigning tasks
  3. Royce never mentions a command and control environment
  4. Royce specifically states that a hard phase approach as described in #5 above is unworkable, and shows quite clearly feedback mechanisms between the phases
  5. Royce never states that phases should be done horizontally
  6. Royce specifically states that the customer should be involved early, and testing should be done sooner rather than later
  7. etc

So the Agilists present a false dichotomy: Either you choose a (fictitious) Waterfall process that never existed, and make everyone slaves to documentation and management, or you choose their latest Agile scheme, and become slaves to daily Scrums, Poker Games, and begging the Customer to tell you what you should do.

The fact is, there are a lot more choices out there. There are many flavors of traditional management out there; choosing tasks can be done when there are documents and planning.

There are many ways of doing iterative traditional practices as well…see the “my approach” link above for more information.

The next time you hear someone promising you will fail with waterfall you can be sure of a few things:

  1. They don’t know what they are talking about
  2. They don’t believe in facts or logic
  3. They’ll say anything to get the sale

You can always respond smartly with: “Beware the Jabberwock!”


About postagilist

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

7 Responses to The Perennial Waterfall Strawman/Myth

  1. While Royce may not have called out a process called Waterfall (or anything like it), that doesn’t mean it doesn’t/didn’t exist. A few years ago (before their love affair with Agile began), the shop I work went whole-hog for a methodology they called “The Factory” and that had all six of the elements you mention above, and then some.

    Just as Agilists come in different flavors (kanban, scrum, lean, etc.) so did the “waterfall” mentalities.”The Factory” was stupidly rigid, with gates and reviews and such.

    I just wish management would realize that we, as IT professionals, have done this before, that we know what works and what doesn’t, and would let US devise and tailor the methodology that works best for US, rather than implementing the latesty shiny new object from the latest white paper.

    • PostAgilist says:

      I’m sure “big process” existed in some places, like Boeing or whatever, but

      1) Even when it existed it did work (the Boeing planes do get built…)

      2) It’s very rare, for anything modern and software ish, the past 30 years to be anywhere near the highly gated myth promulgated by agilists.

      3) Change did get accomodated even in Waterfall

      I do agree very much that we should create methodologies for software, not derived from manufacturing. See the My Approach link at the top.

      Agilists spend too much time skating to where the puck was (30+ years ago — eg Kanban) instead of skating to where the puck will be. In fact they are skating on a football field because manufacturing is not software. Will be blogging about this in the future


  2. On the front of myths vs reality I would like to add my very personal 2 cents:
    1) I understand Royce’s paper wasn’t meant to propone Waterfall as a method but like it or not it happened
    2) When I was at university I was taught the ‘Waterfall methodology’. It comprised of a process, activities and artefacts.
    3) I was also taught at university the ‘Spiral’, ‘V-Model’ and ‘Incremental’ methodologies
    4) Subsequent to university I learnt RUP
    5) My first job out of university in a world renowned software development shop was exactly as you described – however you described it as a myth. I am sorry to say it really happened to me. The Project Manager and Architect created all the tasks and estimates and told us we were to ensure we delivered to those time. The requirements phase lasted 6 months, design another 4 months, development one year, compilation and systems integration 3 months, systems testing 5 months and then delivery into production. In this whole time I only saw the customer once in requirements (and I was writing requirements) and a few times at the end when we were running very late (over a year late). The phases were strictly kept to and huge upfront design did happen prior to coding.

    I know in retrospection (and knew to some extent at the time) that a lot of what happened was wrong but the key question is- was this the fault of waterfall or the fault of people? I believe it is both.

    • PostAgilist says:

      When was your first job out of college? I think things like that happened, whatever you want to call it, decades ago.

      Whether it is a total myth (never happened) or just a “local myth” (hasn’t happened recently), it doesn’t matter to me, because modern traditional projects, are not like what you describe.

      The past is the past. Whether it’s myth or the past, Agilists build up a straw man version of waterfall, that either never existed, or does not today exist.

      It’s like talking about polio — sure maybe 70 years ago, polio was a grave threat, and now it’s eradicated nearly worldwide.

      It doesn’t matter if polio ever existed — it’s not a health problem today, and so building up a whole healthcare philosophy based on demonizing polio makes absolutely zero sense in the modern world.


      • JayWilmont says:

        I’m working under Waterfall right now, quit saying it doesn’t exist.

        The problem isn’t that the projects don’t get built, the problems include:
        0. No development work begins until lengthy documentation is produced
        1. Documentation not getting updated when features change
        2. The deadlines remaining fixed even after features change
        3. Clients don’t look at the system until it is ‘done’

        Mostly this results in much time wasted building unusable documentation, developers staying late to meet the original deadline, and developers staying late to retrofit features once the client sees the product.

        None of these problems can be resolved by Waterfall processes, like better requirements gathering or ‘better’/stricter timelines or trying to enforce that no features will change once development begins.

      • postagilist says:

        Hi Jay

        What you are working under is a degenerate form of phased approach that even Royce in his so called “Waterfall” paper described as unworkable.

        So I’m not surprised it isn’t working for you…

        Please read the 2nd part of the royce paper where it talks about overlapping/paralellizing the phases and prototyping.

        Royce said “DON”T do that”. It’s like Moses said, thou shalt not murder.

        Agilists leave the “not” out of it and say that Royce was espousing murder.

        It’s not true; read the paper and jettison the obviously broken approach that even Royce 40 years ago said didn’t work, and read his 2part of the paper, and/or my approach for various alternatives (although certainly not the only alternatives).

        Essentially what you are referring to (degenerate form) equates to:

        We’ll get it right the first time. (not likely)

        What he recommends boils down to:

        Prototype it first, and we’ll get it right the 2nd time. (OK..maybe)

        What agile recommends is:

        We’ll do it over and over forever until we get it right (Hrrm..well…)


  3. Mirko says:

    Hi PostAgilist,

    This is the first time I comment in your blog. I accidentally found it (and I am glad I did!). I was hired last year as a ScrumMaster right out of college. So, I did not have any experience with project management in the real world. I had to study about Agile project management and learn with the people from the company that was already using Scrum for a while. So, my only source of knowledge for a long time were the Scrum or Agile-gurus (as some call them).

    Even though, I don’t have much experience, I think is true when some people say that they faced the situations you describe as myths. I think that the myth you talk about is not about the situation happening or not, but that “traditional management” is meant to be that way. And, I gotta tell you, that is how I believed it was meant to be until last year.

    Last year I had the opportunity to start a MBA program on project management (based in the PMBok) and I got surprised with what I saw. Traditional project management is supposed to adapt to change, involve customers early, have the development team to collaborate with estimates and decisions, etc? That was not what I expected. That is not what I was told by the “hardcore” Agile people…

    Anyways, even though I still have a lot to learn, I can see some value on Agile stuff (even though, I agree with you that some stuff are not Agile, such as iterative development, etc.), but I have to agree with you that some people use it as a way just to get more money.

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 )

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