After leading or advising on more than a dozen Agile transformations across European financial institutions — banks, insurers, asset managers, and payment processors — I have noticed that the ones that struggle do not fail because of poor sprint rituals or misconfigured Jira boards. They fail because of decisions made, or avoided, in the ninety days before the first PI Planning session is ever called.
This post is about those decisions: the structural choices, the political landmines, and the organisational antibodies that determine whether an Agile Centre of Excellence becomes a genuine capability multiplier or an expensive consultancy wrapper that everyone quietly routes around.
The Structural Pattern: Sponsorship Without Mandate
The first pattern I see repeated, almost without exception, is the confusion between sponsorship and mandate. A C-suite sponsor is not the same as an organisational mandate. A sponsor attends the kick-off, champions the initiative in Town Halls, and approves the budget line. A mandate is the formal, written authority for the CoE to challenge delivery structures, realign funding flows, and require portfolio-level visibility from business units that would rather operate as black boxes.
Without mandate, the CoE operates by persuasion. Persuasion works until it meets a Head of Retail Banking who has been running the same waterfall delivery model for fourteen years, hitting his cost targets, and has no incentive to expose his programme to cross-portfolio scrutiny. At that point, the Agile Transformation team gets a polite email about "alignment workshops" and effectively freezes.
"A Centre of Excellence without written mandate is a consulting team with good intentions and no leverage. The transformation stalls at precisely the point where it matters most."
The fix is unglamorous: before a single coach is hired, the transformation lead must negotiate and document the CoE's authority. This means explicit answers to three questions:
- Can the CoE block programme gate approvals if Agile maturity criteria are not met?
- Can it require access to delivery data from all lines of business within scope?
- Does it have a seat at the capacity and funding table for the annual planning cycle?
If the answer to any of these is "it depends" or "we'll cross that bridge when we come to it," the transformation is already in trouble.
The Coaching Model Trap
The second recurring failure is what I call the coaching model trap. Organisations hire excellent Agile coaches — often experienced SAFe Practice Consultants or ICAgile practitioners — and then position them as trainers rather than change agents. The coaches run PI Planning events beautifully. The retrospectives are textbook. The Scrum of Scrums is facilitated with precision. And three quarters later, nothing structural has changed.
Rotating coaches across teams every quarter prevents the deep organisational knowledge needed to identify systemic impediments. It also signals to teams that the transformation is a programme, not a permanent capability — so they invest accordingly (minimally).
Coaches are most valuable when they are empowered to surface systemic impediments to senior leadership and expect those impediments to be actioned. This requires:
- A direct reporting line from the coaching practice to the transformation sponsor — bypassing the programme management layer that has every incentive to downplay problems
- An impediment register that is reviewed at C-suite level monthly, not just in the CoE's internal standups
- Explicit permission to be uncomfortable — to surface the conversations about team structures, incentive misalignments, and budget rigidity that middle management would prefer to defer
The Metrics Mirage
The third failure pattern is the metrics mirage: measuring Agile adoption rather than business outcomes. Velocity is reported. Sprint completion rates are tracked. Team health surveys are administered quarterly. Leadership feels informed. But the underlying questions — are we delivering customer value faster? are we reducing time-to-market for regulatory changes? are we building the optionality to respond to competitive moves? — remain unanswered.
The 90-Day CoE Foundation: Three Non-Negotiables
Based on the patterns above, here are the three things a CoE must fix in its first ninety days — not the first programme increment, not the first transformation review, but the first ninety days. After that, the structural mistakes become load-bearing: teams have been organised around them, middle managers have found their workarounds, and the political cost of correction rises sharply.
A Note on Financial Services Specifically
Financial institutions present a particular challenge because they operate under a model of continuous regulatory change that creates a structural tension with Agile principles. The backlog is never truly prioritised by business value alone — a PSD3 implementation or an ECB model validation change can arrive with a hard deadline and consume forty percent of engineering capacity regardless of what the product teams thought they were doing this quarter.
The Agile frameworks that work in this environment are those that explicitly accommodate regulatory work as a first-class citizen of the planning process — not as an unplanned interrupt that breaks the sprint, but as a predictable capacity allocation that gets sized, sequenced, and tracked alongside product work.
Build a "Regulatory Sprint" allocation into your capacity model from day one: typically 20–35% of team capacity reserved for compliance and audit obligations. This is not waste — it is honest planning. Teams that pretend this work doesn't exist simply carry it as hidden technical and compliance debt until it surfaces as a crisis.
Pair this with a regulatory backlog owned jointly by Legal/Compliance and the delivery teams — not thrown over the wall, but groomed collaboratively so that engineers understand the intent behind the obligation and compliance officers understand the technical complexity of meeting it.
The best Agile CoEs I have seen in European banking don't try to eliminate regulatory interrupts. They make them legible — sized, visible, and owned — so that the organisation can make conscious trade-off decisions about capacity rather than pretending infinite elasticity exists until it demonstrably doesn't.
The Uncomfortable Truth
Most Agile transformations don't fail because the teams aren't trying. They fail because the structural environment makes agility impossible — and the transformation programme is designed to train teams to be Agile within that environment, rather than to change the environment itself.
A CoE that focuses its first ninety days on mandate, metrics, and one visible structural fix will do more for an organisation's long-term agility than two years of coach rotations and framework certification programmes. It's less visible, less photogenic, and considerably harder. It is also the only thing that actually works.