"SAFe, LeSS, Nexus – Scaling as an Excuse"

October 2025 11 min read Opinion + Report Reference

When an organisation’s Agile adoption is not working, the answer is rarely to add more framework. Yet that is exactly what most organisations do. They scale. And scaling, in most cases, is not a solution to the problem. It is an expensive, elaborately documented way of avoiding it.

---

The Hook: The Scaling Paradox

Here is a question worth sitting with: if a single Scrum team in your organisation is struggling to deliver value consistently, what makes you think that fifty Scrum teams coordinated through a Programme Increment planning event will do better?

The honest answer, in most cases, is nothing. The problems that make one team ineffective – unclear priorities, lack of genuine Product Owner authority, organisational structures that obstruct self-organisation, management behaviours that undermine psychological safety – do not disappear when you add a scaling framework. They multiply. One team’s dysfunction becomes fifty teams’ dysfunction, now with additional ceremonies, additional roles, and a significantly larger consulting invoice.

This is the scaling paradox: the organisations that most aggressively adopt scaling frameworks are frequently the ones that have not yet solved the basic problems that scaling frameworks cannot solve.

---

The Reality: What Scaling Frameworks Actually Do

Let us be precise about what we are discussing. The three most commonly adopted scaling frameworks are:

Framework	Full Name	Origin	Market Position
SAFe	Scaled Agile Framework	Dean Leffingwell, 2011	Most widely adopted, enterprise focus
LeSS	Large-Scale Scrum	Larman and Vodde, 2005	Organisationally demanding, less common
Nexus	Nexus Framework	Scrum.org, 2015	Scrum-native, moderate adoption

Each of them addresses a real problem: how do you coordinate multiple teams working on a single product or related products? Dependencies need managing. Planning needs aligning. Architectural decisions need coordinating. These are genuine challenges and they deserve genuine solutions.

The problem is not that scaling frameworks exist. The problem is why most organisations adopt them – and what they are actually used for once adopted.

What the Data Shows

The State of Agile Report is instructive here. Year after year it shows SAFe as the dominant scaling framework by adoption – typically used by 30-40% of organisations that have adopted a scaling approach. It also shows, consistently, that the top reasons organisations adopt scaling frameworks include:

• Consistency across teams – a legitimate goal, often pursued for illegitimate reasons
• Improved visibility – frequently code for “management wants more reporting”
• Better alignment – genuine need, but alignment of what, exactly, and in whose direction?
• Executive mandate – the least encouraging reason of all

“Executive mandate” deserves particular attention. When a scaling framework is adopted because a senior leader attended a conference, or because a consultancy recommended it, or because a competitor is using it – the framework is being used as a signal, not as a solution. It signals organisational maturity, strategic intent, and modernity. It does not, in itself, deliver any of those things.

---

The Checksum: A Framework-by-Framework Assessment

SAFe – The Enterprise Comfort Food

SAFe is the most commercially successful scaling framework for a reason: it is the one that requires the least organisational change while appearing to require the most. It adds roles – Release Train Engineer, Business Owner, Solution Architect. It adds ceremonies – PI Planning, System Demo, Inspect and Adapt. It adds artefacts – Program Increment, Solution Backlog, Architectural Runway. All of this sits on top of existing organisational structures rather than replacing them.

This is SAFe’s commercial genius and its structural weakness simultaneously. It is adoptable precisely because it does not require organisations to give up the hierarchy, the governance structures, or the management behaviours that are frequently causing the problems they are trying to solve. You can implement SAFe without a single senior manager changing how they make decisions. And most organisations do exactly that.

The SAFe tell: Ask a SAFe-implementing organisation whether their development teams have genuine authority to make technical decisions without management approval. Ask whether priorities can change within a Programme Increment based on new evidence. Ask whether any part of the existing management hierarchy was eliminated as part of the SAFe adoption. The answers will tell you whether you are looking at a genuine transformation or an expensive rebranding.

To be fair to SAFe: implemented with genuine intent and genuine organisational change, it can work. I have seen it work. The framework itself is not the problem. The problem is that it is almost never implemented with genuine intent and genuine organisational change. The organisations that need it most are the ones least willing to do what it actually requires.

LeSS – The Honest One

LeSS deserves more credit than it receives. Unlike SAFe, it is explicit about what organisational change it requires. It specifies that most specialist roles should be eliminated. It requires a single Product Owner for the entire product, with genuine authority. It demands that teams be truly cross-functional and self-managing. It removes the middle management layers that typically exist between teams and product strategy.

This is why LeSS adoption is relatively rare. Not because it does not work – the evidence suggests it works well when implemented properly. But because implementing it properly requires organisations to give up things that most organisations are not willing to give up: management layers, specialist silos, and the comfortable fiction that coordination problems can be solved by adding coordination roles.

“LeSS is the scaling framework that tells organisations the truth about what scaling requires. SAFe is the one that tells them what they want to hear. The market has made its preference clear.” Markus – agile-checksum.com

Nexus – The Pragmatic Middle Ground

Nexus sits between SAFe and LeSS in terms of both complexity and organisational demand. It is Scrum-native – built explicitly on top of Scrum rather than alongside it – and it adds a single integration layer: the Nexus Integration Team, responsible for coordinating dependencies and ensuring integrated increments across three to nine Scrum teams.

Nexus is honest about its scope. It addresses the specific problem of multiple Scrum teams working on a single product. It does not try to be an enterprise operating model. For organisations that genuinely need to coordinate three to nine Scrum teams on a single product and have already solved the basic Scrum problems at team level, Nexus is probably the most pragmatic choice available.

The catch: most organisations adopting Nexus have not solved the basic Scrum problems at team level. They are scaling dysfunction, not capability.

---

Real-World Examples: Scaling Gone Wrong

The SAFe Implementation That Changed Nothing

A large financial services organisation I worked with adopted SAFe over an eighteen-month period. The transformation programme cost several million euros, involved an external consultancy, and resulted in a full SAFe implementation across twelve teams and three Agile Release Trains.

Two years after the implementation, I was brought in to assess why delivery performance had not improved. The assessment was not complicated. The twelve teams still received their priorities from a portfolio management committee that met monthly. The Release Train Engineers had no authority to change priorities within a Programme Increment based on new evidence. The PI Planning events were elaborate ceremonies that formalised decisions already made in pre-PI planning meetings. The management hierarchy was identical to the one that had existed before SAFe. The vocabulary had changed. Nothing else had.

When I presented these findings, a senior manager asked me what I recommended. I told him: stop doing SAFe, fix the prioritisation process, give the teams genuine authority, and eliminate two layers of management. He told me that was not realistic. I agreed that it was not realistic in their current culture. I also told him that without those changes, no framework would help them. We did not work together again.

The LeSS Attempt That Was Abandoned

A product organisation attempted a LeSS implementation. They got as far as defining the single Product Backlog and identifying the need to eliminate three middle management roles before the programme was quietly shelved. The official reason was “organisational readiness.” The actual reason was that the three managers whose roles were to be eliminated were politically influential enough to make the implementation untenable.

This is not a criticism of LeSS. It is an illustration of why genuine scaling is politically difficult in ways that framework documentation rarely acknowledges.

The Nexus That Became SAFe by Accident

A software company implemented Nexus for five teams working on a single platform. Within eighteen months, the Nexus Integration Team had grown from four people to twelve. It had developed its own backlog, its own ceremonies, and its own reporting line. It had become, in effect, a programme management office with Agile vocabulary. The coordination layer designed to be lightweight had become the heaviest part of the organisation.

This happens because coordination roles attract work. Give a group of people responsibility for integration and they will find more things to integrate. The antidote – rigorous WIP limits on the coordination layer itself, and a clear mandate to make themselves progressively less necessary – is rarely applied.

---

When Scaling Actually Makes Sense

I want to be clear: I am not arguing against scaling frameworks categorically. I am arguing against using them as a substitute for solving the problems they cannot solve.

Scaling makes sense when all of the following are true:

• Individual teams are genuinely effective – they self-organise, they deliver consistently, they improve continuously. If teams are not effective at the team level, scaling will not fix them.
• The coordination problem is real – multiple teams genuinely cannot deliver independently because of shared architecture, shared codebase, or genuine inter-team dependencies. Not every multi-team environment has this problem.
• The organisation is willing to change – not just to add a framework on top of existing structures, but to actually change how decisions are made, how priorities are set, and how authority is distributed.
• Leadership understands what they are signing up for – not a transformation programme with a defined end date, but a permanent change in how the organisation operates.

The honest diagnostic: Before adopting a scaling framework, ask this question in a room full of senior leaders and watch the reactions: “Are we willing to eliminate management roles if the framework requires it?” If the answer is anything other than a clear yes – stop. You are not ready to scale. Fix the culture first.

---

The Takeaway: Scale the Solution, Not the Problem

Scaling frameworks are tools. Like all tools, they are useful in the right context and counterproductive in the wrong one. The right context for a scaling framework is an organisation that has solved the basic problems of Agile at team level and genuinely needs to coordinate multiple teams on a complex product. That description fits fewer organisations than the scaling framework market would suggest.

For most organisations that are currently adopting or considering scaling frameworks, the honest diagnosis is simpler and more uncomfortable: the problem is not that you need better coordination between teams. The problem is that individual teams do not have the authority, the clarity, or the trust they need to be effective. No scaling framework addresses those problems. Only leadership does.

Run the checksum before you scale:

1. Can each of your teams name their Sprint Goal right now, without looking it up?
2. Can each Product Owner change a priority without getting approval from someone outside the team?
3. Has any management layer been eliminated – or genuinely changed – as part of your Agile adoption?

If the answers are no, no, and no – you do not have a scaling problem. You have a foundation problem. Build the foundation first.

---

Glossary Terms Used in This Article

• SAFe – Scaled Agile Framework, the most widely adopted enterprise scaling framework.
• LeSS – Large-Scale Scrum, a scaling framework that requires significant organisational change.
• Scrum – A lightweight framework for developing and delivering complex products.
• Product Owner – The Scrum accountability responsible for maximising product value.
• Agile Transformation – The process by which an organisation adopts Agile values and practices at scale.
• Psychological Safety – The shared belief that it is safe to take interpersonal risks within a team.