The good parts of Waterfall
Waterfall SLDC gets a bad rap among most dev shops. Its reputation is that teams who use it are slow, bogged down by process, and can’t deliver great software. The reality of my experience is that in those three areas, at least, Waterfall has a lot in common with Agile. I’ve seen Agile teams crippled by overbearing process, and Waterfall teams executing efficiently, evolving processes, and delivering excellent products.
One might then argue “those Agile teams are doing it wrong”. I agree, but what about the Waterfall teams? No one told them they were doing Waterfall wrong by succeeding.
I am not arguing a return to Waterfall for most dev shops. The teams I’ve been a part of that have succeeded with Waterfall succeed because, in part, they had products, customers, and timelines that lent themselves to the design-first top-down approach (military and government contracts especially).
What Agile really tries to solve
Things are different in the business world where most developers live (including myself). We don’t have the benefit of a customer group that can comfortably wait two years while a product is designed and then another two while it’s built. We often lack requirements more specific than the hint of opportunity.
Internal enterprise shops suffer for similar reasons - they often lack product owners with the knowledge to define a feature from the top down. These shops don’t necessarily benefit from their comfortable perch within the enterprise - I’ve been on teams building products with no known users and no product ownership.
When people diss Waterfall in favor of Agile, they’re responding to how Agile copes better in the above situations. Agile’s effectiveness scales with the opacity present in business. When there’s more fog (in terms of missing features, owners, and customers), Agile does better, and Waterfall does worse. What Agile really tries to solve is people, specifically the difficulty in coming to the right decision the first time.
Business Fog (coining a new term here) exists because:
- it’s hard to find all the key decision makers, owners, and subject matter experts,
- much less get them in a room together,
- it’s difficult to get them agree to anything,
- or be honest with themselves about their motivations and visions for a given product.
If you’ve ever advocated for a technology, process, or product, you might interrogate your own motivations in bringing it up - did you read a blog post about it? Is that architecture what you used at your last job? Is that framework solving problems that plagued you on your last project?.
By the way, it’s ok to have conflicted motivations - no one is perfect. But this exercise should help the reader understand that everyone around the decision-making table will have their own invisible biases and motivations. They might not even be the right people to bring together to define a product.
Reality is chaos
The strength of Agile is that it accepts these human faults and accepts the chaotic reality of most businesses. Agile prioritizes the things that drive iteration and collaboration. It doesn’t mean that it will work, or even that it will be better than using Waterfall, but it probably stands a better chance in the living world of business.