Scrum of Scrums

Past three teams, a state appears where each team runs properly and the space between them jams. The payments team has been waiting two weeks on an answer from auth, and on the auth team's list that request sits twelfth. Both teams are working well by their own standard. The jam has no owner because it doesn't live inside either team.

The word "waiting" gets said every day. It gets said in each team's daily scrum — a meeting nobody from the auth team attends. With no channel carrying a sentence repeated inside one team out of that team, the same sentence is uttered twenty times over two weeks while the other side has no idea the request is urgent.

Having a manager relay it in the middle was tried. Two things caught. The relaying person can't hold all the technical context, so the request shifts slightly each time it's passed; and when that person takes leave, the channel closes.

So one meeting got added on top, putting team representatives in the same room. Since the only new thing is a meeting, it's the lightest of the multi-team systems and the first thing teams of three or four try. The payments representative saying they're waiting, with the auth representative sitting right there, is the whole of what this meeting does.

Holding to 15 minutes is the first rule. Six steps.

1. Hold it two or three times a week. Daily makes it one more version of the team's own meeting; weekly means a wait can take up to five days to surface.
2. One person per team. Six teams, six people; anyone attending to observe doesn't speak.
3. Answer three questions at team level: what our team finished since the last meeting, what we'll do before the next one, and what we're blocked on because of another team. It's the three questions individuals answer inside a team, moved up a level.
4. Give the time to the third question. The first two are context; the third is the reason this meeting exists. Whoever is facilitating cuts the first two short when they run long.
5. Attach an owner and a date to each blocker on the spot. Don't discuss what broke and why here — the two representatives agree to meet after the meeting. Whether the 15 minutes holds depends entirely on this rule.
6. Start the next meeting by reviewing the previous list. Without that step the same wait gets reported fresh each time, and after a few weeks of that, attendees learn that saying it changes nothing. A list carrying dates is the only thing that makes the meeting worth attending twice.

What it doesn't do is also fixed. It isn't a status meeting, and it doesn't decide what comes first. Priority belongs to each team's product owner, and this meeting goes only as far as surfacing who ended up waiting because of those priorities. Start discussing technical design and the 15 minutes is gone.

Who attends decides whether this works. On paper it's each team's scrum master, but the person actually needed is whoever knows what their team needs from other teams. Which is why engineers attend on many teams. Seat someone without the technical context and a blocker doesn't get resolved in the room; it ends with a promise to check.

A different person attending each time is its own problem. Nobody carries the context of the previous list, so each team designates one person and sends a stand-in only when that person can't make it.

Three to eight teams is the workable range. Past nine, 30 seconds each fills the 15 minutes, and people spend most of it sitting with teams unrelated to their work. At that point you split into two groups of related teams, or move to a heavier system. Relevance decides the size, not headcount.

The time to start is when there are three teams and the same wait has recurred twice. With two teams this meeting isn't needed: it puts a meeting around something two people could say to each other directly.

Setting a time to stop is worth doing too. Three weeks with no blockers and you cut it to weekly or drop it. That may be the result of dependencies genuinely shrinking, and keeping the meeting turns that achievement into 15 minutes with nothing to report.

The signal to move to something heavier also comes from here. The same integration problem appearing weekly means you need a system that manages integration; teams waiting on each other's mismatched release dates means it's time to bind the dates with a release train.

"Take that between the two teams after this. I'll put it on the list."

Facilitation that holds the 15 minutes while recording the wait.

"Let's start with the three items from last week."

The order that begins with the list.

"Third week with no blockers. Let's go weekly."

Giving grounds for reducing a meeting.

Pagedeck started this after splitting into three teams. Documents, payments, and auth each ran two-week cycles, and in the first cycle half the carried-over work was waiting on another team.

Theo ran it twice a week for 15 minutes and recorded only the blockers. Seven items came out of the first meeting, and five of those were requests the other team didn't know had arrived. None of the five had been refused; none had been seen. Two cycles later, work carried over from waiting on another team was down to a quarter.

The most common reading is that this is a higher decision-making forum. The name implies a level above and representatives are gathered, so it looks that way. But the seat holds no authority. It can't change any team's priorities, and if they need changing, the route is that team's product owner. Treat it as a decision forum and decisions made inside teams migrate upward, which leaves each team unable to plan its own cycle.

The other frequent belief is that more teams automatically means needing this. More teams need coordination, so it's a natural inference. But this meeting earns its keep only when the teams genuinely wait on each other. In an organization split cleanly enough that waiting is rare, you get a meeting with nothing to report. The first move isn't opening a meeting; it's reducing the places where one team has to wait at all. Splitting teams by feature costs less than coordinating teams split by layer.