Scrum of Scrums are about the conversation!

The purpose and composition of a Scrum of Scrums (SoS) have been discussed in detail in earlier blog entries.As a means to scale, SoS has been leveraged as a structure for teams to coordinate and plan activities between each other.  The SoS is a platform for conversations such as negotiating access to a capacity from a team with specific skills or reminding everyone that you are refreshing the test environment in a few hours. The pattern of getting people together to coordinate with a structured approach in a time box is a powerful tool. That is why the base pattern has been tweaked and leveraged for many other purposes, some of which stray away from a few basics prerequisites:

  1. You have to have more than one team. It is difficult to coordinate if no one else is involved.   Just because you are doing Agile or Scrum does not mean that you need to leverage a Scrum of Scrums. Don’t think this has not happened.
  2. Participant teams need to interact with application or capability level.  Holding a Scrum of Scrums that have no functional or capability connection will devolve into a status meeting or worse.
  3. Participants need to have a valid reason to plan and coordinate together.  Even if participants share an application, project, technology or capability, they still need a reason to plan, coordinate and negotiate together or the SoS will be a status meeting.
  4. Participants must trust each other.  Without trust no real communication is possible.

A Scrum of Scrums is not a status meeting — the world does not need more status meetings.

One way to prevent a SOS from becoming a status meeting is to use a framework.  A framework is not the same as a straightjacket. Every group of teams needs to use continuous process improvement (inspect and adapt) to evolve their own approach to SoS in order to maximize the usefulness.  A simple format, similar to the daily scrum or standup meeting, the SoS often features a simple set of questions acts as format/outline.  

  1. What has happened since the last meeting that effects other groups?
  2. What are you going to do that effects other groups in the near future?
  3. What help do you need from other teams NOW or in the next sprint?
  4. What will you need from other teams in the next few iterations?
  5. Are there risks that affect more than a single team emerging?

Coordination and synchronization are about sharing information outward rather than inward.  The shift from an inward to an outward point of view is the crux of a SoS. The structure provides a way to train teams to shift the focus.  Other agendas or formats can be used to accomplish other sorts of results.  Steven Adams puts forward the following structure for a very operational SoS (we might argue with the name but it leveraging the basics concepts of Scrum of Scrums)::

  1. Coordinate related activities between teams for a specific release.  Identify and understand the dependencies and common timelines.
  2. Tackle technical issues that affect more than one team – architecture discussions or joint solutioning for a business requirement (do this in a follow-on meeting – Tom)
  3. Collective planning for the next release; keeping teams on the same page.
  4. Production priority one issues that might arise, where root-cause has not been established at the sub-system level (e.g., mobile, content management, search, web)

Note that every item addresses the impact on others rather than just sharing “whats happening.”

Fundamentally, a SoS is not about any individual team or organizational structure, like a PMO, but rather about teams making sure they have what they need to get the job done and what they can do to help their colleagues deliver.