If you are someone who is passionate about agile, the word “Waterfall” is usually used in a derogatory manner or, at least, when you use it — you are making the stink eye. On the converse, if you are someone who practices what is popularly known as “Waterfall” Project Management, you generally get offended or defensive when the word “Waterfall” is used.

Here’s how the conversation plays out:

Agile practitioner:  “There’s no way I’ll ever work on a Waterfall project.”

Waterfall practitioner: “There’s no way I’ll ever work on that Agile project.”

Agile practitioner: “Waterfall projects are never successful and I hate being told what to do.”

Waterfall practitioner: “Well at least we do work and don’t practice that Agile witchcraft and all that kumbaya mumbo-jumbo.”

Agile practitioner: “Well, your mama said Waterfall is for losers.”

Waterfall practitioner: “Don’t be talking about my mama!” …

[Chaos ensues]


The sad part about this dialog is that although it’s somewhat fictitious, I’ve heard similar arguments at organizations and with colleagues who work across all spectra of the project management continuum. The funny part about the dialog above and, in particular, the word Waterfall — is that no one is really clear who started calling it Waterfall. It’s obvious that when diagramming out a sequential process, it looks like a waterfall:


Often, people credit Dr. Winston Royce with Waterfall project management, especially with respect to software engineering when, in 1970, he wrote a part in a white paper that describes this approach (read it here). The funny thing is that he goes on in that same white paper that is credited for starting the Waterfall practices to describe how risky it is, and that, in order to mitigate the risks, each stage of the Waterfall process should do things iteratively and incrementally.

Waterfall project management is really Sequential Project Management. Meaning we perform a sequence of activities and there are generally stages, maybe with sign-offs, and usually hand-offs, to another group of people who are charged with performing the next sequence and consuming the output of the previous sequence. Some refer to this as Traditional Project Management, but in most environments its called Waterfall.

I’m not going to discuss the differences between the two and which approach I think is better — it should be clear since you are reading an agile blog. I will say that I think that the merits of each approach are obvious and each approach has challenges. The usage of one approach over the other really depends on the project and possibly the people engaged.

What I am going to say is that, in the world in which we all live today, it is very likely that we’ll have a mix of projects using a more of an agile approach and one using more of a Sequential approach. Sometimes we’ll have to join forces and combine the output of these approaches into one. Of course, we are learning and adapting ways to do this, but that too is another discussion altogether.

Let’s face it, when words start dividing people, we probably shouldn’t use them any more. Instead call the project management approaches what they are – iterative and incremental, or sequential, or continuous, or simply ad hoc. Also, be aware that the moniker we place on people isn’t really on the people; it’s on the processes by which they may operate in — and they may be really comfortable in that process. Generally, they’ve put in a lot of blood and sweat to make it work. Sometimes we need to put the monikers aside and focus on “individuals and interactions over process and tools” (crazy how I got the Agile Manifesto into this blog, isn’t it?).

For now on, be aware and call it Sequential Project Management or even Traditional Project Management — unless you want to get in an argument about “your mama.”

Join the Discussion

    • edster

      Yeah, but… software development is always a complex adaptive system (CAS) because it is a creative act, and hence non-linear. The application of a sequential (waterfall) model to such systems is inherently incompatible — projects succeed *despite* the model, the people involved in the project compensate for the inefficiencies of the model, usually without the knowledge or recognition of the project manager. Organisations can continue to pretend that development is a mechanistic, linear process and suffer a high probability of failure or they can bite the bullet and acknowledge that development is a complex process and start using compatible models to manage it.

    • Evans Travis

      Hey Edster, I hear what you are saying but it sounds to me like we’re blaming the process and not the practioners who are mis-using it. It is hardly surprising that people back in the day picked up on the idea of “waterfall” and with little or no training and even less understanding went ahead and created the legacy we have today.

      What I see Matthew saying is we need to stop blaming the tools (and using the labels) we use for the bad outcomes we end up with and look in the mirror. I have heard similar conversations between people trying to use agile methods “in the field” and those who are pushing a pure agile approach. Agile methods are just a capable of failing as any other and there are quite a few cases where someone blames agile methodology for a project failure.

      After 30 years of managing mostly waterfall projects with external clients and some more recent experiences using agile methods (I am a CSM), I don’t see any inherent inefficiencies in either approach. They certainly are radically different, however. I have never understood why so many practitioners look upon methodolgies like these as recipes following them religiously no matter what the situation demands. They are, in my opinion, tools to be applied to the job at hand by experienced practitioners only. By “experienced practitioner” I mean someone with the required training, experience, and understanding of how these methodologies work to properly apply them. Anointing someone with little or no experience or with insufficient mangerial skill to run a project (which is something that often happens) is bound to end up in a troubled or failed project. At that point, I doubt it matters what methodology they use.

    • Mike DePaoli

      Another view into this is more from a neuroscience perspective. Human being all possess a “Control The Future” congnitive bias. This is explained in Cognitive Dissonance Theory. Certainty for our primitive ancestors meant a much higher probability of survival. If you feel more certain of things, there is generally less delay in our decision making.

      I agree that software development is by its nature a in the complex systems domain, hence the need to do a little, see what patterns are emerging and then adjust is the correct approach for operating in such a system. Of course that doesn’t stop our brains from wanting to reduce it to a simple system, where best practices rule. This is the domain where baking cookies lies 🙂

    • Pete Kovacevich

      While an accomplished practioner of the ‘waterfall’ method, I have to agree with ‘edster’ regarding the creative, non-linear reality of software development. I’ve become pretty adept at working with our software engineers who ‘create’ the software, the QM people who test it, and business & IT management (these guys should know better) who expect the SDLC methology to follow a proscribed path. We just have to get it done on time, on budget and satisfying the busienss requirements. Easy 🙂

    • Matt Badgley

      Fun discussions here and like I mentioned in the blog, I’m didn’t want to wade into the merits of either approach. I’ve seen them both work, but as @edster points out — ultimately people are what makes delivery of software successful, despite their challenges around the methodology they chose to deliver.

      In my past experiences, we made the sequential processes work and often didn’t like it much because we knew we could deliver better and faster without the processes in place. Some of the processes also introduced friction between the team members and functions, that got in the way of focusing on the real goal of delivering quality, valuable solutions.

      In any case, my sole purpose of this discussion is more about recognizing that words we use are either misunderstood or trigger responses which are not good for anyone. If you want to influence change (e.g. like getting an organization to move towards adopting an agile) be aware of your audience and their position on the words you use.

      As I’ve seen with the responses on this blog here and within a couple LinkedIn groups, the whole concept of talking methodology is a passionate one and ultimately turns into a competition. Nonetheless, it is a fun topic to debate. And I love the ideas and thoughts that debate triggers — if anything, it generally makes us better.

    • Joel Calderon (CSM)

      I think that the the problem with practitioners of Agile, particularly Scrum, is that they approach it like it’s a silver bullet, or worse, the one true religion, and that every thing else is evil. I’ve seen Agile teams fail because they used Agile/Scrum dogmatically and ended up serving the methodology rather than the other way around.

      I agree with Evan Travis that software development should be approached in a pragmatic way, and that we should be open to the strengths of all methodologies and be wary of their weaknesses.

      One strength of the “Waterfall” method is that it forces you to plan thoroughly, because its practitioners understand that the earlier in the project errors are introduced, and the later they are found, the higher the cost of rework will be. Waterfall necessitates extreme foresight–and foresight won’t hurt an Agile/Scrum practitioner even if the Scrum methodology allows for so much flexibility in dealing with project changes.

      So I say, use the Waterfall discipline to plan ahead and give all project stakeholders a clear path to project completion, but open the plan to the flexibility and adaptability of Agile/Scrum to be able to proactively respond to the possibly evolving constraints and liberties of your project.

    • Mike DePaoli

      IMO the bottom line is choose the “right tool for the job” based on the nature of the problem domain. This is inclusive of the business and technology requirements as well as organizational, human and environmental factors / needs. Our approach should hopefully have the least amount of delays (waste) possible from the start and a strong means to continually identify and remove the delays and dysfunction in the system.

      @ Joel – You wrote “One strength of the “Waterfall” method is that it forces you to plan thoroughly…” I worked in waterfall projects for 15 of my 27 years in the software industry. This upfront planning mindset, misused, is exactly what got sequential, phase gate execution in trouble. As I mentioned in my previous post. We all have an “Illusion of Control” cognitive bias and hence the analysis paralysis that still occurs. The vast majority of people prefer to talk about and plan a solution instead of getting started on it because our immediate sense of certainty is less threatened when we’re not moving into less certain environments.

      There is a big difference between planning thoroughly and planning effectively, especially in complex domains where everything just can’t be known or planned for. Irrespective of this fact about complex systems there are many carcasses of “Waterfall” projects that followed the plan done during thorough planning but still drove off a cliff. Whenever you have folks that are making the plans possess strong illusion of control bias, effective planning is not likely to occur.

      There are of course agile projects that fail, but a team executing with even a small amount of lean-agile competence will know they are off course from their plan earlier and also they will know from the customer if they are in fact building what they want. The question will be why didn’t they do something about it.

      I continue to see a mix of sequential / phase gate backbone product development processes integrating lean and agile techniques at the dev team or feature team level. They work just fine as long as the focus is on value and not following the plan.

    • John Argo

      A good PM will know when to do either and variations thereof. When they do, they will be aware of the shortcomings of each. Agile has some very effective applications and, when executed with discipline, can produce more relevant, cost effective results.

      Nonetheless, there are places for waterfall and some organizations are most comfortable with it. Stakeholder management, after all, is a key PM responsibility. This transcends methodologies. When a PM says they will only do one or the other, I will suspect them of having limited PM capabilities.

      For many reasons, sometimes good ones, some organization will still dictate waterfall. A good PM will able to step into that with open eyes and maximize the chances of delivering successful results.

    + 65 = 74