Scaling Framework

The execution rules that came out of agile were written for one team. Agile is the stance that you don't fix the plan up front — you build a small slice, show it, and correct course. Scrum and Kanban both turn that stance into rules, and both assume roughly five to ten people working on one product. At that size everyone who matters fits in the same meeting, nobody has to write down who is doing what because you can see it from the next desk, and one person deciding what comes first is enough.

The trouble starts when headcount grows. Adding a second team is easy; having two teams touch the same product is where new problems appear. The team building checkout waits on an authentication feature owned by the login team. Two teams edit the same code separately and discover the collision on the day they merge. Two teams want to ship in the same week and nobody owns the order. These problems multiply faster than teams do. Two teams have one relationship to manage, four teams have six, eight teams have twenty-eight.

In meetings, the discomfort looked like this. In team A's morning standup, "still waiting on authentication" shows up three weeks running — and team B, the people who need to hear it, aren't in the room. In team B's standup the request never comes up, because it isn't in this cycle's plan. Neither board shows a blockage. The thing that has stopped sits between the two boards, and nobody owns the space between them. Each team reports a healthy cycle to its own stakeholders while the feature the company actually promised slips by a month.

The old answer was to fill that gap with a person: a manager holding the whole schedule in one spreadsheet and handing deadlines down to each team. That pulls decisions the teams used to make back upward, so the short cycles inside each team keep their shape while the real choices return to whoever holds the spreadsheet. A scaling framework tries the opposite: leave autonomy inside the team and add rules only between teams. Where exactly to draw that line — what rises to the top and what stays with the team — is what separates one framework from another.

Everything under scaling frameworks belongs to one branch: complete systems. There are six of them, and you can line them up by how much of the single-team rulebook they touch. At one end sit the ones that leave Scrum nearly untouched and only wire the teams together. At the other end sit the ones that build new layers and new cycles above the teams. Off to the side sits the one that redraws the org chart instead of the meeting calendar.

Three of them only add wiring.

1. Scrum of Scrums — a higher-level meeting where one person from each team shows up on a fixed schedule. It asks the same three questions a team asks itself every morning, one level up: what did we finish, what are we doing next, and what is another team blocking. The only new thing it creates is a meeting, which makes it the lightest of the six and the usual first move when a company reaches three or four teams. When the checkout rep says "we've been waiting two weeks on authentication," the login rep is sitting at the table. That is the whole mechanism.
2. Nexus — a system for managing how the work of several teams merges into one result. If each team builds separately and everything comes together at the end of the cycle, conflicts only surface at the end, so Nexus pulls representatives into a dedicated integration group and merges continuously during the cycle instead. It's aimed at roughly three to nine teams. The integration group isn't a separate department — it's people who still sit on their own teams and take on the merging work as a second responsibility.
3. LeSS — Scrum stretched with the smallest possible change. It scales by subtracting: one product owner, one priority list, one cycle, many teams. The rule is that you add almost no new roles and no new meetings. One list means no team keeps a private pile of work. Five teams pull from the top of the same list, so what matters most to the company is visible on a single page. The cost is that maintaining that one list is hard — if a single person can't hold five teams' worth of context, the arrangement falls apart quickly.

Two of them build layers above the teams.

1. SAFe — a cycle of eight to twelve weeks sits above the team's two-week cycle, and above that sits a layer for company-wide investment decisions. Every layer has its own planning event, owners, and artifacts named in the rulebook, which makes it the heaviest of the six. Starting a large cycle means eight teams spending two days in one room, putting what each owes the others and when on a wall. That's a hundred people for two days spent on planning, so it pays off only where there is a reason to spend it: regulated industries, or organizations of several hundred people with a lot to explain upward.
2. Release Train — several teams shipping on one shared date. It behaves like the train it's named after: it departs on schedule, and a feature that isn't ready takes the next one. Instead of moving the date to fit the feature, you move the feature to fit the date, which collapses scattered per-team release dates into one. It's the engine that drives the large cycle inside SAFe, and it also gets used on its own.

One of them answers with structure. The Spotify model changes how people are grouped rather than how they meet. A small team owning one goal, with product, design, and engineering inside it, is called a squad; a horizontal line grouping the same discipline across squads is called a chapter. Work happens in the squad, while technical standards and career growth are looked after in the chapter. What sets it apart from the other five is that it isn't a rulebook — it's one company's account of itself, published in 2012. The company that published it later asked people to stop calling it a model, because it was a photograph of one moment and they had kept changing since.

The six aren't items on a menu you pick from freely; there's usually an order. Start with a heavy one and you add meetings while decisions drain upward, so most teams start with the lightest higher-level meeting and look further only when it visibly fails. The same wait repeating in that meeting every week means it's time to fix how work gets merged; release dates drifting apart so teams wait on each other means it's time to tie the dates together. Whichever you pick, the first job is the same: reduce the number of places where one team has to wait for another. If checkout has to wait on authentication every single time, no meeting design removes the wait — the new meeting just tells you about it sooner.

"We're three teams now and we still plan separately. Let's start with a scrum of scrums this quarter."

A proposal to begin with the lightest higher-level meeting rather than a full framework, on the grounds that three teams are few enough for one shared table.

"That's not on this train. We'll decide at the next planning session whether it goes on the following one."

It's outside the scope of this shared release cycle, so it waits for the next one.

"Rolling out all of SAFe at forty-five people is too much. Meeting time goes up and building time goes down."

An objection that the framework is heavy relative to the size of the organization, usually followed by a proposal to take only the parts that help.

At Pagedeck the question came up right after the Series A, when the product group split from one team into three: the editor team, the collaboration team owning sharing and permissions, and the team owning plans and billing. Two months in, each team's cycle ran fine, but less was shipping overall than before the split.

Grace brought in material proposing they adopt a framework built for large organizations, and Theo pushed back — three new layers for forty-five people. Mia counted the items marked blocked across all three teams over the previous three weeks: eleven of them, and eight were the billing team waiting on a permissions feature from the collaboration team. The cause sat in one place.

So the three teams changed only two things. One person from each team meets twice a week for thirty minutes, and all three cycles now start on the same Tuesday. The shared start date matters because a team that receives a request mid-cycle has nowhere to put it; starting together lets each team raise what it needs from the others in its own planning session.

A month later the count of waits had gone from eight to five, which is not dramatic. What changed is that the waits became visible on the day they were requested, and that made the next decision obvious. Moving the permissions feature out of the collaboration team and into the billing team came up in that meeting. The meeting didn't supply the answer; it showed where to cut.

The most common mistake is expecting that adopting one of these keeps the pace steady as teams multiply. The word "scaling" reads like output scaling with headcount. What these systems actually do is manage the coordination cost, not remove it. As shown above, connections between teams grow much faster than the teams themselves, and the new meetings and merge work consume time of their own. Double the people and output doesn't double — run it well and it lands somewhere near one and a half times. A company that misses this doubles headcount, and six months later leadership asks why nothing got faster while the teams answer that the framework was set up wrong. The mismatch is in the original expectation, not the framework. Planning headcount works better when the extra coordination time is subtracted in advance.

The second mistake is treating the choice of framework as step one now that there are several teams. Six named options, each with certifications and material behind it, make choosing feel like the natural starting move. But every one of them does the same core thing — surface the waits between teams and coordinate around them — while shrinking the waits themselves depends on how the teams were divided in the first place. If finishing one feature requires passing through three teams, no meeting removes those three handoffs. Reverse the order and a company spends six months with more meetings and the same delivery time, blames the framework, then switches to a different one. The first question is which pairs of teams wait on each other every week, and merging that pair or redrawing the boundary usually comes before adding a meeting.