You've seen this before. Maybe you've lived it.
A large organisation decides it's time to transform. Leadership brings in consultants, adopts SAFe, reorganises teams into ARTs, hires RTEs, trains hundreds of Scrum Masters and Product Owners, runs PI planning every quarter. On paper, everything looks right.
But something doesn't add up. Work still moves sequentially through siloed departments. Releases still take six to nine months. Teams spend weeks preparing for PI planning, only to produce plans that unravel within days. Architects design systems in isolation, disconnected from the teams building the product. The business sits somewhere on the other side of the organisation, and nobody quite knows how to bridge that gap.
The ceremonies are happening. The framework is in place. And yet — nothing has fundamentally changed.
I've been in that organisation. I've had those conversations. The scene above is real.
The incentive problem
Before we diagnose what went wrong, we need to be honest about something uncomfortable — including those of us who have worked as agile consultants.
When a transformation begins, success is typically measured by adoption metrics: how many ARTs have been established, how many people have been trained, how many ceremonies are being held. Consultants and internal transformation leads have a clear incentive to declare victory once the framework is in place. And in organisations hungry for visible progress, that declaration often comes too soon.
Nobody is necessarily acting in bad faith. But the system creates perverse incentives. The consulting firm gets paid for rollout, not outcomes. Internal champions get rewarded for adoption speed, not organisational health. Leadership receives dashboards full of green indicators while the actual problems remain untouched beneath the surface.
The result is transformation theater: the costumes and the stage are in place, but the fundamental play hasn't changed. When results don't materialise, the organisation concludes that agile doesn't work. The real problem — that the structural changes were never made — stays invisible. The consultants move on.
What agile was actually about
To understand how large organisations went wrong, it helps to remember where agile came from.
In the early 2000s, agile was a grassroots movement. It didn't start in boardrooms or consulting firms — it started with developers, testers, and product people who were frustrated with how software was being built. They understood something crucial: the old way of working, with long planning cycles and late feedback, was fundamentally broken. By the time you delivered something, the world had moved on.
The insight at the heart of early agile was simple but profound: bring together the people who understand the business and users with the people who can actually build the product, give them the conditions to work closely together, and create tight feedback loops so you learn fast and adjust constantly. Technical craftsmanship wasn't optional — it was the enabler. You needed excellent engineering practices so you could ship frequently, learn from real users, and adapt without accumulating crippling technical debt.
It was about building a learning system, not following a process.
How large organisations broke it
When agile moved into large organisations, it typically arrived as an IT initiative. The development department would "go agile." Business stakeholders would remain on the other side of the organisational wall, submitting requirements and waiting for delivery. The tight feedback loop between market, users, and builders — the very core of what made agile valuable — was severed from the start.
Then it was handed to people who didn't fully understand the technical reality of what they were transforming. Process consultants who had never shipped software. Newly certified coaches who understood ceremonies but not system architecture. Senior architects who designed in isolation, rarely hands-on with the actual product.
The result was agile stripped of its two essential ingredients: the business-user connection and the technical depth. What remained was a purely organisational process — rituals without substance, frameworks without understanding.
Organisations that built ARTs across deeply siloed departments discovered what Conway's Law predicts: your system architecture mirrors your organisational structure — communication problems included. ARTs layered on top of siloed departments don't produce integrated delivery. They produce integrated-looking ceremonies that generate the same siloed output as before. Reorganising the boxes on the org chart without changing the underlying communication structures just adds a new layer of coordination overhead on top of the old problems.
The agile ceremony doesn't fix the silo. It just gives the silo a new set of meetings.
"That only works for small organisations"
When I describe what good product development looks like, the response is almost always the same.
"That only works for small organisations. We're too large and complex for that."
I've heard this so many times I've started to think of it as the last line of defence. As long as you believe scale makes these conditions impossible, you never have to try.
But the claim doesn't hold up. The structural conditions that make product development work aren't a small-company luxury. They're a choice — an uncomfortable one, because it requires genuinely redistributing authority and dismantling the structures that gave large organisations their sense of control. The organisations that have succeeded at building these conditions at scale have done so by making exactly those choices. The ones that haven't are the ones still saying it can't be done.
What the conditions actually are
What makes product development genuinely work isn't a methodology. It's a set of structural conditions:
- People who understand users and people who build the product working together, toward the same goal, with genuine shared authority over the outcome.
- Technical excellence treated as a competitive requirement — not a preference, not a nice-to-have.
- Teams structured to own the full chain: from understanding the problem to shipping the solution.
- Leaders who actively remove obstacles rather than add process.
These are the conditions agile was trying to create. The ceremonies were always meant to help create them — not to substitute for them. When you implement the ceremonies without the conditions, you get the form without the function.
There is no shortcut
There is no framework that, once implemented, will make a complex organisation suddenly healthy. Anyone telling you otherwise is selling something.
Real improvement means understanding your specific organisational problems — not applying a generic template. It means leaders willing to look honestly at how their organisation actually works, not how it looks on a dashboard. It means making structural changes that are genuinely difficult: breaking down silos, changing incentives, redistributing decision-making authority, investing in technical foundations that don't show up in a quarterly report.
And it means recognising that this isn't a project with an end date. Building an organisation that learns continuously and improves is a permanent leadership responsibility. The question isn't "how do we complete our transformation?" — it's "how do we keep getting better?"
Better questions
Stop asking
"Are we doing agile correctly?"
Start asking
- Do we understand our users continuously — not through requirements documents, but through frequent, direct contact with the people using what we build?
- Are we learning fast enough? When we ship something, how quickly do we know if it worked? How quickly can we adjust?
- What is actually slowing our teams down? What technical debt is accumulating? What organisational friction is in the way?
- Is leadership actively removing obstacles — or just monitoring them?
These questions are uncomfortable precisely because they expose real problems rather than measuring proxy metrics. That discomfort is the point.
The ceremonies are not the destination. They're a vehicle. Where they take you depends entirely on whether the organisation is willing to tackle the structural changes that make them work.
Those changes are hard. They challenge who has authority over what. They require leadership to give up some control in exchange for better results.
But that's what it actually takes. Everything else is theatre.