Tag archive

project management

Words Mean Things – Waterfall

in Agile/Project Management by

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 phrase “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]

Winston and Murphy

The sad part about this dialog is that although it’s somewhat fictitious — I’ve heard similar arguments at organizations and with colleagues that work across all spectrums of the project management continuum. The funny part about the dialog above and, in particular, the word Waterfall — 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, especially with respects to software engineering when, in 1970, he wrote a part in a white paper that describes this project management 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 describing how risky it is and that in order to mitigate the risks, each stage of the 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 that 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 the world we all live in today, it is very likely that we’ll have a mix of projects using a more Agile approach and one using a more 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 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 instead of calling it Waterfall, try Sequential Project Management or even Traditional Project Management — unless you want to get in an argument about “your mama.”


in Project Management by

When I talk with folks learning about Agile, I often play the game Presto Manifesto where the room talks about what it means to have a successful project and then break up into groups and based on their experiences come up with a list of critical elements that they’ve noticed on successful projects. This exercise is meant to bring people to the concepts of what makes up the Agile Manifesto.
The interesting thing is that in many cases we discover that we’re programmed to believe that failures of projects relate to not knowing everything up front. I almost always hear, “complete, thorough, and approved requirements” as an element of successful projects. This programming aligns well to the formula of success I learned during a short stint at an ERP consultancy firm:


This formula leads us to make sure we set clear expectations so that we can meet and hopefully exceed them; thus, leading to success. However, as we know and learn in Agile (and really any process) – thinking the users/customers know everything about a project (a.k.a. need) six-to-nine months before they get their hands on it is simply a fallacy. Sure we can make the customers agree to the expectations ahead of time, but doesn’t that negate the ability to ensure that value and ROI is actually achieved on the project. What generally happens is that the customer/user defines the requirements and agrees to them, then sometime about a month before the project is delivered — they get their hands on some working capabilities and the say, “this doesn’t work like I expected, can you add a screen that does this and we’ll need a report that gets generated daily; if we don’t get these, we really can’t use this.” The response of the team is first, “but you signed the requirements document” or “those are great ideas, we’ll need to do that in the next phase” or “that will need to go through the change control process, we’ll need to escalate this.”

Ultimately, the team is not happy because they don’t get to experience SUCCESS because the RESULTS fall short of EXPECTATIONS. On-top-of-this, the customer is not happy either.

By using an Agile approach, we can improve on our SUCCESS rate through applying these very basic ideas:

  • The customer (a.k.a. the Product Owner) stays engaged with the team delivering throughout the project life-cycle. In fact, they are part of the team. At no point in the process should they disengage; thus, decisions and expectations are set near the time the need is built and subsequently delivered – requirements evolve. And since the customer stays engaged, changes should not be surprises to either the delivery team or the customer.
  • Needs are delivered in small valuable bites. This means that the delivery team and customer work together to understand what is smallest piece of value that should be delivered first and they deliver just that. This approach helps both the customer and delivery team by narrowing focus which results in faster delivery and a focus on getting the high-value need right (with quality). By the way, if the delivery team falls short of expectations for some reason it should not be a surprise to anyone and since we handle just a small bite – we fail small.
  • At regular intervals the delivery team (including the Product Owner) shows off the demonstrable product increment. Preferably what is demonstrated is a complete capability; however, this is not always possible. At a minimum enough is demonstrated so that feedback can be provided and the team can show that they are doing what they said they would. This demonstration provides a checkpoint for measuring success as well as it provides a way that expectations can be continuously molded and refined.
  • Conversations are constant within the delivery team, with the customer, and the stakeholders. Instead of having formal meetings that are dubbed “Status Meetings” — we have ongoing, regular discussions about the EXPECTATIONS. When an engineer has a question, they grab the key team members and product owner and discuss real-time. This results in clear understanding and a lack of hand-off breakdowns (where information is translated as it passes from one person to another).

There are many more things we do with agile delivery methods that ensure our projects are successful (e.g. continuous planning, short release cycles, engineering best-practices, and a ephemeral drive to get better). But if you start with the above ideas, I can assure you that the team and the customers will start getting that feeling of SUCCESS.

What are your thoughts?  How does your team measure success? Another great question, do you define SUCCESS before you start your projects?

Go to Top