The Scrum of Scrums That Should Be an Email

TL;DR Scrum of Scrums exists to solve cross-team problems, not report progress. When it becomes a status meeting, it wastes the time of the one person per team who knows exactly what’s blocked. Here’s what makes it fail and what it looks like when it works.

You know the drill. Every team rep takes their turn.

“We finished the auth module. Next sprint we’re doing notifications. No blockers.”

Next team. Same format. Same energy. The meeting ends on time and nothing has changed.

That’s not a Scrum of Scrums. That’s a standup for people who don’t work together.

What It’s Actually For

The original idea (Sutherland and Schwaber, 1996) was simple: when multiple teams work on the same product, someone needs to surface problems that exist between teams, not just within them. Dependencies. Blocked work. Integration conflicts. Things no single team can solve alone.

The question that should drive every Scrum of Scrums isn’t “what did you do?” It’s “what’s in your way that someone in this room can fix?”

If nobody answers that question, the meeting failed. Even if it ran on time.

The Four Anti-Patterns

1. Everyone reports, nobody solves

The meeting turns into a round-robin status update. Each rep gives a three-sentence sprint summary. Others listen politely while checking Jira.

Nobody raises a real blocker because nobody expects anyone to do anything about it.

👉 Fix: change the format. One question per team: “What’s blocking you that another team caused or could fix?” If the answer is nothing, they’re done. No update needed.

2. The wrong people in the room

Scrum Masters attend because it’s on their calendar. But the actual blocker is two developers arguing about an API contract, and neither of them is here.

The rep logs the problem, assigns it to nobody, closes the meeting. Two weeks later the ticket is still open.

👉 Fix: rotate who attends. Bring the person who actually owns the blocked work. Sometimes that’s the Scrum Master. Often it isn’t.

3. Problems logged, not solved

A dependency gets raised. Everyone nods. Someone creates a ticket. The ticket sits in a backlog nobody reviews.

This is the most common failure mode and the most invisible one. The meeting feels productive because something was written down. It wasn’t. It was deferred.

👉 Fix: every blocker raised in Scrum of Scrums needs an owner and a resolution date before the meeting ends. Not a ticket. A person and a deadline. If you can’t commit to that in 15 minutes, schedule a working session for tomorrow with the two teams involved and end the meeting early.

4. Cadence that outlived its purpose

The meeting was set up weekly when the ART launched. Three PIs later, teams are less dependent, integration is smoother, and there’s nothing to discuss most weeks.

But the meeting stays. Because it’s on the calendar.

👉 Fix: let cadence emerge from actual need. When cross-team problems are rare, meet less. Some mature ARTs run Scrum of Scrums on demand, triggered by a dependency raised in PI Planning or a blocker from the previous iteration. That’s not laziness. That’s the meeting doing its job.

The Test

At the end of your next Scrum of Scrums, ask one question: what got unblocked today?

If the answer is nothing, you just had a status update. Everyone already had that information before walking in. The meeting added nothing except a shared calendar slot.

That’s not coordination. That’s theater with better attendance.

Fix the question, and the meeting fixes itself.