If you get into any kind of open forum discussion regarding the benefits of more agile or more lean approaches to traditional software development, it’s not uncommon for someone to say that the problems organizations experience with Waterfall are largely because they aren’t doing Waterfall right (incidentally, this is also what most of the Scrum folks say when organizations experience problems doing Scrum, but I digress). The idea is that, if organizations were disciplined and knowledgeable enough to implement Waterfall properly, the way it was designed, that most or all of the high risk issues in Waterfall wouldn’t be issues.
It reminds me of martial arts forums. Someone will post twenty videos of Bad Won Do practitioners getting their tails kicked, and someone will comment that what they’re doing isn’t “real” Bad Won Do. “Real” Bad Won Do is actually quite effective (and apparently undocumented) and, if they’d just do the real stuff right, they’d be powerhouses.
But here’s the thing. Even if you did Waterfall with 100% perfect execution, it remains an extremely high risk, high fail project delivery methodology.
1. Testing Comes Too Late in the Process
Winston Royce, the man who brought a lot of visibility and popularity to phase-gate approaches to software development (and accidentally contributed to the success of Waterfall) wrote this in “Managing the Development of Large Software Systems:”
The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a l00-percent overrun in schedule.
In other words, since you’re testing the whole system at the end, you run a very high risk of major rewrites to fix issues. This is Waterfall done right.
2. Value delivery comes at the end.
You release at the end of the project. Nobody gets any value out of your work until everything is done. This is a huge risk for a number of reasons.
First of all, the project might not get done. In fact, many projects meet this fate. Funding runs out. Priorities change. Dissatisfaction with the vendor. When this happens, the business is often left with nothing. They just eat the cost of a ton of work that got them nothing but stacks of documentation and some half-baked code. Since value wasn’t delivered incrementally, they have nothing.
Second, there is an enormous risk that what was valuable nine months ago is no longer valuable, either due to changes in the business or just the fact that the value of requests expires over time. It would have been useful when it was requested, but not nearly as useful now.
Third, the funder of the project has no real option but 100% success or 100% failure. You either get everything, or you get nothing, and this leads to some very unhealthy decisions like sticking with a vendor who isn’t performing or continuing to pump funding into a project that should have been abandoned or thoroughly revised months ago.
This is Waterfall done right.
3. Waterfall is predicated on a faulty premise.
Waterfall assumes that I can fairly accurately predict timelines and resource needs for a project that will involve several people extending over a large amount of time. The entire notion of a phase-gate approach like Waterfall is the idea that I can get all the requirements, lock those down, do all my design, etc. And all the trappings of my project management revolve around this presupposition.
And this might have a glimmer of hope to it if software requirements were cookie-cutter kinds of things that all required the same resources, same effort, same complexity, same outcomes. But as we know, software development is way, way more variable than that.
Can you imagine a general making a battle plan for a year long campaign and sticking to that plan the entire year? It doesn’t happen. Yes, having a plan is important, but the plan has to be intrinsically adaptable because conditions on the ground are changing. Some are predictable, some aren’t – the variables in war are endless.
I’m not saying software development is as volatile as war (most of the time), but the principle is very similar. I mean, what if I asked you to plan down to the hour your work days for the next year. Could you do it? What about the next month? Next week? I think you’d find this challenging, because each day of work brings up new variables, emergencies, challenges, etc. So, I ask you, if you couldn’t even plan the hours of your work week in advance, how realistic is it to assume that you can do that for several people, departments, and resources over the course of six months to a year and expect the outcome to still be relevant to all stakeholders?
This is Waterfall done right, and this factor is, I believe the most problematic, because it gives an illusion of certainty that does not actually exist.