I've sat through more methodology debates than I care to remember. Waterfall people say agile is chaos without a plan. Agile people say waterfall is a death march to obsolescence. Here's the thing: both are right about the other side and wrong about their own. The question isn't which methodology to use. It's whether you're willing to take the best of both, throw away the dogma, and actually start building.
The False Dichotomy
The software industry has turned methodology into identity. You're either a waterfall shop or an agile shop. You hire waterfall PMs or scrum masters. You follow PRINCE2 or SAFe. The frameworks come with certifications, consultants, and conferences. And somehow, despite all of this, the project success rates haven't meaningfully changed.
16%
of enterprise IT projects completed on time, on budget, and on scope in 2018
Source: Standish Group CHAOS Report, 2018
Sixteen percent. After decades of methodology refinement. That number should make everyone pause and ask whether we're optimising the wrong thing.
What Waterfall Gets Right
Waterfall gets vision right. Before you write a line of code, you know what you're building and why. You've defined the destination. You've agreed on scope. You've mapped the requirements. There's a plan, and everyone knows what it is.
This matters enormously for enterprise projects. When you're building something that needs to integrate with six existing systems, serve 500 users on day one, and meet regulatory requirements, you can't "figure it out as you go." You need strategic discipline. You need to know where you're headed.
What Waterfall Gets Wrong
Waterfall assumes the plan won't change. It assumes the requirements you gather in month one will still be right in month twelve. It assumes the world will hold still while you build.
It won't. User needs evolve. Stakeholder priorities shift. The market moves. New information surfaces. And waterfall has no mechanism for adjusting. The plan is the plan. Change requests are bureaucratic. By the time you deliver, you've built exactly what was specified and precisely what nobody needs anymore.
What Agile Gets Right
Agile gets feedback right. Build something small. Show it to people. Listen. Adjust. Repeat. The feedback loop is the single most valuable contribution agile has made to software development.
When you show working software to real users every two weeks, you catch problems early. You discover that the feature you thought was critical isn't, and the one you planned for phase three is needed now. You stay grounded in reality instead of building in a vacuum.
What Agile Gets Wrong
Agile, as practised in most organisations, has lost its way. The Agile Manifesto was 68 words of common sense written by people who were frustrated with bureaucratic processes. What it's become is a multi-billion dollar certification industry that's often as bureaucratic as what it replaced.
52%
of agile practitioners reported that their organisation's agile culture was at odds with the wider company
Source: VersionOne 12th Annual State of Agile Report, 2018
"We'll figure it out as we go" has become an excuse for not defining where you're going. Sprints become a rhythm without a destination. Backlogs grow endlessly because there's no overarching vision to filter them against. Teams ship increments that feel productive but never add up to a product with purpose.
And for enterprise, the problem is worse. Enterprise projects have constraints that can't be discovered iteratively. Compliance requirements. Integration dependencies. Organisational change management. Launching a vague "minimum viable product" into an organisation that needs a defined system on a defined date doesn't work.
The Third Option
At IDESIGN, we don't pick a side. We take what works from each.
From waterfall: strategic discipline. Before we write code, we establish a clear vision. What does success look like? Who are the users? What are the constraints? What's the destination? This isn't a 200-page requirements document. It's a shared understanding, tight enough to guide decisions and flexible enough to absorb new information.
From agile: dynamic delivery. Once we know where we're going, we build in stages. Short cycles. Working software in front of real users regularly. Genuine feedback loops. Not ceremonies performed for their own sake, but real conversations about what's working and what isn't.
The blend: vision with flexibility. Know the destination. Be flexible about the route. When new information arrives (and it always does), assess it against the vision, adjust the roadmap, and keep building. Not a change request process that takes three weeks. A conversation that takes thirty minutes.
The best projects I've been part of had the strategic clarity of waterfall and the feedback loops of agile. The worst had the rigidity of waterfall and the aimlessness of bad agile. Know where you're going, then stay close to the people you're building for.
Tim Hatherley-Greene
Chief Operating Officer
Why This Matters for Enterprise
Enterprise projects are uniquely badly served by methodology dogma. They're too complex for pure agile's "discover as you go" approach. They're too long-running for waterfall's "plan everything upfront" approach. They need both. Vision and feedback. Direction and adaptation.
The organisations that get this right don't ask "are we agile or waterfall?" They ask "do we know where we're going, and are we getting feedback fast enough to stay on course?"
That's the question that matters. Stop debating methodology. Start delivering outcomes.