The worst thing about Waterfall

Erwin van der Koogh

Last week, after one of our bi-weekly Xebia Knowledge Exchange meetings when we should have been having a beer chatting about cars and sport, a few fellow Xebians and I were having a beer chatting about agile vs waterfall. The conversation quickly turned to the question "what is the worst part about waterfall."

In the end we settled on "Incentivizing (is that a word?) parts of the chain instead of the whole".

Let me explain.

A typical waterfall project has a few distinct phases that are always something along the lines of Business Analyses, Detailed Specification, Construction and Testing. They all depend on each other and nothing can start before the previous phase is finished. You can not start Constructing if you do not know what the Detailed Specifications are for example. Nothing really spectacular wrong with this yet. The problem arises when you consider that all phases are usually impacted and budgeted separately. You can not know how long Construction will take until the Specification guys are done.
But in the real world you have to manage your resources, so once your impact and estimates for the Specification phase are done, you have to make reservations for the Construction guys to actually code your project.

With that reservation in place, there is now a very big incentive to have that phase finished by that time, because the penalty for not finishing in time are that a whole development team is twiddling its thumbs. When it comes to making decisions that might delay the current phase, even though it might save hundred of hours later down the line are now surprisingly hard. A project manager's first priority is delivering his particular part of the chain on time.
This is hard to spot though, because the next phase will look at the deliverables of the previous phase and if there are any defects or inefficiencies they will just plan and budget accordingly. This hides (most of) the real pain. Usually the only performance metrics that are used are if you delivered your part in time. Not if the overall project went smoothly.

With no focus on the total project costs, including maintenance, it is no surprise that a lot of these projects eventually run very late and get more and more expensive as they go along. So if you absolutely have to do waterfall, at least make sure that if ever a decision comes up about when to fix or improve something the answer can not be anything but: "Right now!"

Comments (1)

  1. [...] in detail up front. It’s actually not a project yet, so not all Waterfall vs. Agile flamewars [...]

Add a Comment