Agile at Scale: What Works, What Does Not, and Why
SAFe® and other scaled agile frameworks have become standard in large financial institutions. The results are mixed. Understanding why requires looking beyond the framework itself to the organisational conditions that determine whether it can work.
The Promise and the Reality
The case for scaled agile in financial institutions is compelling in theory. Faster delivery, better alignment between technology and business, more responsive to change, less waste. The frameworks — SAFe®, LeSS, Spotify model variants — provide a structured approach to achieving these outcomes at scale. The training programmes are well-developed. The certification ecosystem is mature. The consulting support is readily available.
The results, in practice, are consistently mixed. Some institutions achieve genuine transformation in how they deliver. Many achieve a surface-level adoption of agile terminology and ceremonies without the underlying change in how decisions are made, how work is prioritised, and how accountability is structured. A significant number find that their scaled agile implementation has added process overhead without delivering the promised benefits.
The gap between the promise and the reality is not primarily a framework problem. It is an organisational conditions problem.
Genuine Product Ownership
Scaled agile frameworks require product owners who have real authority to make decisions about what gets built and in what order. In most financial institutions, this authority is distributed across multiple stakeholders — business units, risk functions, compliance, technology — and the product owner role becomes a coordination function rather than a decision-making one. The result is that prioritisation decisions take as long as they did before, but now they happen inside an agile ceremony rather than in a project steering committee.
Cross-functional transformation that addresses this requires genuine changes to decision rights — not just the creation of product owner roles. It requires business leaders who are willing to delegate real authority, and governance structures that support rather than undermine that delegation.
Architectural Readiness
Agile delivery at scale requires a technology architecture that can support it — modular, loosely coupled, with clear interfaces between components. Most large financial institutions have technology estates that are the opposite: tightly coupled, with complex interdependencies that make it impossible to deliver independently across teams. The agile ceremonies happen, but the actual delivery is constrained by architectural dependencies that the framework cannot address.
Enterprise transformation advisory that addresses this recognises that scaled agile adoption and architectural modernisation are not sequential — they need to be designed together. The operating model transformation and the technology transformation are the same programme.
Leadership Behaviour
Scaled agile frameworks require a different kind of leadership behaviour from senior executives. They require leaders who can tolerate uncertainty, who make decisions based on evidence rather than plans, and who create the psychological safety that allows teams to surface problems early. In institutions where the leadership culture rewards certainty and punishes bad news, agile teams learn quickly to behave like waterfall teams — they just use different vocabulary.
Transformation delivery effectiveness in a scaled agile context depends more on the behaviour of the top three levels of leadership than on the quality of the framework implementation. This is the variable that most agile transformation programmes underinvest in.
What a Realistic Assessment Looks Like
A realistic assessment of a scaled agile implementation — or a planned one — starts with the organisational conditions, not the framework. It asks whether the decision rights exist to support genuine product ownership. It assesses the architectural readiness to support independent delivery. It evaluates the leadership behaviour at the levels that matter most.
If the conditions are not in place, the question is not which framework to adopt. It is what needs to change to create the conditions — and whether the organisation has the appetite and the capability to make those changes. That is a more difficult conversation than a framework selection exercise. But it is the conversation that determines whether the investment in scaled agile produces the outcomes the institution is expecting.
Discuss This Perspective
Is your scaled agile implementation delivering?
An independent assessment of the organisational conditions — not just the framework — can identify what needs to change. All discussions are confidential.