Scaling only the coordination that genuinely needs it
Most scaling conversations start from the wrong question, which framework should we adopt, instead of the right one, does this coordination problem actually require a scaling framework at all. This module opens with descaling as the first real option: many multi-team dependency problems are solvable by better backlog slicing, clearer team boundaries, or removing an unnecessary dependency entirely, and adopting a heavyweight framework before trying those cheaper fixes is a common, expensive mistake.
Where scaling genuinely is warranted, the module compares SAFe, LeSS, and Nexus honestly rather than promoting one, walking through what each framework actually optimizes for: SAFe's structured Program Increment cadence for large multi-team, multi-vendor organizations that need coordinated planning at scale, LeSS's insistence on minimizing added structure and pushing decisions back down to feature teams, and Nexus's lighter integration layer built specifically for scaling one Product Backlog across a handful of Scrum Teams without introducing an entirely separate framework of new roles and events. A framework-matching exercise forces teams to connect an organization's actual constraints, size, industry, existing structure, to the framework that fits rather than the one that is most talked about.
The module closes on managing cross-team dependencies in practice, a dependency-ordering exercise that makes visible how a single team's blocked item can cascade across a whole Sprint, and a descaling check revisited at the end: after choosing a framework, the module asks teams to periodically re-examine whether the coordination overhead they added is still earning its cost, since organizations rarely descale voluntarily once a framework is in place, even after the reason for adopting it has gone away.
Mistakes teams make with this material
Reaching for SAFe, LeSS, or Nexus as a first response to a coordination problem, without first checking whether better backlog slicing or clearer team boundaries would solve it without adding a framework at all.
Picking whichever framework is most discussed in the industry instead of matching the organization's actual size, structure, and dependency patterns to what each framework is actually built to solve.
Failing to surface a dependency during planning, so it only becomes visible when a team is already blocked mid-Sprint and the cascading delay affects several other teams at once.
Keeping a heavyweight coordination structure in place indefinitely after the original coordination problem has shrunk or disappeared, because organizations rarely descale voluntarily once a framework is embedded.
Questions people ask
Should every multi-team organization adopt a scaling framework?
No. Many coordination problems can be solved by descaling first, through better backlog slicing, clearer team boundaries, or removing an unnecessary dependency, which is cheaper and less disruptive than adopting SAFe, LeSS, or Nexus before those options are exhausted.
What is the core difference between SAFe, LeSS and Nexus?
SAFe adds the most structure, with a Program Increment cadence suited to large, multi-team, multi-vendor organizations. LeSS deliberately minimizes added structure and pushes decisions down to feature teams. Nexus adds a lighter integration layer specifically for scaling one Product Backlog across a handful of Scrum Teams without introducing an entirely new framework of roles.
How do you manage cross-team dependencies before they block a Sprint?
Surface them explicitly during planning by mapping which teams' items depend on output from another team, and order the backlog to resolve the highest-risk dependency first, rather than discovering the block once a Sprint is already underway.
Should an organization ever remove a scaling framework once it is in place?
Yes, if the original coordination problem has shrunk or disappeared. Periodically re-checking whether the scaling overhead is still earning its cost matters, because organizations rarely descale voluntarily without a deliberate prompt to reconsider.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
Before adopting any scaling framework, what is the first question to ask?
- Which framework has the best certification
- Does this product genuinely need more than one team, or can it be descaled instead
- How many Release Train Engineers will we need
- Which framework does the tooling vendor support
Most requests to scale Scrum come from organisational structure, not from a genuine multi-team coordination problem. Descaling removes the need before you reach for a framework.