Large-Scale Scrum

Scrum was written with one team in mind. One person setting priorities, one list of things to build, one two-week cycle, all attached to a single team. The moment several teams work on one product, that whole set gets copied, and every question starts having several answers.

Pagedeck hit this right after splitting engineering into three teams. Each team got its own person setting priorities, which produced three lists — and the slow document loading that customers complained about most was near the top of none of them. Every list was defensible on its own terms. What disappeared was any seat that could say what mattered most across the company.

The usual fix is to add a layer above the teams: a coordination meeting, a role that owns that meeting, and documents to bring to it. Decisions that used to happen inside a team move upward.

Large-Scale Scrum (LeSS) went the other way. Instead of building a layer above the teams, it has several teams share the rules one team was already using. One owner, one list, one cycle — the only thing that multiplies is the number of teams. Rather than adding process to absorb the scale, it removes structure so there is less scale to absorb.

Merge the things teams will share before you split the work, then arrange the meetings around that.

1. Keep the shared assets singular. The product owner is the one person who makes the final call on priority, and the product backlog is the ordered list of what might get built. There is one of each regardless of team count. The definition of done — the shared bar for calling work finished — and the sprint calendar are shared too, so five teams start and end on the same days.
2. Run part one of sprint planning with everyone. Two or so people per team join the product owner and work down the list deciding which team takes what.
3. Run part two per team. This is where a team works out how to build what it picked up, so it stays inside the team, and when one feature spans two teams those two sit in the same room.
4. Coordination during the cycle happens through people rather than new meetings. Teams touching the same area send one person to sit in on the other team's daily scrum. It's a 15-minute meeting, so listening in costs almost nothing.
5. Hold one sprint review. Reviewing team by team would make stakeholders sit through five sessions, so the teams set up booths in one room and people walk around the parts they care about.
6. Run retrospectives in two layers. A team retrospective looks at how that team works; an overall retrospective looks at problems between teams and obstacles in the organisation.

No new roles get created. There is no dedicated coordination manager, and one scrum master covers up to three teams. What does change is how teams are cut. Split them into a front-end team and a back-end team and every feature entangles three of them, so teams are formed to carry a feature from the screen down to the server.

It fits one product built by two to eight teams. The product has to be coherent enough to rank on one list — mix a payment system and an internal tool into the same backlog and there's no basis for ordering them. Past eight teams, the work is divided into a few requirement areas with an owner for each, though even then the product backlog stays single.

Three limits show up in practice.

1. The load on one owner is heavy. For five teams to pull from one list, that person has to understand five teams' worth of work, and when they fall behind, five teams fall behind together.
2. Reorganising comes first. Teams split by component have to be rebuilt around features and middle management roles change with them. Import the meeting sequence while leaving the org chart alone and only the names change, while per-team backlogs quietly survive.
3. A thin rulebook means more is left for you to decide. Unlike SAFe, where each layer has named meetings, roles and artifacts, there are many blanks here, and organisations that want a script to follow find those blanks expensive.

Comparing the neighbours makes the position clearer. Scrum of scrums adds a single meeting of team representatives and nothing else, and Nexus concentrates on the work of integrating what several teams built. This framework touches more than either, but in the opposite direction — it takes structure away rather than adding it.

"There's one backlog. If we keep separate lists per team, this isn't LeSS."

Once teams stack their own lists, the premise of the whole approach is gone.

"Only two people per team in part one. The details are yours to work out in part two."

The joint session distributes work; design goes back to the teams.

"Don't create a meeting for that — have the two teams sort it out directly."

Pushing back on the habit of answering every coordination need with a recurring meeting.

Pagedeck's first cycle under this ran roughly like that. Grace decided against per-team owners, Mia merged the three lists into one, and in part one the three team representatives worked down from the top. Slow document loading sat at the top, so two teams picked it up together and each worked out its own half in part two.

The hard part turned out to be the list rather than the meetings. Mia was ordering work across three teams without knowing all of it, so items near the top kept changing mid-cycle. After that, one person from each team joined a weekly session to refine the list together.

People often read it as a smaller version of SAFe for smaller groups. Both sit in the same drawer labelled scaling, so the difference looks like size. The difference is direction. SAFe adds layers and cycles above the teams to absorb a large organisation; LeSS removes structure above the teams so there is less to absorb. Adopt it expecting the smaller version and you wait for a layer that will sort things out from above — no such layer exists, so decisions stall while the cycles keep turning.

The second misreading is that fewer rules make it easier to adopt. By rulebook thickness it looks that way, but the thin rulebook works only because the way teams are cut and the way managers work were changed first. Skip that reorganisation and take the meeting names, and you end up with fifteen people in part one while decisions still get made outside the teams and per-team lists live on.