Introduction
Scaling an Agile organization is hard, and most attempts produce frameworks that look agile from outside while losing the substance from within. The interesting question is rarely "which scaling framework should we adopt." It is "is scaling actually what our situation needs, or would smaller teams, clearer ownership, and better coordination patterns serve us better?"
The frameworks below all attempt to coordinate many teams toward a shared outcome, but they make very different bets about how to do that — how much ceremony, how much governance, how prescriptive the roles. Descaling approaches argue the opposite case: that most coordination problems are really team-design problems that disappear when teams become small, autonomous, and well-aligned.
Topics
Descaling Agile
The counter-pattern that asks whether the coordination problem you're solving is actually a team-design problem in disguise.
Read →Scrum@Scale
Jeff Sutherland's lightweight scaling approach — a Scrum of Scrums of Scrums tied to a strategic backlog through MetaScrum.
Read →LeSS (Large-Scale Scrum)
Bas Vodde and Craig Larman's framework that scales by adding teams to a single Product Backlog, not by adding processes.
Read →Nexus
Scrum.org's framework for coordinating 3-9 teams working on a single product, with integration as a first-class concern.
Read →SAFe Essentials
The most adopted (and most criticized) scaling framework. The Essential configuration is its lightest, team-of-teams form.
Read →Agile Release Train
SAFe's coordinating unit: a long-lived team-of-teams that ships value on a synchronized cadence around a shared Program Increment.
Read →PI Planning Mechanics
The big-room planning event at the heart of SAFe — agenda, mechanics, and the disciplines that make it work or fail.
Read →Spotify Model
Squads, tribes, chapters, guilds. Less a framework than a vocabulary — the source of more cargo-cult than any other Agile pattern.
Read →Disciplined Agile Delivery (DAD)
Scott Ambler's process-decision toolkit that gives teams options across the delivery lifecycle rather than a single prescribed path.
Read →Amplio System
Al Shalloway's evolution of FLEX, designed to make scaling decisions through the lens of value streams and learning rather than ceremonies.
Read →Agile Fluency Model
James Shore and Diana Larsen's four-zone model that frames maturity as deliberate investment, not a linear progression.
Read →Flight Levels
Klaus Leopold's framework for coordinating across operational, coordination, and strategic levels — without prescribing team structure.
Read →Team Topologies
Skelton and Pais's four team types (stream-aligned, enabling, complicated-subsystem, platform) and the interaction modes between them.
Read →Team Self-Selection Workshops
The reorganization technique that lets people choose their own teams within constraints, instead of assigning them top-down.
Read →Choosing — or Refusing to Choose
The biggest mistake in scaling is treating "which framework" as the most important decision. It is not. The most important decision is whether the work you are trying to coordinate actually belongs in one program, or whether it should be split into smaller, more independent pieces with clearer ownership and lighter coordination between them.
If scaling is genuinely necessary, pick the framework that fits the organization's tolerance for ceremony, the team's maturity, and the coupling of the work. SAFe gives the most structure and the most overhead. LeSS and Scrum@Scale give the lightest scaffolding. Team Topologies sidesteps the framework question entirely by changing how the teams are shaped in the first place. None of these is right for every situation. All of them are wrong for some.
Back to Hubs