Descaling Agile

---

The Reframe

Most scaling frameworks accept the premise that many teams need to coordinate on shared work, and then offer mechanisms — ceremonies, roles, cadences — to make that coordination work. Descaling rejects the premise. It argues that the coordination problem the team is solving is usually a symptom: the work has been organized into the wrong shape. Reshape the work, and most of the coordination disappears.¹

The movement has roots in Craig Larman and Bas Vodde's work on LeSS, in the simplification arguments of Spotify-era Henrik Kniberg, and in Marty Cagan's repeated insistence that the best product organizations are made of small, autonomous, end-to-end product teams.

The Diagnostic Question

The descaling lens asks of any coordination need: could this be eliminated by reshaping the teams?

• Multiple teams contributing to one feature → fewer, broader teams that own the feature end-to-end.
• Cross-team dependencies in PI Planning → shared services exposed as platforms; team boundaries redrawn.
• "Scrum of Scrums" coordinating slices of one product → one product backlog, smaller team set, less coordination.
• Component-team handoffs → feature teams that own the vertical slice.
• Architectural review board → fewer teams making fewer cross-cutting decisions.

If reshaping is possible, descaling argues it's almost always the better move. The coordination machinery — even when well-designed — produces overhead that compounds.

Conway's Law as the Driver

Melvin Conway's 1967 observation — "organizations design systems that mirror their communication structures" — is the foundational insight.² Most large agile programs fight Conway's Law: they organize teams around components or skills, then add coordination machinery to deliver value across those boundaries. The architecture mirrors the team structure; the coordination cost mirrors the architectural complexity.

Descaling inverts the move. Decide what the architecture should look like, then organize teams to mirror it. If the architecture should have a small number of independent services, the teams should be similarly few and similarly independent. The coordination need shrinks because the work was reshaped before it was assigned.

Practical Descaling Moves

1. Reduce team count, increase team breadth

Twelve teams of five become four teams of fifteen — full-stack, end-to-end, customer-facing. The internal communication within the larger team replaces the cross-team coordination of the smaller ones, and is typically cheaper.

2. Convert components to platforms

Component teams that get pulled into every feature become platform teams that expose stable services to stream-aligned teams. The platform team's work is self-service consumed; the dependency turns into an interface.

3. End the "shared resource" pattern

If specialists (security, UX research, ML) are perpetually overloaded across many teams, either embed them per team where the demand justifies, or build an enabling team that teaches the practice rather than performing it.

4. Kill the architectural review board

Replace it with shared principles, paved roads, and ownership clarity. If three architects can decide the system's direction, the teams probably weren't autonomous to begin with.

5. Eliminate the program manager role

If teams need a program manager to coordinate them, the teams are too narrow. The cost of the role is one signal; the underlying coupling is the cause.

Where Descaling Breaks

• Genuinely large, coupled products. Some products — operating systems, multi-decade legacy systems, regulatory-driven domains — cannot be cleanly split. Descaling has limits.
• Talent inventory constraints. Reshaping teams requires people with broad skills. If everyone is a narrow specialist, the broader teams don't function.
• Political constraints. Reorganizing many teams threatens many managers' headcounts and careers. Descaling is technically simple and politically explosive.
• Conway's Law inertia. Once the architecture has crystallized around team boundaries, changing the teams without changing the code is harder than it sounds.

The Modest Version

Most organizations cannot fully descale. What they can do is descale at the margins: remove one layer of coordination, merge two adjacent teams, convert a component team to a platform service, replace a planning-coordination role with shared documents and async tools. Each move is cheap; the cumulative effect is significant.

Coaching Tips

Ask the descaling question first.

Before picking a scaling framework, ask: could this coordination be eliminated by reshaping the teams? Usually some of it could.

Track coordination overhead.

Meetings per week, handoffs per feature, escalations per quarter. The numbers reveal where the team structure is producing waste.

Convert one component team this quarter.

The smallest meaningful descaling move. Pick one team, redefine them as a platform service, watch what coordination disappears.

Don't romanticize small teams.

Two teams of three are not always better than one of six. Smallness has costs too. The right size depends on the work.

Name the political reality.

Descaling threatens managers and existing power structures. Address that honestly — pretending it's purely technical will fail.

Pair with Conway's Law analysis.

Map the system architecture. Map the team structure. The mismatch is the descaling opportunity.

Summary

Descaling is the most under-considered move in the scaling conversation. Most leaders default to picking a framework when faced with coordination problems, when the better question would have been whether to reshape the teams instead. The descaling argument is uncomfortable because it implicates organizational design — many managers, many headcounts, many habits — but it produces structurally simpler outcomes than any framework can. The rare organizations that descale rather than scale end up with the kind of agility that frameworks promise but don't usually deliver.

Back to Scaling Agile