Why Agile Transformations Keep Failing: It’s Not the Framework, It’s the Follow-Through
- Darren Emery
- Nov 3
- 7 min read
When a COO tells me their “agile transformation failed,” the story usually starts with optimism: expensive consultants engaged, frameworks deployed, teams reshuffled. Six months later, velocity plateaus, cynicism spreads, and “agile” becomes the subject of cynical jokes beside the coffee machine.
According to McKinsey, 70% of agile transformations fail to achieve their stated objectives, often within just 18 months. The cost isn’t just financial; it’s the collapse of trust that cripples any future change effort.
Yet the common response to this failure is not to step back and examine the root cause.
Instead, organisations tend to double down on process - searching for the next framework or the better tooling - rather than asking the harder question: Why didn’t the organisation actually change?
This pattern of failure is especially costly for mid-to-large enterprises. A failed transformation doesn’t just mean wasted money; it means losing competitive speed, watching crucial talent leave, and destroying the executive credibility required to push any future change initiative. While competitors are accelerating their market feedback loops, the organisation stuck in "agile theatre" is crippled by internal cynicism and fatigue.
Transformations: Implementation Projects in Disguise
The quiet truth is that most so-called “transformations” are actually implementation projects in disguise.
They focus intently on installing a framework, like SAFe or Scrum, which is a visible, tangible, and easily measured activity. Leadership can check the boxes: Teams trained? Yes. Backlogs created? Yes. Ceremonies run? Yes.
However, installing a framework does not constitute transformation. Frameworks help you manage complicated work - structured but predictable. Real transformation is about designing an organisation that can operate effectively in complex environments - adaptive, emergent, and continuously learning.
Most enterprises confuse the two and optimise for control, not adaptation.
Transformation requires fundamentally changing how work is prioritised, funded, and learned from at the executive and governance levels. When the focus remains on the activity of implementing a process rather than the outcome of reprogramming the organisation’s core systems, failure is (in my experience), guaranteed from the start.
The Absorption Problem: Culture Eats Frameworks for Lunch
You can’t just pour new, flexible methods into old, rigid “organisational containers”.
As management thinker Peter Drucker famously warned, “Culture eats strategy for breakfast.” But in truth, it also eats frameworks for lunch.
At Agilicist, we call this the absorption problem: when the organisation’s existing incentives, governance, and decision rhythms quietly absorb and neutralise the intended change, turning revolutionary principles into bureaucratic overhead.
Case Study: How a Fintech Absorbed its Framework
We saw this first-hand with a major UK fintech we supported last year. They’d rolled out a scaled agile framework across 300 odd engineers. On paper, they were perfect: the ceremonies were in place, the tooling looked impressive, and every team had a Scrum Master. But nothing was moving faster.
Deeply entrenched organisational habits had neutralised the change:
The backlog had ballooned because prioritisation still happened outside the teams, in a political committee.
Delivery decisions still bottlenecked in a centralised Project Management Office (PMO).
Dependencies multiplied because funding was still allocated to siloed departmental budgets, not cross-functional product lines.
The teams were doing agile, but the organisation was still governing waterfall. Instead of a second, more complicated framework rollout, we helped them rebuild how work flowed through the system:
We repositioned funding from temporary projects to persistent product lines.
We shifted governance to focus exclusively on customer outcomes, not internal activity reports.
We installed feedback loops so decisions traveled as fast as the data.
Six months later, lead time - the time from idea to validated customer impact - dropped by 42%, and teams started owning decisions rather than waiting for permission.
What changed wasn’t the teams’ process - it was leadership’s principles. Once executives stopped trying to control delivery and started redesigning the system itself, momentum returned.
The Hidden Operating System: Three Pillars of Organisational Change
Frameworks only operate on the surface layer - the rituals, roles, and artifacts. The real transformation happens when you reprogram the organisational “Operating System” (oOS).
This oOS is defined by three fundamental pillars, each controlled by executive leadership:
1. Decision Rights: Who Can Say ‘Yes’ and ‘No’?
In a traditional enterprise, most decision rights are centralised. Every meaningful change - a scope modification, a budget increase, or a new technology choice - must be escalated. This centralisation is the single greatest bottleneck to speed.
Reprogramming this pillar means shifting from centralised approvers to decentralized accountable decision-makers.
For example, Product Owners or persistent product line leaders should be empowered to manage the trade-offs within their established quarterly budget and outcome goals. The executive oversight shifts from reviewing individual feature changes to confirming the overall strategy and ensuring the decentralised decisions align with the strategic objectives. If a team has to wait three weeks for a steering committee to approve swapping Feature A for Feature B, you don't have an agility problem; you have a trust and decision rights problem.
2. The Funding Model: Allocating Capital to Outcomes
The most potent organisational habit that inhibits agility is the annual, project-based budget cycle. Project funding, which is fixed-scope, fixed-budget, and temporary - creates a perverse incentive for teams to hide problems and for managers to hoard resources until the next budget battle.
Reprogramming this pillar means moving to Product-Based Funding (PBF).
PBF allocates a stable capacity (money for a persistent, cross-functional team or teams) to a long-lived product or value stream. The conversation shifts from, “How much will this project cost?” to, “What outcomes can this stable team achieve for this investment over the next quarter?” Stable teams with stable funding are incentivised to optimise the entire system, reduce internal handoffs, and focus on long-term value creation.
3. Feedback Loops: How Quickly Does Learning Travel?
Agility is not about being fast; it’s about being fast to learn and adapt. If your primary feedback loop is the annual budget review or the quarterly performance review, your organisational OS is running too slowly to survive in a rapidly changing market.
Reprogramming this pillar means linking market data directly back to investment decisions.
This requires technical agility (continuous deployment and robust metrics) coupled with executive discipline. Every governance meeting must focus on validated learning: What changed in customer behaviour last week? Did the feature we shipped move the outcome metric? When learning travels instantly back to the people who control the investment (the C-suite), strategy can pivot monthly, not yearly.
The Executive's Role: Shifting from Delegate to Designer
This organisational reprogramming is the exclusive mandate of COOs, CTOs, and CIOs. Agile transformations fail when executives treat them as implementations to be delegated to middle management or a consulting firm. Success requires the C-suite to become the Chief Architects of Organisational Design.
The C-suite can’t delegate transformation because the real levers - decision rights, funding, and feedback - sit within their authority. Transformation isn’t about delegating change; it’s about redesigning power.
The hardest part of that design is rethinking risk. Too many enterprises still treat risk as something to be avoided, not understood. The predictable result: slow-moving, over-governed initiatives that fail too late and too expensively.
Agility flips that logic. It’s about exposing risk sooner, learning cheaply before failing expensively. The executive’s role isn’t to eliminate risk but to design for it, creating conditions where fast, low-cost learning replaces slow, high-cost collapse. That pivot - from risk avoidance to risk design - is often the single biggest determinant of whether transformation takes hold or fails.
Three Actions for Executive Leaders
If you are a COO, CTO, or CIO preparing for or struggling with a transformation, focus your executive efforts on these three foundational actions:
1. Audit the Decision Flow, Not Just Delivery Flow.
Map how long it takes a decision to move from identification (e.g., “We need to address X security vulnerability” or “The market segment Y is shifting”) to action. Conduct a Value Stream Map for your top 5 most critical strategic decisions. That time delay - the waiting, the handoffs, the committee reviews - is your organisation’s real velocity. If it takes six weeks to get approval for a change that takes two days to code, the six weeks is your problem.
2. Rebuild Governance Around Outcomes.
Stop measuring activity. Activity metrics include things like "percentage of features launched," "number of story points delivered," or "budget spent." None of these guarantee value.
Instead, rebuild every steering meeting to focus on Outcome Metrics. Make every governance conversation start with the question: “What changed in customer behaviour this week?” Focus on measurable business results, such as "increase customer retention by 10%," "reduce service desk tickets by 25%," or "increase market share in segment Z." When outcomes are the only currency, every decision aligns around value.
3. Treat Frameworks as Stabilisers.
Frameworks are excellent scaffolding: they provide shared language, standardised roles, and a starting point to stabilise early momentum. But they are not structures. If you leave the scaffolding up forever, you end up with an ugly, rigid building that cannot adapt.
Use the framework to build a rhythm, a cadence, and a culture of feedback, and then begin to remove its restrictive elements as teams build their own rhythm, tools, and expertise. The goal is not compliance to Scrum or SAFe; the goal is a self-designing organisation that continuously inspects and adapts its way of working to maximise its flow of value.
When executives understand that agile frameworks are scaffolding, not structures themselves - and they shift their focus from implementing process to reprogramming the organisational OS, the 70% failure statistic starts to look less inevitable and more like a simple matter of executive follow-through.
The Path Forward: Stop Implementing, Start Designing
Reprogramming an organisational OS - dismantling decade-old systems of funding and control - is the hardest, yet most necessary, work of a true digital transformation. It is the exclusive mandate of executive leadership.
At Agilicist, this is precisely the work we specialise in. We have moved beyond the failed framework rollouts to rebuild the underlying decision, funding, and feedback mechanisms for major enterprises. We have seen what works, and what doesn't - when transitioning from Project Governance to Product Outcomes.
If you’re tired of agile theatre and ready to design a truly adaptive organisation, we’d love to help you rebuild the OS that makes agility real.
