The Mid-Transformation Wall: Why Agile Transformations Stall in Financial Services

Most Agile transformations in financial services do not fail at the beginning.

They usually fail after enough progress has been made for leadership to believe the hardest part is over.

That is what makes the middle so dangerous.

The early phase often feels encouraging. New squads are formed. Customer journeys start improving. Teams use fresher language. Leaders see faster demos and better energy. The transformation looks alive.

Then, something changes.

Velocity gets harder to sustain. Dependencies start piling up. Governance becomes heavier again. Technology teams begin sounding cautious. Business leaders grow impatient. Risk and compliance questions get louder. The program is still moving, but not with the confidence it had six months earlier.

That moment is where many financial institutions hit the wall.

It is not always dramatic. Sometimes it looks like missed milestones. Sometimes it looks like endless alignment meetings. Sometimes it shows up as teams still doing Agile ceremonies while real decisions keep getting pushed upward or sideways.

Whatever form it takes, the pattern is familiar.

The first stage feels easier because it usually is

The first phase of transformation often targets the parts of the bank where visible progress is easiest.

That usually means customer-facing work.

Digital onboarding, mobile journeys, self-service improvements, alerts, front-end servicing, and product discovery can often be improved faster than deeper operational or core-system environments. Agile naturally feels stronger there because teams can test, learn, and adjust in smaller pieces.

McKinsey notes that banks have been under pressure to speed up change because fintechs and neobanks release new features every two to four weeks on average, while traditional banks often still operate on product rollout cycles of four to six months. The same research says large banks are roughly 40 percent less productive than digital natives. 

That pressure creates urgency.

So institutions start where the benefits are easiest to show. That makes sense. The problem is that early wins can create a false impression that the whole bank is becoming more adaptive, when in reality only part of it has changed.

The deeper constraints are still there.

They simply have not taken center stage yet.

The middle of the transformation is where the bank meets itself

The middle is where the institution runs into its own structure.

This is where teams stop working only on surface improvements and start colliding with legacy systems, fragmented ownership, data dependencies, manual controls, and old approval paths that were never redesigned.

That shift changes everything.

A front-end team may have improved a journey in two-week cycles. But when the next phase requires changes to servicing platforms, reconciliation logic, document workflows, reporting outputs, or third-party integrations, the pace changes. The work is no longer just about product iteration. It becomes about institutional coordination.

This is where legacy system constraints stop being an abstract phrase and become daily reality.

The Basel Committee has warned that banks’ legacy IT systems may not be adaptable enough to support new technologies, that change-management practices can be inadequate, and that integrating new technology with legacy environments adds complexity. It also notes that increasing use of APIs, cloud, and new technology arrangements can expand cyber exposure if controls do not keep pace. 

The transformation becomes structurally more complex as it progresses.

Early transformation lets the bank behave differently in selected areas. Mid-transformation forces the bank to confront what still has not changed underneath.

Agile does not remove structural complexity

One reason leaders get frustrated in the middle is that they expect Agile to solve more than it actually can.

Agile can improve learning speed, ownership, transparency, and responsiveness. It can reduce the chance of spending years building the wrong thing. It can make teams more accountable for outcomes instead of documents.

What it cannot do on its own is remove structural complexity.

McKinsey’s banking discussion on Agile makes an important point here. It says Agile organizations are made up of dynamic teams, but those teams are supported by a more stable backbone that includes governance, performance management, and enabling capabilities. 

That stable backbone is where many financial institutions fall short.

They stand up squads and ceremonies, but they do not redesign funding models, governance paths, shared-service interfaces, or decision rights deeply enough. So the visible layer changes first, while the institutional backbone remains mostly the same.

That mismatch can be hidden for a while.

Then the transformation reaches the middle and the old system starts pushing back.

Governance conflict usually returns right when the program needs scale

In the pilot phase, governance often feels manageable.

There are fewer teams. Leadership attention is stronger. The scope is narrow enough that people can work around friction. A few exceptions get approved. A few shortcuts are tolerated. Everyone stays optimistic.

That rarely holds once the transformation grows.

As more teams begin touching more systems, governance comes back into the room with more force. Architecture wants consistency. Risk wants clarity. Compliance wants evidence. Operations wants support readiness. Internal-control teams want traceability. Audit wants proof that change is being managed properly.

If those functions were not redesigned as part of the transformation, they tend to reappear through old processes.

PwC makes this problem very clear. It says many organizations embrace Agile while leaving risk, compliance, and assurance functions without a seat at the table, which can result in non-controlled, non-compliant, and less effective adoption. It also notes that when compliance functions try to retrofit old-school controls into an Agile cycle, productivity gains erode. 

That is the middle-stage trap.

At first, Agile feels fast because governance has not fully caught up. Later, the program slows because governance was never truly integrated into the delivery model in the first place.

Scaling Agile often exposes coordination debt

Many banks assume that if a few Agile teams performed well, more Agile teams will automatically perform even better.

That is not always what happens.

In financial services, scaling can expose hidden coordination debt before it improves performance. More teams mean more dependencies, more shared platforms, more integration questions, more data ownership issues, and more need for common standards.

McKinsey’s broader digital-transformation work says digital transformations depend on cross-functional teams, but scaling those teams requires a new operating model. It also emphasizes the need for distributed technology, reliable data, strong governance, and coordinated action across those areas. 

That is the part many banks underestimate.

It is one thing to run a few energized squads at the edge of the bank. It is another to support dozens of teams without overwhelming architecture, control, data, and operational functions.

This is where scaling agile challenges become very real.

If the bank has not simplified the underlying system, scale makes the bottlenecks more visible. It does not remove them.

That is why transformations often feel strong at twenty people and confused at two hundred.

Resistance gets subtler in the middle

Early resistance to transformation is usually easy to spot.

People question the model. Leaders defend their teams. Some managers openly doubt the new way of working. That kind of resistance is visible and easier to manage.

The middle is different.

Resistance becomes quieter.

A decision gets delayed because “more input is needed.” A dependency suddenly appears. A team agrees in principle but slows execution in practice. A legacy-system owner insists that an old process must be preserved “for now.” Governance bodies start asking for extra steps that no one can clearly justify, but no one wants to challenge.

This form of resistance is harder because it often sounds reasonable.

McKinsey’s work on core banking transformations notes that banks sometimes put teams running existing systems in charge of the new one, but those teams may resist adopting a new architecture or unintentionally migrate legacy processes into the modern solution, creating delays. It also reports that only about 30 percent of core banking transformations over the previous decade completed a full migration of ledgers and products to a new system. 

That is not just a technology problem.

It is an organizational resistance problem tied to power, familiarity, and risk ownership.

People do not only resist because they dislike change. They resist because the middle of transformation starts changing the parts of the organization that matter most to their role.

A realistic example banks know too well

Imagine a retail bank modernizing its account-opening and servicing experience.

The first phase goes well.

The bank improves the mobile flow, shortens the forms, simplifies status updates, and reduces obvious customer friction. Leadership sees movement. Teams feel proud. The transformation story sounds convincing.

Then phase two begins.

Now the work touches identity-verification rules, case routing, legacy document stores, fraud checks, servicing workflows, operational handoffs, and reporting obligations. Suddenly the team depends on functions that were barely involved in phase one. Some systems cannot support the desired release cadence. Some controls were never translated into build-ready requirements. Some data is inconsistent across channels.

The bank is still “doing Agile.”

But the program now feels heavier, slower, and more political.

That is not because Agile stopped working.

It is because the transformation moved from the part the bank could modernize quickly to the part that reveals how the bank really runs.

Many programs stall because they optimize use cases, not domains

Another reason transformations hit the wall is that they improve isolated use cases without fully redesigning the broader domain.

The first improvement looks good on a dashboard, but it still depends on manual work, disconnected systems, and older processes somewhere else. The result is visible progress that does not scale cleanly.

McKinsey’s digital-transformation guidance says transformations have a much better chance of success when teams focus on entire domains, such as a customer journey, process, or functional area, instead of only isolated use cases. It argues that a domain view matters because it includes all the related activities needed to deliver complete value. 

This is especially relevant in financial services.

A bank may improve one onboarding step without fixing the rest of the fulfillment process. It may digitize a front-end workflow without modernizing case management underneath. It may launch a better self-service feature while the contact-center and operations teams still work off fragmented data.

At first, those gaps are survivable.

In the middle, they become the reason progress slows.

Leadership fatigue is often a symptom, not the cause

When programs stall, senior leaders often start talking about fatigue.

Transformation fatigue. Change fatigue. Delivery fatigue.

Those phrases are not wrong, but they can be misleading.

Fatigue is often the visible symptom of structural issues underneath. Teams get tired because priorities keep colliding. Leaders get frustrated because metrics show movement but not enough value. Control teams feel ignored until late. Delivery teams feel slowed down by old routines. Business sponsors lose trust because the second half of the program feels less predictable than the first.

McKinsey’s research on digital transformation says the average transformation has a 45 percent chance of delivering less profit than expected, and that the likelihood of outperforming expectations improves significantly when leaders commit to clear priorities, strong talent, sustained leadership focus, agility, and accountability. 

That matters because the middle of the program is where weak priorities and weak accountability become impossible to hide.

By then, the institution is no longer running on enthusiasm. It is running on design quality.

What banks should do before they hit the wall

The best way to handle the mid-transformation wall is to prepare for it early.

Banks should assume the middle will be harder than the beginning and design accordingly.

They need to separate customer-facing work from core and operational work instead of pushing both through the same delivery rhythm.

They need to bring governance, risk, and control functions closer to the work before scaling, not after friction becomes visible.

They need to identify where legacy architecture will block progress and decide which dependencies must be addressed before velocity goals are raised.

They need to define success by domain outcomes, not just team activity.

And they need to treat change management as part of transformation economics, not as a communication task added later. McKinsey says organizations should plan to spend at least another dollar on implementation, process change, training, and change-management initiatives for every dollar spent developing a digital solution. 

That one point alone explains why so many programs feel underpowered in the middle.

They funded the build. They did not fund adoption, coordination, and institutional rewiring deeply enough.

The wall is predictable, not mysterious

Agile transformations stall in financial services for understandable reasons.

They stall because banks often modernize the visible layer faster than the structural layer. They stall because governance is adapted too late. They stall because scale exposes coordination debt. They stall because legacy systems, control obligations, and organizational interests do not disappear just because teams have changed their rituals.

That should not make leaders pessimistic.

It should make them more realistic.

The middle of transformation is not where momentum dies by accident. It is where unfinished institutional work comes due.

Banks that understand that can prepare for it.

They can use Agile where learning speed matters. They can use hybrid delivery where deeper coordination is needed. They can redesign governance early, simplify domains instead of polishing use cases, and treat change management as real work rather than side work.

When they do that, the wall does not disappear completely.

But it becomes something the organization can move through, instead of something that quietly stops the transformation in its tracks.