Understanding the different approaches to scale agile can be overwhelming. After all, despite agile being originally aimed at small teams—which includes the scrum framework—there have been quite a few attempts at scaling it.
In this article, we’ll cover one of these approaches: scrum of scrums (SoS.) You’ll understand how it works, learn about its history and find out the similarities and differences between it and other approaches.
Scrum of scrums is a technique to scale scrum to larger groups. In a nutshell, it consists of coordinating the work of several scrum teams working together, by creating a larger scrum team whose members will be regular, smaller teams.
A successful adoption of scrum of scrums requires that each individual team be a high-performing scrum team. That is to say: don’t attempt to scrum in the large until you’re doing it successfully in the small.
Scrum of scrums is often “embedded” into other scaling approaches, serving as the starting point for those efforts. Also, people often mix it up with other approaches, particularly scrum at scale—or [email protected], as it’s officially called. Later in the article you’ll learn how the two approaches relate to each other in more detail.
Learning about the history of SoS is learning about the history of scrum itself. So, let ‘s do it.
Scrum was originally created by Jeff Sutherland and Ken Schwaber. Both of them were already experimenting with approaches that would become the framework by the early nineties. They published the approach with a paper in 1996 at OOPSLA, having codified it in a workshop at the same conference the year before.
Like most methodologies under the “agile” umbrella, Scrum champions small teams, with no more than 9 people. Empiricism has shown that smaller teams perform better, among other reasons, due to the streamlined communication.
However, Sutherland and Schwaber, at some point, needed to work with a larger organization. The experiences in scaling scrum led Sutherland to write an article in 2001 in which he formalized Scrum of scrums.
Compared to many of the other approaches to scale scrum, scrum of scrums is incredibly straightforward. It works exactly the way its name suggests: it’s a scrum composed of smaller scrums, helping you coordinate a larger number of people by dividing them into smaller scrum teams with up to 10 members.
Each individual team names an “ambassador” to participate on the scaled version of the daily standup. Another new role is the scrum of scrums master, which is simply a scrum master, but at a higher level.
We’ll now discuss the similarities and differences between scrum of scrums and competing approaches.
There are plenty of similarities and differences to be found. For starters, scrum of scrums is often “embedded” into other approaches at scaling scrum, serving as a starting point for those efforts. Also, SoS shares similarities with lightweight approaches that aim to leave scrum as intact as possible.
On the other hand, SoS is dramatically different from approaches that build a lot on top of scrum, adding additional layers, roles and ceremonies.
Finally, SoS is often confused with [email protected]—or “scrum at scale”, as it’s also called. As you’ll see, there are related but still two different approaches.
LeSS stands for Large-Scale Scrum. It shares some similarities with SoS and regular Scrum, including all of the regular roles and events. As it turns out, LeSS is one of the least prescriptive frameworks out there, not adding a bunch of extra things on top of scrum.
However, there are important differences. LeSS actually offers two frameworks according to number of people in the organization:
In the small LeSS framework, there’s a single PO, backlog, definition of done, and sprint for everyone. The teams are still cross-functional teams, as in regular scrum.
In LeSS Huge, there are divisions called “requirement areas”, which correspond to major areas of customer concern inside a product. Each requirement area has its own product area owner and contains from four to eight teams. All teams work from the same backlog. However, every item is assigned to a single product requirement area, so each team can focus on its own work.
Scrum of scrums, on the other hand, deals with the problem of further scaling by adopting the same structure at a higher level. In other words, you can have a scrum of scrums of scrums, to coordinate multiple scrums of scrums. The roles and events are also scaled to this level: you have a daily scrum of scrum of scrums meeting, and a scrum of scrum of scrum master.
SAFe (Scaled Agile Framework) was first introduced in 2011 and since then has gone through five major updates.
SAFe is targeted at the enterprise, and aims to support a large number of people, in situations that call for tighter control. So, SAFe introduces many new artifacts, roles, and events, making it one of the most complex and prescriptive frameworks out there.
On the other hand, SoS is a natural evolution of scrum, connecting a relatively small number of regular scrum teams.
Learn more about Scaled Agile Framework here.
Last but not least, let’s compare scrum of scrums and scrum at scale.
For starters, Scrum of scrums is way older: it was first formalized in an 2001 article from Sutherland, but he and Schwabber had used the scaled approach before.
Img Src: scruminc.com
[email protected] is a more recent enterprise, launched in 2018 —despite being worked on as early as 2014—as a partnership between Sutherland and Scrum, Inc (without the involvement of Schwaber, who has yet another framework, Nexus, to scale scrum.)
Scrum at scale is a relatively lightweight framework, specially when compared to heavy-weights such as SAFe. However, it has ambitious goals, since it attempts to reduce the time to decision-making in the whole organization. Scrum of scrums, on the other hand, only attempts to coordinate a number of scrum teams.
Why is there so much confusion between these two approaches? For starters, Jeff Sutherland is involved in the creation of both. Also, the naming is somewhat confusing, so it’s understandable that people would think they’re synonyms.
Finally, there’s another strong relationship in play between the two approaches. And that’s the fact that scrum at scale uses scrum of scrums to scale and coordinate the scrum teams working on the increment. It then adds a few new roles on top of it, including ones that bring agility to the management part of the organization.
Scrum of scrums is exactly what its name suggests: a scrum composed of smaller ones. That means it features the same roles as regular scrum.
However, there are some additional roles. For starters, each internal team has a representative to attend the scrum of scrum meetings. And there is a “scaled” version of the scrum master, called scrum of scrums master.
The scrum of scrums has its own backlog in order to keep track of impediments to the proper collaboration between teams.
If SoS features the same roles as regular scrum, it also features the same events.
Besides the regular events, SoS relies on a scaled version of the daily meeting or daily scrum. A representative or ambassador of each team attends this event, in which the teams can coordinate and ensure impediments to their collaboration are removed.
The scaled scrum follows pretty much the same agenda as a regular scrum meeting. Each participant answers the same questions:
However, there’s one major difference between the regular and the scaled versions of the scrum meeting. Typically, you don’t use the daily to solve problems; you only want to find out about the problems, but they’re supposed to be addressed later.
On the other hand, it is OK to solve problems during the scaled version, since they affect other teams and the collaboration between them. So, it makes sense to timebox this meeting using a longer duration than that of the regular scrum.
Also, despite being recommended to hold the scrum of scrum meetings daily, there are teams that report success while holding it less frequently—2 to 4 times a week, for instance.
Unlike some of the other attempts at scaling scrum, SoS isn’t a heavy-weight framework of its own. Instead, it’s a lightweight approach composed of a few smaller, regular scrums.
This has both pros and cons. On the bright side, since it doesn’t add a lot of new artifacts on top of scrum, it’s not so hard to get started with—at least for teams who are already doing scrum successfully in the small.
On the other hand, it also means scrum of scrums is susceptible to most of the common pitfalls of regular scrum:
As mentioned, getting started with scrum of scrums might be easier than other approaches at scaling scrum, since it doesn’t add a bunch of extra layers and roles on top of the original framework. Here are some tips to get started:
The original scrum framework was intended for a single, small team. However, companies will often have more teams, and the need to connect and coordinate the teams appears.
Created by scrum’s co-founder itself, scrum of scrums is one of many approaches to scale scrum. Unlike many of the competing approaches, SoS is a natural extension of the original framework.
Among its characteristics, it’s notable that scrum of scrums is often embedded into other more complex and heavy-weight frameworks. That serves as a testament to its effectiveness.