Choosing A Scaling Framework

The question arrives in a recognisable form. An organisation has somewhere between five and fifty delivery teams, quarterly commitments that keep slipping, a portfolio process that nobody trusts, and a growing suspicion that the team-level agility it bought three years ago has not added up to anything at the programme level. Someone asks which scaling framework to adopt, and the conversation proceeds as a procurement exercise: comparison matrices, certified partner lists, reference customers, a pilot.

This framing is wrong in a specific and expensive way. A scaling framework is not a solution to a delivery problem. It is a coordination mechanism, and coordination mechanisms are pure overhead. They exist to manage dependencies between teams. The value of a coordination mechanism is bounded above by the cost of the dependencies it manages, which means the first question is not which framework but how much coordination does our architecture and our funding model actually force upon us, and the second question is whether that amount can be reduced before you institutionalise it.

That said, the anti-framework position is also lazy. Plenty of organisations genuinely have irreducible coordination needs — a regulated release train, a physical product with long lead-time components, a legacy estate that cannot be decomposed inside three years, a portfolio that must be funded and defended annually. For those organisations, "just descale" is advice that cannot be executed, and a framework that provides shared vocabulary, a cadence and a visible planning ritual is a genuine improvement on the ad-hoc coordination they have now.

What follows is an attempt to describe what each of the serious options actually optimises for, what it costs, and the organisational conditions under which choosing it is defensible rather than merely fashionable.

The prior question: do you need to scale?

Scaling frameworks manage dependencies. Dependencies are mostly a consequence of two design decisions: how the system is decomposed, and how the work is funded and allocated. Neither is fixed.

Before selecting a framework, run a dependency census. Take the last two quarters of delivered work, and for each substantial item record which teams had to change something, which teams had to be asked for something, and which teams had to be waited on. You are looking for the shape of the graph, not a precise number. Three patterns tend to emerge.

If a small number of teams appear in almost every dependency chain, you do not have a scaling problem. You have a shared-service bottleneck, and a framework will formalise the queue rather than remove it. The fix is a platform team with a self-service interface, or splitting the bottleneck's ownership, not a quarterly planning event.

If dependencies are diffuse — every team touches every other team, roughly evenly — you have an architectural problem. Your service boundaries do not match your team boundaries, and Conway's Law is asserting itself in the form of coordination overhead. A framework will let you survive this at considerable recurring cost. Fixing the boundaries removes the cost permanently, but slowly.

If dependencies cluster into two or three tight groups with thin connections between them, you are in the fortunate case. Those clusters are your real value streams. You may need coordination inside each cluster and very little between them, which usually means a lighter framework than the one being proposed.

What each option genuinely optimises for

SAFe optimises for making a large, existing, budget-driven organisation legible and predictable without requiring it to change its funding model, its hierarchy or its governance on day one. This is a real and underrated strength. SAFe gives a CIO a vocabulary that maps onto the structures they already have, a planning ritual — PI Planning — that produces genuine cross-team visibility, and an implementation roadmap that can be sequenced. Organisations that were previously coordinating by escalation often find PI Planning transformative simply because it is the first time the people who depend on each other have been in the same room with the same information.

The cost is that SAFe's comprehensiveness makes it easy to adopt the structure without the substance. The framework contains sound engineering guidance, but that guidance is optional in practice and the ceremonies are not, so implementations drift towards a two-day quarterly planning ritual bolted onto unchanged engineering practice and unchanged funding. The result is a longer, better-decorated waterfall — the pattern described in water-scrum-fall. SAFe also encodes a large role taxonomy, which tends to create a new layer of coordination jobs that then has an interest in the framework's continuation.

LeSS optimises for keeping the system simple as it grows. Its core move is to refuse most additional structure: one product, one Product Owner, one backlog, one Definition of Done, many teams. Where SAFe adds roles to manage complexity, LeSS removes organisational elements so that the complexity has nowhere to accumulate. When it works, the result is genuinely lighter than anything else on this list and the feature teams that result are capable of end-to-end delivery without handoffs.

The cost is that LeSS demands changes most organisations are not prepared to make. A single Product Owner over many teams is a structural claim about authority that cuts across existing management. Feature teams require broad skills and a codebase that allows broad ownership. LeSS adoption is a reorganisation, not a process overlay, and half-implemented LeSS is worse than what preceded it because the coordination structures were removed before the capability to work without them existed.

Scrum@Scale optimises for modularity. It treats scaling as two linked networks — a Scrum of Scrums for delivery coordination and an Executive Action Team for impediment removal and strategy — and lets an organisation adopt components independently. It is the most honest of the frameworks about the fact that organisational impediments are the real constraint, and the Executive Action Team is a genuinely useful construct because it puts a named, accountable group on the hook for removing blockers that teams cannot remove themselves.

The cost is that modularity means less prescription, which means the outcome depends heavily on the quality of the people implementing it. An organisation with weak internal capability will assemble something incoherent. Scrum@Scale also assumes Scrum is working at team level; where it is not, the scaled structure amplifies the dysfunction.

Nexus optimises for a narrow, well-defined problem: a handful of Scrum teams building one product, where integration is the main risk. It adds one thing — an integration team accountable for a single integrated increment — and otherwise leaves Scrum alone. For its intended range it is the highest-value-per-unit-of-overhead option available, and its restraint is a feature.

The cost is simply range. Nexus does not address portfolio funding, cross-product dependencies or organisational impediments, because it does not try to. Selecting Nexus for a twenty-team programme spanning four products means you will end up building the missing parts yourself.

Team Topologies optimises for something different from the others and is not, strictly, a scaling framework. It provides a language for organisational design: four team types, three interaction modes, and the concept of cognitive load as the limit on what a team can own. Its central contribution is treating team boundaries and interaction patterns as a design problem with explicit trade-offs, and it pairs naturally with Domain-Driven Design's bounded contexts and with Conway's Law used deliberately — the inverse manoeuvre, where you shape the organisation to produce the architecture you want.

The cost is that it gives you no cadence, no planning mechanism and no governance answer. Team Topologies tells you how to draw the boundaries; it does not tell you what to do on Tuesday with the dependencies that remain. In practice it is best used alongside one of the others, or alongside a deliberately minimal home-grown coordination layer.

Descaling optimises for eliminating the coordination need rather than managing it: decompose the system along bounded contexts, give each stream-aligned team end-to-end ownership, invest in platform services so that teams are self-sufficient, and fund persistent teams rather than projects. Where it succeeds, the recurring overhead goes to near zero and never comes back.

The cost is that it is slow, requires engineering investment before it produces visible benefit, and offers no reassuring ritual to show a steering committee in month three. It is the highest-return and least-saleable option, which is why it is chosen less often than it should be.

The decision table

Option	Optimises for	Real cost	Choose when	Avoid when
SAFe	Predictability and legibility at scale without immediate structural change	Heavy role and ceremony overhead; easy to adopt form without substance	Large estate, regulated or budget-driven governance, many existing dependencies you cannot remove soon	You have fewer than roughly five teams, or you want the structure as a substitute for engineering change
LeSS	Simplicity; removing structure rather than adding it	Requires genuine reorganisation and broad-skilled feature teams	One product, real executive appetite for structural change, strong engineering base	Multiple products, weak sponsorship, or an architecture that forbids feature teams
Scrum@Scale	Modular adoption and executive impediment removal	Low prescription means outcome depends on internal capability	Scrum already works at team level and you have credible internal coaches	Team-level practice is weak, or nobody senior will staff the Executive Action Team
Nexus	Integration risk across a few teams on one product	Narrow range; no portfolio or funding answer	Three to nine teams, one product, integration is the dominant pain	Portfolio governance or cross-product dependency is the real problem
Team Topologies	Boundary design and cognitive load	No cadence, governance or planning mechanism of its own	You suspect the problem is boundaries, not process; combine with another option	You need a coordination answer this quarter and have no design capacity
Descale	Removing the dependency rather than managing it	Slow; needs engineering investment before visible payoff	Architecture is decomposable, leadership has patience, platform investment is fundable	Hard external deadlines within the year and a monolith you cannot touch

The conditions that actually determine the outcome

Framework choice explains less of the variance in outcomes than four other factors, and any honest assessment should weigh these first.

Engineering practice. If integration is manual, test coverage is thin and releases are batched quarterly, no coordination framework will help, because the constraint is downstream of everything the framework touches. Trunk-based development, automated testing and small batches are prerequisites, not phase two. This is the single strongest predictor we observe. See trunk-based-development-and-why-it-matters.

Funding model. Annual project budgets create temporary teams, which destroy domain knowledge and force the matrix allocation that generates most resource dependencies. A framework layered on project funding will spend its energy fighting the funding model and will lose. See from-project-funding-to-product-funding.

Architecture. Team boundaries that cut across module boundaries generate dependencies mechanically, at a rate no amount of planning can absorb. The coordination cost is a direct function of how badly the two maps disagree.

Organisational culture. Westrum's typology is useful here: a pathological or bureaucratic organisation will implement any framework as compliance theatre, because information flows are the actual mechanism and the framework does not change them. A generative organisation will get value from almost any of these options, including the ones you would not have chosen.

How to choose without pretending to certainty

Treat the decision as reversible and make it at the smallest scope that will teach you something. Pick one real value stream — genuinely end-to-end, from request to production, including whatever governance it must pass — and apply your chosen approach there for two or three planning cycles. Instrument it with flow metrics and DORA measures rather than framework-compliance measures.

Then be willing to conclude that the framework was not the binding constraint. In most engagements the first cycle reveals that the coordination ritual surfaced dependencies beautifully and that the dependencies themselves are the problem, at which point the useful work shifts to removing them. That is not a failure of the pilot. That is the pilot working.

Resist the temptation to standardise across the organisation before you have evidence. Different value streams have genuinely different coordination needs, and a mandate that every part of the business adopt the same cadence is a decision optimised for the reporting layer rather than for delivery.

What to do on Monday

Run the dependency census on the last two quarters of delivered work. One row per substantial item, columns for which teams had to change something, be asked something, or be waited on. Do not clean it up. You want the raw graph.

Then answer three questions in writing, with evidence, before anyone is allowed to name a framework in a steering meeting. First: what fraction of our lead time is spent waiting on another team rather than working? Second: which three dependencies, if eliminated, would remove the most waiting? Third: for each of those, what would elimination actually require — an architectural change, an ownership transfer, a platform capability, or a change to how the work is funded?

If the answers point to a small number of removable dependencies, do that work first and revisit the framework question in six months; you may find it has dissolved. If they point to a large, irreducible coordination surface, you now have the information to choose deliberately from the table above, and — more usefully — to explain to a sponsor what the framework will and will not fix.