Practice: Scrum of Scrums

A “scrum of scrums” (“SoS”) is one of the options to Coordinate Across Program. In a scrum of scrums, someone from the coordination meeting of a subteam (a scrum) attends the coordination meeting across all teams within the program (the scrum of scrums).

The focus of the scrum of scrums is the larger collection of teams, some portion of the value stream, rather than a single team. Its members come from the multiple working-surface teams in that value stream (such as a line of business or program), as well as members representing the value stream.

A scrum of scrums includes both a structure (including who may join and what they contribute to the team) and protocols (such as rules for conducting SoS meetings).

A scrum of scrums is usually facilitated by someone whose focus is on the overall value stream and who is concerned with the issues affecting the system as a whole. Other members from the value stream level may also participate.

As traditionally practiced in agile, a scrum of scrums is often very useful but can be incomplete. It is light on handling system issues such as risk and change. Thus, SoS should be supplemented with additional approaches to address these kinds of concerns. SoS is most effective in the context of an overall, coordinated systems approach such as Disciplined Agile.

Why to do this Practice

A value stream (such as a program or a continuous-production software line) must coordinate the efforts of multiple teams working together on different aspects of the same high-level system goal(s). This requires vertical communication between people at the value stream level (system as a whole) level, and those working in teams on the various parts of the system. It also requires horizontal communication between the teams themselves.

Scrum of scrums is one technique for achieving both vertical and horizontal communication. It brings together people from both the value stream and team levels, and it helps identify impediments in any of their work areas. This provides an opportunity for the other teams or the value stream level to volunteer to work together (“swarm”) with the group experiencing the impediment, and thus remove it. This helps all levels in the program to continue coordinating and progressing.

Who does this Practice

Here are roles most involved in this practice:

Team lead
Value stream management leaders

What to do

Inputs

Inputs to this practice include:

Inputs from members. Each member should arrive at the SoS coordination meeting knowing the status of work in the area they represent. The main things they should know are:
- What work has been completed since last scrum of scrums meeting
- What work is coming up next (in the team or value stream backlog)
- Current impediments and (possibly) root cases
- Key metrics that are seriously and consistently underperforming and (possibly) root cases
Dependency diagrams. These show the dependencies between the work to be done by the different teams (typically these come from planning done at major value stream boundaries, such as from a program increment planning event).

Approach

1. Form a scrum of scrums team.

Pick one representative from each working-surface team. This is usually the team lead.
Pick a leader for the SoS. This is usually from value stream management, someone who focuses on keeping to the value-delivery roadmap and to impediments to achieving it.
Hold scrum of scrums coordination meetings.
Can be daily, just as with the daily coordination meetings held by working-surface scrum teams, or less frequently.
Follow the same guidelines as a team daily coordination meeting.
Keep the meetings focused, simply stating completed work, upcoming work, impediments/subpar metrics, and potential members in a swarm on a given impediment.
Use dependency diagrams to help identify who is best suited or has the greatest need for help; for example, if they will soon be using the impeded work.

2. Identify swarming opportunities to solve cross-team and system-level impediments.
3. Outside the coordination meeting, people identified during the meeting swarm to remove impediments.

Tools and Techniques

Tools and techniques that help with this practice include:

Whiteboards (free-form discussion)
Information radiators for each team and for the value stream/system level
Dependency diagrams to identify where the work of each group and level has dependencies on the work in other groups and levels

Discussion

Scrum of scrums is a straightforward solution for up to 5-6 teams. They tend to fall apart given the increased need for architecture/technical coordination and requirements/work coordination as a program grows in size.

Scrums of scrums are often criticized for being ineffective in practice. The group and its team lead will need to be very disciplined in keeping SoS coordination meetings focused on the questions of latest work, next work, and impediments. Swarming should likewise be very focused on the identified problem(s).

Outputs

Here are some expected outputs from this practice:

Temporary swarming activities
Impediment resolutions

When to do this practice

Here is when to do this practice:

On an ongoing basis
- The frequency of the SoS coordination meeting should suit the nature of the value stream. It could be daily (as is typical of team-level daily coordination meeting), or less frequently (if the work can be synchronized less frequently).
- Meetings should be held at less than the working surface teams iteration length: So, if the value stream’s teams are running two week iterations, weekly SoS Stand-ups are the minimum recommended (so there is time for teams to react to the findings of the SoS, during a given iteration).
As part of value stream level planning
- In this context, the SoS is both temporary (just for the event), and focused on the event’s purpose rather than on system development as a whole (such as in a program increment planning event, a major focus will be to resolve impediments between teams due to the dependencies the planning has revealed)

Where to do this practice

A fixed location and time should be chosen for the SoS meetings to maximize the possibility of having all members attend.

Outcomes

The benefits of this practice include:

Rapid detection problems that will impact other parts of the value stream
Increased cooperation among those in the parts of the value stream
Cross-system visibility of impediments at the working surface and system levels
Better understanding
Among teams, of value stream concerns
At the value stream level, of team concerns
Among the teams, of other teams’ concerns