Waterfall image

Waterfall Is the Wrong Enemy

I was reading The Inmates are Running the Asylum by Alan Cooper when I came across this passage in chapter 8:

“Some of their previous products were successes and some were failure, but the process they used to create them was the same. From this they deduced that the success or failure of a software product is due only to chance; software success is simply a crapshoot. The problem is reminiscent of physicians in the nineteenth century, before it was discovered that the anopheles mosquito carried malaria, who were unsure of the disease’s source. It was thought to float on the evening air, striking randomly, and one’s only defense against the often-deadly fever was luck. After the cause-and-effect relationship was discovered, the disease was quickly brought to heel.”

And reading this, I thought “That’s us! We have looked at our randomness and declared Waterfall to be the culprit. Agile is the cure!”

Only, I’m not sure we yet understand the problem. I have little faith agile alone can save us. I fear we have become students of nineteenth century doctors.

The Manifesto signers were right, but all too often we have looked beyond the principals they espoused and cried for process and tools. And in our search for what’s easy to digest, we have missed what is most important.

Waterfall image

The problem with waterfall was not too much documentation, but documentation over conversation and understanding. The problem was not in developing plans, but in blindly following plans that were developed with too little information. The problem is we like simple tools and easy-to-use processes, and we are following them without understanding when they work best.

It is difficult to look at ourselves, our skills and shortcomings, to honestly evaluate a team, and then to cast the same critical eye over our technical environment, our business partners, our corporate culture, a nascent understanding of the marketplace, and more to develop the right version of a process. It is easy to say “I will follow Scrum (or any version of Agile)” and fight for meeting the version you were taught in class. And because you still have to fight for your version against the reticent and resistant, it feels like a good fight.

But it is the wrong fight.

Let us commit to reviewing both the manifesto and the principles. Then let us commit to working on the foundations, rather than just a new process. Because if you’re only changing the process without understanding what you are changing and why, I’d rather you change the lighting and humidity.


  1. Curtis Michelson   •  

    Spot on GoodReq! (great book btw. “Inmates” is a classic.)

    I think the thing is, we (all of us) take a good idea (like the Manifesto) and we then ossify into a “Methodology” like Scrum, Lean, etc. And somewhere along the way have lost all our ability to think freely and fluidly. I have a sneaking suspicion how this happens, but we’ll leave for that another day.

    The challenge is to be continually creative in our application of principles, willing to flex where appropriate. Perhaps over time, as the profession matures and approaches evolve, with hindsight some day, we’ll look back and see ourselves as those 19th century physicians. But at this point in time, I think the best we can do is stay nimble in our hypotheses and open to our intuition, instincts and new incoming data.

    SpecosaurusRex (a not so highly evolved analyst)

    • @JeffreyGoodReq   •     Author

      It’s a shame more people haven’t read The Inmates Are Running the Asylum. It’s a bit dated now, having been published 13 years ago, but the reason it became dates was because it was seminal to changing the world of software production!

      And I still run into people who have never used or even seen a persona. I really need to develop a post or class for this.

  2. Geoff   •  

    In my opinion, if you have good people then the process is irrelevant.
    A great team with a crap methodology is still better than a crap team with a great methodology.

    • @JeffreyGoodReq   •     Author

      Ah, a fan of Jim Collins! I also believe a great team can make up (and will almost certainly have to) for any process they must follow.

      The problem is so very few take the time to build a great team for the problem at hand. What would you guess? I think great teams are less than 2% of the total, 5% at the outside? And if so few teams are great, and not many more are truly good, then you need methodology and process to backfill for the shortcomings.

      *sigh* I know it feels like I am arguing against my post above, but we do need process. The question goes back to “Which process? In what technical and cultural environment? And for which teams?” If you don’t evaluate where you are and what you have against your goal, you will reach significant points points before you reach the desired outcome. If you get there.

  3. Robert Sprigge   •  

    I’m certain we don’t yet understand the problem Jeffrey.

    We need to review our thinking in several directions:

    Although an Agile enthusiast I’m not happy that the Agile principles, as defined, are the right ones. For example I feel that they launch into the Software world without giving sufficient consideration to the Business or Customer, despite what they purport to say.

    If you simply think every situation is a minor variant of the same problem you’ll always use the same tool without thinking.

    Whereas we actually need a collection of tools not one, or even two, we then need to carefully select the most appropriate tools for the particular situation.

    What is the particular situation that you have now and what matters most? There are just so many variables to consider, but consider them we must BEFORE we select the tools each time.

  4. Bob Marshall   •  

    Actually, a small few of us now do understand the problem. The problem is described in some detail in my white papers, videos, and model. See in particular “Rightshifting”, and “The Marshall Model”.


    – Bob @FlowchainSensei

Comments are closed.