“Waterfall” comes up a lot in my line of work: talking with orginizations about how to do software better. People like myself take the definition of “waterfall” for granted and usually don’t spend too much time talking about it, let alone when it might be a good idea of how to do it well.
Someone asked me the simple question “what is waterfall?” as a follow-up to one of my talks recently. Here’s what I typed back:
Usually when people (like me) use the term “waterfall” we mean two things:
- A phased, linear process of specifying, designing, writing, testing, and deploying software. What’s key is that you can’t go “back” and redo each step: hence the waterfall (going up a waterfall is like trying to walk up a down escalator).
- Long release cycles, on the order of 6+ months, if not 12 to 36 months.
In both of these, we’re focusing on the end-to-end time to takes from coming up with the software to deploying it production where actual end-users can use it. This is worth calling out because just creating a build that could be deployed is just art of that cycle.
In waterfall process, you’re strongly encouraged to keep the requirements fixed. If you change or add requirements mid-waterfall, the schedule is effected: you either lengthen it, or you have to remove other requirements. Depending on how requirements have been implemented, removing requirements may not work too well: you might have to rip and replace no longer needed code, or rewrite code to match new requirements. The result is often being late and over-budget.
Agile advocates would also add that you’re building up a lot of “risk” when you wait so long to deploy: until actual end-users have and are using your software, you have no idea if it truly works or if it’s actually useful.
“Waterfall” is largely a straw-man, bogeyman even. In practice, it more means long release cycles and a belief in hitting unrealistic schedules with a fixed set of requirements. In truth, you can look at the release cycle of most agile practices as “tiny waterfalls,” ones that last 1-2 weeks.
Shortening the release cycle has profound effects on the overall quality (as in usefulness) of the software and has also been shown to increase the chance of overall delivery success. Speaking in very broad terms, the other parts of Agile-think that are different than waterfall are: an emphasize on learning (a la continuous learning from Lean Manufacturing) over knowing and, therefore, specifying all requirements up-front.