Yes, you read that right. If you’re surprised, you might have listened too much to the Agile evangelists. Let’s face it: learning about so-called waterfall methods from them is basically like learning the history of Israel from the skinheads. Get some soda and popcorn, and read along, we’ll get to the bottom of this.
A Brief History of Waterfall
The term “waterfall” was coined to describe a purely sequential approach to software development, a method taken straight from the construction industry. First, you gather requirements about what to build, then plan, design, obtain permits, construct, get formal approvals, and eventually hand over to the occupants. The key characteristic of the process is that each phase must be completed before the next one. On a Gantt chart, this looks like a waterfall, hence the name.
Sequential phases make a lot of sense in construction. You can’t start building unless you have a permit and to get one you have to present the design. If you want to change something, you need to submit paperwork and obtain a permit. In other words, the domain of construction, with its safety regulations, enforces big design up-front, formal change control, and phased development.
The field of software development is still a very young discipline. Like every other field, it developed first through imitation of its more mature counterparts. The term such as “software architect” or “software developer” reflect that. This is also why early software development methodologies were essentially copied and pasted, without much adaptation for the unique specifics of the software world.
The Big Lie
When Winston Royes introduced the infamous “waterfall model” he only did it as an example of what will definitely not work in software development. Yet he was wildly misquoted as a proponent of it. Truth is, there was never any pro-waterfall movement. There was no Waterfall Development Institute, awarding Certified Waterfall Developer credentials. There was no Waterfall Conference, where enthusiasts of phased development congregated, to share jokes about Scrum.
People applying classical waterfall model to software development exist mostly in the tales of agile evangelists. The big lie is that every method without an “agile” stamp on it is essentially equal to a waterfall. Therefore, propagandists argue, your only option is to go agile. Agile, on the other hand, is a silver bullet that solves all the problems automagically.
This propaganda inflicted real damage. Throughout my entire career, I’ve seen a lot of flawed “agile” setups. I’ve seen PMs trying to deliver a fixed-priced contract with just scrum, with absolutely no control over scope, schedule, and budget. There was a lot of scrumbuts. I’ll never forget a kanban with no WIP limit, no continuous improvement, with work delivered in pretty big batches (yeah, a that’s essentially a hot dog without sausage and a bun). I’m sure you all have some examples to add in that category.
Waterfall Works Great
Big Design Up Front approach (BDUF), contemptuously called waterfall, can bring great value if it is used right. Compare Frankfurt and Munich airports. The first one is a result of “agile” development, with multiple increments being added over time, whereas the second one was carefully designed up-front, and then developed within the frames of the original masterplan.
But that’s construction, you might say. Ok, let’s look at software development then. Do you know how Linux is being developed? Or Windows? How about Google Search? Do you know the story behind git? There’s a lot of interesting literature about all that and while you can find some “agile philosophy” in it, there is close to zero Scrum, Kanban, SAFe or LeSS. There are however big designs up front all over the place.
In fact, the world is full of examples of great innovations in the software industry that was straight BDUF. Many of them were made by a small team of smart guys that didn’t see much value in asking people every two weeks if they are going in the right direction. They pitched the idea with their bosses or volunteered their private time, and developed for months without any sprint reviews or continuous delivery.
You use the results of their work every single day.
Don’t get me wrong. I’m not saying agile is wrong and BDUF is great. Both could be great when used right, and in fact, many successful projects I’ve seen is a mixture of both approaches. I believe that a mature manager should always be learning about methods outside of his comfort zone. And look beyond marketing or anecdotal evidence of superiority.