Why Scaling Agile in Banking Increases Risk Before Performance

Banks often assume that if a few Agile teams help, more Agile teams will help even more.

That sounds logical. It is also where a lot of trouble starts.

In the early phase of a transformation, Agile usually looks promising. A handful of squads get closer to the business, delivery feels faster, customer journeys improve, and senior leaders finally see movement after years of heavy programs and slow releases. The mistake is assuming that this early momentum will scale neatly across the institution. In banking, it rarely does. 

That is why scaling agile in banking often increases risk before it improves performance.

The reason is not that Agile is flawed. The reason is that scale exposes everything the pilot phase was temporarily able to hide. It exposes weak decision rights, fragile architecture, overloaded control functions, inconsistent standards, unclear ownership, and data problems that were always there but were easier to manage when only a few teams were moving at speed. 

Banks are under real pressure to make this work.

Traditional banks still lag digital natives on speed and productivity. McKinsey found that fintechs and neobanks were releasing product features every two to four weeks on average, while traditional banks often operated on rollout cycles of four to six months. The same research says large banks are about 40 percent less productive than digital natives. When leaders see that gap, the natural instinct is to scale faster. 

The problem is that speed at small scale and speed at enterprise scale are not the same thing.

A few Agile teams can succeed through attention, talent concentration, and workarounds. A bank with dozens of squads needs something else entirely. It needs a real system for coordination, control, and decision-making. Without that system, scale does not create compounding gains first. It creates compounding exposure. 

Why the pilot phase creates false confidence

The pilot phase is flattering.

A bank chooses a visible journey, assigns strong people, removes a few blockers, and gives the team executive air cover. That is usually enough to create early wins. The business sees quicker releases. The team feels energized. Leadership starts talking about rolling the model out more widely. 

What the bank often misses is how much of that success depended on special conditions.

The pilot may have relied on a few trusted architects, a handful of compliance exceptions, informal escalation paths, and people solving problems through relationships rather than through a repeatable operating model. None of that feels dangerous when ten people are moving quickly on one mission. It becomes much more dangerous when forty teams are trying to do the same thing at once. McKinsey describes this directly, noting that companies can often muscle through issues on an exception basis at small scale, but that the ad hoc approach breaks down as organizations move from around ten Agile teams to 40 or more. 

This is the moment where risk rises before performance does.

The bank has scaled the visible mechanics of Agile, but not yet the institutional support needed to make Agile safe and durable. That gap is where delays, control findings, uneven quality, and delivery confusion usually appear. 

Scale multiplies dependencies before it multiplies value

When banks scale Agile, they do not just add teams.

They add interdependence.

One squad depends on shared APIs. Another depends on enterprise data. Another needs architecture review. Another is waiting on legal wording, control design, vendor access, or testing support. Suddenly the organization is not managing ten backlogs. It is managing collisions between dozens of moving parts. That is why scaling often feels harder than leaders expected, even when the teams themselves are capable. 

This is especially true in banking because the institution is already complex.

McKinsey’s banking experts describe banks as highly siloed and complex, shaped by regulatory change and diverse channels. They also warn against copy-paste Agile implementations that rename old processes without fundamentally rethinking how the organization should operate. In other words, adding more squads without redesigning how the bank coordinates them is not transformation. It is mostly relabeling. 

That is why the first thing scale increases is not usually output.

It is coordination debt.

Teams spend more time aligning, waiting, escalating, and resolving dependencies. To leadership, this can feel like Agile has suddenly become inefficient. In reality, the bank is finally seeing how much institutional friction was hidden by the pilot stage. 

Risk functions usually feel the strain first

When Agile spreads, risk and compliance teams often feel the shock before anyone else.

A few Agile teams are manageable because control functions can join selectively, review key items, and keep up through informal effort. Once the number of teams grows, that same model collapses. Reviews arrive faster. Release cadences shorten. The volume of change rises. Risk teams are still expected to provide credible challenge, but they are doing it through structures that were designed for slower, more centralized delivery. 

That mismatch creates a familiar pattern.

Delivery teams start saying risk is slowing them down. Risk teams start saying they are being brought in too late. Both are reacting to the same design flaw. McKinsey notes that many organizations still handle transformation risks at a surface level, such as setting up forums or a few Agile ceremonies, while risk teams try to force-fit traditional practices into the new delivery framework and simply cannot keep pace. 

The cost of that mismatch is not theoretical.

McKinsey describes a midsize bank that moved aggressively toward cloud-native architecture, Agile, and DevSecOps, only to realize that its risk and security teams were still using traditional practices that could not keep up. The result was regulatory findings and a release delay of about five months. That is a perfect example of risk rising before performance. The bank looked more modern on paper before it was actually safer or faster in production. 

More Agile teams do not automatically mean more control ownership

Banks often hope that Agile will push responsibility closer to the front line.

That can happen, but it does not happen automatically.

McKinsey’s work on Agile operating models for risk and compliance says agile structures can increase front-line risk ownership and give control teams more visibility, especially when teams are cross-functional and transparent. But that only works when the first line is given real decision rights, clear guardrails, and practical training. Without that, “ownership” becomes a slogan, not a capability. 

This is one of the quiet dangers of scale.

A bank can create squads faster than it creates judgment. If teams are expected to move quickly but are not equally clear on standards, governance, and escalation paths, then the institution gets more variation instead of more performance. Some squads become excellent. Others improvise. The gap between them becomes a new source of operational risk. (

That is why strong scaling efforts spend real energy on guardrails.

They define what teams can decide locally, what must be escalated, what standards are non-negotiable, and where the second line of defense needs to be embedded. Agile can absolutely work with those constraints. In banking, it usually needs them. 

Data and architecture make the risk bulge worse

Scale gets harder when teams are building on top of fragmented data and older systems.

That is not a side issue in banking. It is often the main issue.

The Basel Committee has repeatedly emphasized that data governance, ownership, and lineage remain hard for banks, and that resistance to change, fragmented responsibilities, and insufficient senior-management attention continue to hinder progress. It also notes that legacy systems and distributed data estates make end-to-end data traceability difficult. When a bank scales Agile across that kind of environment, the added speed does not remove those weaknesses. It reveals them faster. 

This is one reason performance improvement usually lags behind the rollout.

Teams may deliver more quickly into their own lanes, but enterprise value still depends on shared architecture and trusted data. If those foundations are weak, the bank starts seeing more handoffs, more reconciliation work, more release coordination, and more time spent figuring out which version of the truth matters. The transformation feels bigger, but the operating system under it is still resisting. 

Banks sometimes treat this as an execution problem.

Very often it is a sequencing problem.

They scaled team autonomy before they built enough structural coherence underneath it. In other words, they expanded movement before reducing friction. That almost always creates a temporary risk bulge.

Talent strain shows up before productivity gains do

Another reason risk rises early is that banks usually underestimate the talent load of scale.

Agile at scale requires more than good engineers. It needs product owners who can make decisions, control specialists who understand modern delivery, architects who can support modular change, and leaders who can coach rather than command. McKinsey warns that traditional banks often struggle to attract the right tech talent, and that transformation risk rises significantly when too much of the workforce involved is outsourced. Its research suggests at least 50 percent of employees involved in the transformation should be in-house, while risk increases significantly when 70 percent or more are outsourced. 

That is a big deal in banking.

At small scale, a bank can concentrate its best people in a few high-priority squads. At large scale, that becomes impossible. The organization has to create depth, not just islands of excellence. Until it does, some teams will advance much faster than others, which makes governance, quality, and prioritization more uneven. 

This is why early scaling often feels messy even when the strategy is directionally right.

The bank is building capability while still trying to deliver value. That means performance gains arrive more slowly than leaders hoped, while the risk of uneven execution appears almost immediately. 

The banks that scale better build a backbone, not just squads

The institutions that get through this phase do not solve it by telling teams to “be more Agile.”

They build a stronger backbone.

McKinsey’s banking experts put it well when they say agile organizations are made of dynamic teams supported by a more stable backbone that includes governance, performance management, and enabling capabilities. They also stress that there is no one-size-fits-all model and that formulaic implementations usually disappoint. That is exactly the lesson banks need at scale. 

McKinsey’s Digital Factory model points in the same direction.

It argues that scaling transformation requires a central nerve center or control tower that supports teams, coordinates resources, shares best practices, ensures execution quality, and helps break bottlenecks. In other words, the answer to scaling is not less coordination. It is better coordination. 

PwC’s recent guidance on transformation risk is similarly practical.

It recommends a strong PMO, a scalable SDLC, clearly defined quality gates, embedded security and compliance across each phase, and governance models with clear decision rights and a single source of truth. It explicitly says quality gates are not compliance hurdles but opportunities to course-correct and reduce costly rework later. That is exactly the kind of support a scaled Agile bank needs before performance catches up. 

Performance does come, but only after redesign catches up

This is the part leaders often need to hear most clearly.

The early increase in risk does not mean scaling Agile is a mistake.

It means the institution has entered the part of the transformation where real redesign begins.

There is evidence that scaling can work. ING’s Agile transformation involved roughly 350 nine-person squads across 13 tribes and was reported to have improved time to market, employee engagement, and productivity. But that success did not come from multiplying teams alone. It came from changing structure, reporting lines, and how work was organized across the bank. 

That is the difference between rollout and redesign.

Rollout spreads the model. Redesign makes the model hold.

Banks that stop at rollout often conclude that Agile created more risk than value. Banks that keep going, by redesigning governance, embedding risk earlier, simplifying architecture, improving data discipline, and clarifying ownership, are the ones that eventually see performance catch up to the promise. 

Why this matters for leaders now

Banking is not getting simpler.

Risk and compliance budgets are still rising, technology spending continues to climb, customer expectations keep increasing, and competition for talent remains intense. McKinsey’s 2025 productivity work says banks launch efficiency programs every two to three years on average, but those efforts often treat symptoms rather than simplifying the operating model underneath. That is exactly why scaling Agile without redesigning the system tends to disappoint. 

So leaders should expect a temporary imbalance.

When Agile spreads, risk will often rise before performance improves because the organization is exposing hidden complexity faster than it is removing it. That is not failure. It is a sign that the transformation has moved past the flattering pilot phase and into the harder institutional work. 

The right response is not to slow everything down or declare the model broken.

It is to build the missing scaffolding fast enough that the bank can absorb the scale it has chosen. In banking, Agile only starts paying off at scale when governance, risk, architecture, data, talent, and delivery discipline begin scaling with it. Until then, more teams often mean more exposure before they mean more output. 

That is why scaling Agile in banking increases risk before performance.

Not because banks should avoid Agile.

Because institutions usually discover, a little later than they hoped, that multiplying squads is easy and redesigning the bank around them is the real work.