Scaled Agile Framework

Scrum was written for one team. Five to nine people work from a single list on a two-week cycle, and inside that boundary everyone can check daily what everyone else is doing.

Grow to eight teams and a space opens up that the rules never reach. The payments team cannot finish until the identity team changes something first, but the two look at separate lists on separate cycles. Payments waits two weeks, and the only trace is one line in each team's retrospective saying they were blocked by another team. It is not a problem solvable inside a team, and it never appears as anyone's fault, which is part of why it persists for quarters at a time.

A different problem arrives from above. When leadership asks what will exist in six months, adding up eight teams' two-week plans does not produce that answer. In a regulated industry, being unable to answer the question is itself a finding.

The Scaled Agile Framework (SAFe) fills both gaps by adding layers. An eight-to-twelve-week cycle sits above the teams' two-week cycles, and above that sits a layer handling company-wide investment decisions. Every layer has its planning meeting, its accountable role and its artifacts specified by name, which makes it the heaviest and most detailed of the scaling systems.

Bind the teams building one product into a single long cycle, and start that cycle with everybody in one room reconciling dependencies.

1. Group the teams. Five to twelve teams belonging to one product or one value stream form a group — 50 to 125 people. That group becomes the unit that releases on the same date, and the way it operates is called a release train.
2. Fix the length of the long cycle. Usually eight to twelve weeks, holding four to six two-week sprints. The final sprint carries no new features and is spent on integration and improvement.
3. Open the long cycle with a planning event. For two days everybody is in one room; each team sets objectives for the cycle and posts on a wall what it must hand to other teams and what it must receive. Once posted, who is waiting on whom and when reads off a single surface. Anything unresolved in the room gets written down as a risk with a named owner. The wall is the part people remember; most of the rest of the event is bookkeeping around it.
4. Run the cycles. Inside each team, ordinary scrum continues. Every two weeks team representatives meet to check that the posted dependencies are actually holding.
5. Close the long cycle. The whole group demonstrates what it built in one session and holds a retrospective at group level rather than team level. What comes out feeds the next long cycle's plan.
6. Decide upstairs where people and money go. That layer moves on a quarterly or half-yearly rhythm, and which groups grow and which get wound down is settled there.

Four situations suit it: one product with five or more teams and many handoffs between them, a regulated industry that has to produce an audit trail, an organization that has to commit externally to a six-month date, and work that mixes in fixed-schedule elements like procurement or hardware.

Four limits are worth knowing.

1. It is heavy. A two-day planning event with 100 people puts 200 person-days into planning alone. It only pays for itself in organizations with a reason to spend that, and the number is worth computing before the first event rather than after.
2. Learning it takes time. Each layer has its own role and artifact names, so acquiring the vocabulary is a project of its own.
3. More layers move decisions upward. What a team is allowed to settle narrows, and in the worst case the organization uses the word agile while executing a plan handed down from above in order. This is where the most frequent criticism of the framework lands.
4. A settled plan resists change. With eight to twelve weeks posted on a wall, changing direction in week five means renegotiating eight teams' commitments.

Below that scale, lighter options exist. With three or four teams, start with representatives meeting as a scrum of scrums; if integration is the problem, look at Nexus; if you want a thin rulebook, look at LeSS.

"With eight teams, a coordination meeting isn't enough. Let's evaluate adding a longer cycle."

Dependencies between teams have outgrown a single meeting.

"The planning event is 200 person-days. Let's establish it earns that first."

Putting the adoption cost into numbers before deciding.

"This is agile in name only. We're executing a plan handed down to us in order."

Naming the state where added layers moved the decisions upward.

At Pagedeck the framework is not used. With 45 people and two product teams, the dependencies between those two get settled in one weekly meeting. Grace evaluated it once last year and decided against it.

The reason got written down as well. There were only five or six dependencies worth posting on a wall, and that is an amount Mia and Theo reconcile in a thirty-minute call. The note also records the condition for revisiting: more than four teams.

The most common misreading is that this is an advanced version of agile. The name contains "scaled" and it has more layers, so it reads as a later stage of development. But what the framework addresses is size, not maturity. If one team runs scrum well, this is not the next step. Two teams adopting it gain meetings and documents and change nothing else. Maturity and size are separate axes, and this framework moves only one of them. The basis for choosing is not how good you are but how many teams there are and how many handoffs run between them.

The second misreading is that adopting it makes an organization agile. The documentation and training are thorough enough to make it look like following the instructions is sufficient. But what transfers easily is meeting names and document templates, and what transfers with difficulty is decision authority. Introduce the planning event into a setting where teams cannot decide what to build, and you get a two-day ceremony for posting a handed-down list onto a wall. The thing to check before adopting is not whether you can follow the rulebook but what you intend to leave to the teams.