Most banking agile transformations don’t fail because of a lack of ambition. They fail because the dependency and alignment issues identified at the outset remain unresolved, only to become buried beneath more governance, more ceremonies, and more expensive tooling.

I’ve spent the better part of a decade leading large Agile transformations inside Tier-1 banks, and the pattern is remarkably consistent. Teams diagnose their problems accurately from day one. What separates the transformations that compound value from the ones that plateau isn’t the quality of the diagnosis. It’s what happens the day after.

The Productivity Gap Organizations Aren’t Talking About

The numbers are uncomfortable. McKinsey puts large traditional banks at roughly 40% less productive than digital natives. Fintechs and neobanks ship features every two to four weeks; incumbents still measure their rollout cycles in months four to six of them. Globally, banks spend on the order of $600 billion a year on technology, and the productivity dividend keeps not arriving. [1]

The instinct is to read that as an investment problem. It isn’t. McKinsey finds that only about 30% of banking transformation initiatives meet their stated objectives which means roughly seven in ten fall short, and most of them fall short after Agile has already been adopted. [1] Frameworks aren’t the constraint. Execution is.

Naming the Problem: Improvement Debt

I call this improvement debt, the hidden accumulation of process inefficiencies, coordination gaps, and delivery bottlenecks that teams consistently identify in retrospectives but rarely resolve. Much like technical debt, it compounds over time. Every unresolved issue increases organizational complexity, making the next challenge harder to detect and more costly to address. Before long, teams find themselves documenting the very same dependency constraints and alignment challenges they surfaced at the start of the transformation, only now they exist within a more complex operating model, with no structured mechanism in place to resolve them.

This is the part worth sitting with: it is almost never a visibility problem. Banks are acutely aware of what’s slowing them down. Sprints run on time, backlogs get groomed, retrospectives surface real issues governance delays, shifting priorities, the communication gap between delivery and product. Six months later the same themes are back on the board, in slightly different words.

The challenge is structural, not behavioral. Teams are encouraged to surface improvement opportunities, but few organizations have mechanisms in place to capture, prioritize, and act on them beyond the team level. Improvement actions often lack clear ownership, dedicated capacity, measurable outcomes, and visibility for leadership. As a result, they compete with feature delivery for attention and resources. When that trade-off remains informal, delivery commitments almost always take precedence, leaving the underlying issues to persist and compound over time.

McKinsey names the fix directly: traditional oversight has to give way to cross-functional collaboration, cross-silo performance management, and genuine joint accountability across business and IT. [1] Without that shift, the retrospective stops being a system for solving problems and becomes a ritual for re-describing them.

Why Follow-Through Breaks in Large Organizations

Retrospectives don’t fail because teams run them badly. They fail because the organization around them can’t absorb the output. Three structural breakdowns drive it.

1. Improvement work has no capacity allocated to it.

In a large bank, sprint capacity is spoken for before the retro ends. Regulatory commitments, production incidents, and feature releases all arrive with deadlines and executive attention. Improvement actions arrive with none of that, no Jira ticket, no owner, no date. The outcome is predictable. Absent ownership and absent tracking are, consistently, the two most common reasons retro actions never make it to closure. When improvement work has to compete informally against committed delivery, delivery wins without a contest.

2. Most root causes sit above the team’s authority.

A team that documents a dependency bottleneck doesn’t own the dependency, it owns the symptom. The real constraint usually lives in a shared platform, a governance gate, a funding model, or an org chart, none of which the team controls. With no path to escalate, the retrospective degrades into a complaint log: the same problem, re-worded each sprint, going nowhere. Left unaddressed, that shows up as a measurable year-over-year decline in a team’s improvement trajectory.

3. Ownership is ambiguous by design.

“The team will improve this” is not ownership. Shared ownership is no ownership. Without one named individual accountable for driving an action to closure, the initiative dissolves back into the background noise of delivery.

A Transformation That Actually Moved the Needle

A Tier-1 bank. Multiple Agile teams. Eighteen months of retrospectives producing the same two findings, dependency friction and delivery-to-product misalignment, at a resolution rate near zero. The retros weren’t broken. The system around them was.

Every sprint, teams were doing the emotional labor of surfacing genuine problems into a structure that was architecturally incapable of resolving them. Actions were born inside the ceremony and died the moment it ended: no backlog entry, no owner, no capacity, no leadership visibility. Most consultants would have redesigned the retrospective template. We didn’t touch it, the template was fine. The plumbing behind it was missing. So we built the plumbing:

• Retro actions ingested straight into Jira same taxonomy, same prioritization rigor as feature and production work. No ticket, no existence.
• A single named owner for every action, accountable through to closure. “The team will improve this” was eliminated by design.
• An 80/20 capacity model hard-coded into sprint planning, so improvement work was protected rather than negotiated away each cycle.
• Leadership instrumentation extended past release milestones to track completion rates, repeat-issue frequency, and escalated systemic blockers in real time.
• Executive alignment workshops to sponsor cross-team constraints, removing the ceiling on what teams could structurally resolve.

Within three sprints, repeat retrospective themes fell by 15%, delivery predictability improved from roughly 70% to 80%, and retrospective action resolution climbed from near zero to over 55%. The organization didn’t just run better retrospectives, it built the discipline to turn insights into action.

That’s the real opportunity. As McKinsey’s research shows, organizations that systematically remove execution bottlenecks can achieve meaningful productivity gains without adding headcount. [2]

Five Principles for an Operating Model That Actually Improves

If you’re serious about closing the execution gap, start here.

Why AI Makes This Urgent, Not Optional

A lot of banking leaders are betting on AI to accelerate transformation, and the money is committed, BCG projects AI agents could reduce banking costs by 30 to 40 percent and lift profitability by 30 percent by 2030. [4] Here’s the uncomfortable part: AI doesn’t fix a broken operating model. It amplifies whatever model it lands on.

Drop AI into an organization with disciplined execution and it compresses cycle time and compounds advantage. Drop it into one where improvement debt is accumulating, ownership is ambiguous, and systemic blockers go unresolved, and it does exactly one thing faster: the dysfunction. A shorter development cycle buys you nothing if the same dependency problems, prioritization gaps, and alignment failures are still on the board three sprints from now.

The banks that create the most business impact won’t be the ones with the most elegant retrospective templates or the most Agile certifications per capita. They’ll be the ones whose operating model makes follow-through structural instead of aspirational.

The Bottom Line

For a decade, banking Agile transformations optimized for one thing: identifying problems faster. Most banks have won that game. The next one is different, and harder.

The organizations that win it will be the ones that convert insight into action, reliably where every improvement has a backlog item, an owner, a sprint slot, and a leadership review. Where the improvement trend line points up, not down. Where the same issue doesn’t reappear on the retrospective board two months running.

Agile maturity was never about identifying problems. It’s about building the organizational discipline to solve them and proving it with data.

Author Bio:

M

Malathi Upendranath Bhupal

Agile Transformation Leader · Altimetrik

Malathi is an Agile transformation leader at Altimetrik, which partners with global banks and financial institutions on large-scale technology transformation, Agile delivery, and engineering modernization. Learn more about the banking practice at altimetrik.com.

View LinkedIn Profile →