Walk into any large organisation and ask how they deliver change. You will hear two answers, often in the same breath. “We’re agile now.” And then, a moment later, “but the regulatory programme is running waterfall, obviously.”
That second sentence is the one worth paying attention to.
For the last decade, the conversation about delivery methodology has been framed as a transition. Waterfall was the old way. Agile was the new way. The journey was from one to the other, and the destination was a fully agile organisation where everything happened in two week sprints and Gantt charts were quietly retired.
The reality on the ground looks nothing like that.
The work is not the same shape
The reason agile and waterfall both persist is simple. Different work has different shapes.
A new mobile feature, where you can ship, measure, learn and iterate, is genuinely well suited to agile. Small batches, fast feedback, continuous discovery. The cost of being wrong is low and the cost of waiting is high.
A core banking migration, a data centre move, a regulatory compliance programme with a fixed external deadline, a building fit out, a hardware rollout across two hundred sites. None of these benefit from “we’ll figure it out as we go”. They need sequencing, dependencies, critical path, fixed scope at fixed dates, and a plan you can defend to a regulator or an auditor.
Pretending otherwise has caused real damage. Plenty of organisations have tried to force structured, dependency-heavy work through an agile lens and ended up with neither the discipline of waterfall nor the responsiveness of agile. Just a lot of standups about pouring concrete.
The portfolio is always mixed
Even organisations that have genuinely transformed their digital delivery still run mixed portfolios. The product squads work in flow. The infrastructure team works in releases. The compliance programme works to a date that was set by someone in Brussels. The M&A integration runs to a board commitment.
A portfolio leader has to see all of it. Resource capacity, benefit realisation, financial forecast and risk exposure do not care which methodology a piece of work happens to be using. The CFO wants to know what the total spend looks like next quarter. The exec wants to know whether the strategic outcomes are on track. The PMO wants to know where the bottlenecks are.
If your tooling forces you to pick a side, you end up with two systems, two sets of numbers, and an analyst whose full time job is reconciling them. That is not a delivery model. That is a tax.
What good support for both actually looks like
Supporting both methodologies properly is more than putting a Kanban board next to a Gantt chart and calling it a day. A few things matter.
Work needs to be modelled honestly. A sprint backlog item and a milestone are not the same thing, and squashing them into a single concept loses information that matters. But they do need to roll up into the same portfolio view, the same benefit lines, the same financial forecast.
Teams need to work in their native style. Asking an agile team to maintain a parallel waterfall plan for the PMO’s benefit is how you get plans that are out of date the moment they are saved. Asking a programme manager to retrofit a multi year regulatory plan into two week sprints is equally absurd.
The portfolio view needs to be methodology-agnostic. Capacity is capacity. Benefit is benefit. Spend is spend. The view the exec sees should not depend on how the underlying team chose to organise their work.
And the data model needs to flex without forcing a choice. A project might start life as a discovery initiative running in flow, then move into a structured delivery phase with fixed milestones, then settle into a run-and-maintain mode. Real work does not stay in one methodology for its whole life.
The pragmatic position
The honest position, after years of watching this play out, is that the methodology debate was always slightly beside the point. The point is delivery. The point is outcomes. The point is being able to answer the questions the business is actually asking.
Some of those questions are best answered by an agile team iterating quickly. Some are best answered by a programme manager with a critical path. Most large organisations need both, working alongside each other, rolling up into a single coherent picture.
The organisations that have made peace with this are getting more done. The ones still arguing about which methodology is correct are spending more time on the argument than on the work.
Pick the right tool for the job. Build a portfolio view that can hold both. And get on with delivering.
