The first two posts were about agile fundamentals - iterative delivery, MVPs, learning fast. This time, let's talk about when that approach is completely wrong.
These two videos from Development That Pays do a brilliant job explaining when waterfall makes sense:
My Dad... The Agile Coach?!?
https://www.youtube.com/watch?v=502ILHjX9EE
Agile vs Waterfall: Waterfall Wins!
https://www.youtube.com/watch?v=eZXP7LM-OAA
The key insight: it's not about being "pro-agile" or "pro-waterfall" - it's about matching your approach to the problem.
In 2014, I was working on a factory move. We were designing a new facility from scratch - layout, equipment placement, material flows, the works.
You don't iterate a factory floor.
Once you hand drawings to a building contractor, they're building walls. Installing electrical supplies. Laying foundations for specific equipment. You can't experiment your way through that. You can't ship an MVP factory and see what users think.
The physical constraints forced waterfall planning.
But we still found ways to learn before committing.
We produced CAD files modelling material flows. We could experiment with different layouts digitally - move equipment around, test different workflow patterns, measure distances and bottlenecks.
We ran small-scale experiments in the existing factory. Tested different physical workflows with actual operators. Learned what worked and what didn't before designing the new space.
We went to trade shows. Visited other factories. Talked to people who'd done similar moves. Gathered as much information as we could before committing to a specification.
And we built in flexibility where we could. We installed a large grid above the factory floor - a structured way to run services and utilities. If we needed to move equipment later, we wouldn't have to rip up foundations and rewire everything. We could adapt.
This was three years after I'd got my PRINCE2 certification. I knew the formal waterfall methodologies - the stage gates, the documentation, the upfront planning. But the factory move taught me something the certification didn't: waterfall doesn't mean no learning. It means finding every opportunity to learn before you commit, and building in flexibility where you can.
A few years later, we were working on a database restructure. We had a table that had grown too large and was causing locking issues. This database serviced multiple systems across the business.
We started agile. Teams would take stories into their sprints. We'd tackle the restructure incrementally, system by system.
It broke immediately.
The changes were breaking changes. You couldn't migrate one system without affecting the others. Dependencies were everywhere. One team's sprint work would invalidate another team's assumptions.
We pivoted to a rigid plan and schedule. Every team needed to coordinate their changes. We needed a specific sequence - this system first, then that one, then the next. All at once, during a maintenance window.
We'd tried to be agile about something that had fixed dependencies. It didn't work. So we switched to waterfall and executed the plan.
I've worked on banking integrations where security and accuracy requirements meant there was no room for learning in production.
We could test extensively in test environments. We could iterate there. But the production deployment had to be complete and correct.
You don't ship a "learning version" of a payment integration. You don't experiment with moving money between accounts to see what happens. You ship something that works correctly, securely, and completely the first time.
The MVP has to be pretty complete when financial transactions and security are involved.
The trap is using "we need to plan this properly" as an excuse to avoid starting.
Waterfall makes sense when:
Waterfall is being misused when:
I got my PRINCE2 certification in 2011. Learned the methodology, the processes, the stage gates, the documentation requirements. All the formal waterfall practices.
But the factory move in 2014 taught me something the certification didn't: knowing the methodology isn't the same as knowing when to use it.
Physical buildings forced waterfall. Breaking database changes revealed hidden dependencies that required coordination. Financial systems had regulatory constraints that prevented experimentation.
These weren't methodology choices. They were genuine constraints that made sequential delivery the only sensible option.
I'm currently working on an enterprise system implementation. Some parts are genuinely waterfall - data migration has fixed dependencies, banking integration can't be tested in production. Those constraints are real.
But other parts? We're prototyping workflows, testing assumptions in development environments, getting feedback where we can. Finding the spaces where we can learn before committing.
The question that matters: am I planning because I must, or because I'm avoiding uncertainty?
Watch the videos: