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 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.
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.
Understanding the differences between code-level and process-level debt
| Dimension | Technical Debt | Improvement Debt |
|---|---|---|
| What accumulates | Code/architecture shortcuts | Unresolved process and delivery issues |
| Where it surfaces | Code reviews, sprint work | Retrospectives |
| Why it happens | Speed over quality under deadline | Feature work prioritized over fixes |
| Visibility | Hidden until something breaks | Named openly, repeatedly |
| Why it stalls | No time to refactor | No ticket, owner, or capacity |
| How it compounds | Each shortcut raises the next change’s risk | Each unresolved issue gets harder to fix |
| Who can fix it | The owning engineering team | Often above the team’s authority |
| How it’s tracked | Backlogs, quality metrics | Rarely tracked — “the team will improve this” |
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.
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 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:
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]
If you’re serious about closing the execution gap, start here.
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.
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:
Altimetrik CEO Raj Sundaresan said enterprises need to avoid AI “optimizations traps,” trendy approaches that don’t age well if you don’t put architecture first. Sundaresan riffed on AI optimization traps, token-maxxing, the penchant for forward deployed engineers and the need for multi-model approaches in a blog post. Constellation Research caught up with Sundaresan for a […]
Governed, human-in-the-loop agentic experiences for the workflows that run a life sciences business batch release, deviation and CAPA, HCP engagement, and CSR evidence review built on Alti AIOS™ and Google Cloud, and portable across model platforms. In life sciences, the hardest problems don’t live inside a single model. They live in the space between a […]
Why Enterprise AI Won’t Be Won by a Single Model Every technology revolution creates its own optimization traps. The cloud era taught us that migrating more applications didn’t automatically make an enterprise cloud native. The AI era is teaching us something similar, and it is teaching it twice. The first optimization trap was Tokenmaxxing. The […]
“Amit Singh is the Chief Strategy Officer and Chief of Staff to the CEO at Altimetrik, where he drives corporate strategy, growth acceleration, and value creation through transformation initiatives. In this dual role, he partners closely with leadership teams, investors, and the board to align business strategy with sustained, technology-driven growth.
With over two decades of experience at the intersection of technology, business, and transformation, Amit brings a unique perspective on how organizations can innovate and adapt in a rapidly evolving digital landscape. His career has been defined by building high-performing teams, scaling innovative platforms, and driving organizational change to deliver lasting impact.
Before joining Altimetrik, Amit held senior leadership roles at Visa, where he led technology strategy, engineering, and product development for Real-Time Payments and the Visa Developer Platform. Earlier, he served as Chief Product Officer at a startup and spent more than a decade at Oracle, leading product and engineering teams across a wide range of enterprise software applications.”
Altimetrik is committed to protecting your personal information. To apply for a position, you will need to provide your email address and create a login. Your information will be used in accordance with applicable data privacy laws, our Privacy Policy, and our Privacy Notice.
