A “Scrum of Scrums” (“SoS”) is a scrum team which addresses a value stream instead of a single team. Its members come from the multiple working-surface teams in that value stream (e.g., line of business or program), as well as members representing the value stream as a whole.
A Scrum of Scrums includes both a structure (e.g., who may join, what they contribute within the SoS team), and protocols (e.g., rules for conducting SoS meetings).
An Scrum of Scrums is usually facilitated by someone whose focus is on the overall value stream and who is concerned with the issues of the system as a whole. Other members from the value stream level may also join.
Scrum of Scrums, as traditionally practiced in Agile, is highly useful, but still incomplete. It is light on handling system issues like risk and change. Thus, SoS should be supplemented with additional approaches to address these kinds of concerns (see “Resources” at the end of this discussion). SoS is most effective in the context of an overall, coordinated systems approach such as Net Objectives Lean-Agile or SAFe.
Why to do this practice
A value stream (e.g., 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, to identify impediments to progress on the workflow 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 so the program may continue progressing with all levels in synchrony.
Who does this practice
Here are roles most commonly involved in this practice:
What to do
Inputs
Inputs to this practice include:
- Each member should arrive at the Stand-up meeting knowing the status of work in the area they represent (overall system or individual team). The main things they should know are:
- What work (e.g., “stories”) has been completed since last Scrum of Scrum meeting
- What work is coming up next (in the team or value stream backlog)
- Impediments their area is currently experiencing, or key metrics that are seriously and consistently underperforming
- If possible, root causes for the impediments or subpar metrics (requires performing Root Cause Analysis or RCA beforehand)
- Dependency Diagrams, showing 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 a Macro-Iteration Planning Event)
Approach
- Form a Scrum of Scrums team
- Pick one representative from each working-surface team. This is usually the team’s Team Agility Coach.
- Pick a leader for the SoS. This is usually from value stream management, such as
- Release Train Engineer (RTE, if they use a SAFe-like Agile framework)
- Technology Delivery Manager; the one who focuses on keeping to the value-delivery roadmap and to impediments to achieving it
- Program or Project Manager; if they have a more traditional or waterfall organization
- (Optional) Add additional members from the value stream level. For example, if the SoS leader is an RTE, a TDM may also attend due to their complementary interests in how work is flowing throughout the system
- Hold Scrum of Scrums Stand-up Meetings
- Can be daily, just as with the Stand-up Meetings held by working-surface Scrum teams
- Follows the same guidelines as a team Daily Stand-up Meeting
- Keep the meetings to simply stating completed work, upcoming work, impediments/subpar metrics, and potential members in a swarm on a given impediment
- Using Dependency Diagrams to help identify who is best suited or has the greatest need (e.g., if they will be using the impeded work) to help
- Swarm to solve cross-team and system-level impediments
- Outside the Stand-up Meetings, people identified during the Stand-up swarm to remove impediments
Tools and techniques
Tools and techniques that help with this practice include:
- Whiteboards (free-form discussion)
- Information Radiators (e.g., of workflow: Agile Boards, Kanban Boards); for each team and for the value stream/system level
- Dependency diagrams (identify where the work of each group and level has dependencies on the work in other groups and levels)
Discussion
Scrums of Scrums are often criticized for being ineffective in practice. The group and its Team Agility Coach will need to be very disciplined in keeping SoS Stand-up Meetings to just 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:
- 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 (e.g., in a Program Increment Planning Event, a major focus will be to resolve impediments between teams due to the dependencies the planning has revealed)
- On an ongoing basis (the mainstream SoS approach, fully described above)
- The frequency of the SoS Stand-up Meetings should suit the nature of the value stream. It could be daily (as is typical of team-level Daily Stand-up Meetings), 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).
Where to do this practice
A 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 within the parts of the value stream of 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
