The Reference Model in Scrum@Scale is a very important concept that helps organizations start transformations the right way. Instead of launching a transformation in a big-bang manner — for example, starting with 200 teams at once (which some companies actually do, moving from zero Scrum to 200 teams within weeks) — Scrum@Scale introduces the idea of the Reference Model. This means that instead of starting with 200 teams, we begin with just two or maybe three.

Why do we do this? There are several key benefits. First, we want to start Scrum the right way. If we begin with 200 teams, we’ll face huge challenges getting those teams to a good level of Scrum quality. Finding 200 Scrum Masters, training everyone properly, and bringing them up to speed is an enormous task. Instead of dispersing our energy across hundreds of teams, we focus our best people on those two to three reference teams. These teams set the benchmark for all the teams that follow — and that’s where the name “Reference Model” comes from.

For example, if you have a senior coach, make them the Scrum Master of one of those starting teams. You don’t want junior Scrum Masters experimenting on such a critical stage. If this is the beginning of your organization-wide transformation, you want your strongest people leading it. This is the first major benefit of the Reference Model: it ensures a very high level of team-level Scrum quality and creates a clear example for others to emulate.

The second benefit is that transformations are inherently political. By focusing your energy on two or three teams, you can achieve early wins. Having your best people on these teams allows you to show fast progress, which builds trust, generates buy-in, and creates momentum for the broader transformation.

The third benefit — and a very important one — is how the Reference Model handles impediments. Impediments are normal in Scrum. Some are small — like a broken printer or a staging environment that’s down. Others are large, structural impediments, like organizational vacation policies or legal constraints, which individual teams can’t fix on their own. If you start with 200 teams, they’ll all hit these structural blockers at the same time, creating chaos. But if only two or three reference teams hit those issues first — acting like a scouting force — they can identify and help resolve them with management before the rest of the teams even encounter them.

A classic example is vacation policy. Unlike fixing a printer, changing vacation policies is complex. In many companies, deploy dates conflict with vacation deadlines, causing major issues. By having the reference teams hit these problems first, you gain time to resolve them. That way, when the rest of the organization scales up, those issues are already fixed or mitigated.

The Reference Model gives you a small, highly trained group of teams that:

Serve as role models for best practices.

Deliver early wins to build political support.

Encounter and help resolve impediments ahead of the main rollout.

This is why using the Reference Model is so effective — it prevents your entire organization from grinding to a halt when scaling Scrum.

If you’re interested in learning more about business agility or Scrum@Scale, head to teamflow.de, where I offer regular seminars on these topics.