The idea of a Scrum of Scrums (SoS) is fairly simple. A bunch of people get together on periodic basis to coordinate the work their team is doing with other teams. The SoS helps everyone involved work together in order to deliver the maximum value. The SoS typically use the daily stand-up or scrum as a model. The simplicity of the logistics of the SoS and the overall utility often leads to tinkering with the format to address other organizational needs. Four very typical additions include:
1. SoS Hierarchy. As projects get larger, more than one scrum team is often needed to deliver the functionality and value needed by the business in a timely fashion. Any time more than one team has to work together, you need to coordinate to ensure that the teams don’t get in each other’s way. A simple Scrum of Scrums will typically suffice for coordination of a few teams; however, as soon as the number of teams grows to between 7 -10 a single SoS will begin to lose its effectiveness. When a SoS gets too large it generally needs to be split into two, and once you have two SoSs . . . you will need a third. If a project requires ten teams to deliver, then three SoSs will be needed. Two five-person SOSs would meet and then send a representative to the third to coordinate and pass information. Hypothetically SOSs could scale infinitely. However in scenarios requiring more than two layers of SoS, effectiveness usually suffers due to degraded communications and meeting fatigue.
2. Backlogs. Scrum of Scrums, even those with variable membership, often build up lists of to-do items that need to be tackled by SoS members outside of the meeting. These to-do items often do not belong on the backlog of the everyday team. ANY item that a SoS needs to tackle belongs on a backlog (or a to-do list). Most SoS teams I coach use Scrumban to prioritize and the work items on their backlog. Items on the backlog are often varied. For example, some the items I have seen on SoS backlogs included: tasks for consolidated demos, release planning tasks, activities for coordinating external reviews, training and even team events. Using a backlog allows the SoS to capture and prioritize work that both affects and requires coordination across multiple teams.
3. Retrospectives. I have never met a team that could not benefit from a retrospective at some point. Scrum of Scrums teams are no different. Standard retrospective techniques can typically be used without modification. One exception to standard approaches are for SoS retrospectives for teams with variable membership. For example, in cases where common patterns occur, such as scrum masters one day, technical leads meeting on another day and perhaps test leads a third day. In this case I suggest holding three separate retrospectives. In cases where membership purely depends on daily context, I usually invite everyone that attended the SoS within the timeframe being addressed. One side note, I tend to do SoS retrospective(s) over a lunch at the end of sprint to minimize the potential for time contention with the ability of SoS participants to work with their regular team.
4. Planning. Where there is a backlog and a cadence of events, there needs to be planning. A SoS team should plan its activities. Planning should include the number and cadence of meetings, membership and any outside activities that the SoS might need to address. Planning should be done at the beginning of a sprint and then tuned on a daily basis. I typically add 30 minutes to the first SoS meeting to address logistics and planning (a form of sprint planning) and then have the SoS team(s) work the backlog as part of their meetings. Asking the SoS to plan its own schedule sends a message about the need for teams to self-organize and self-manage.
The four typical additions of hierarchy, planning, backlogs and retrospectives are consistent with the principles of Agile. These additions add a layer of transparency and coordination. The simplicity and effectiveness of the SoS (and the daily stand-up for that matter) often generate suggestion add extras to the meeting. Use the concept of the time box, for example limit all meetings of this type to 15 minutes, and the principles of Agile to ensure that additions don’t reduce the effectiveness of the Scrum of Scrums. Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.