Scrum of Scrums


… a Scrum Team is working on a single product with multiple Development Teams. The Development Teams need to coordinate dependencies and shared work. Dependencies that cannot be resolved within individual teams are a shared challenge of all teams.

✥      ✥      ✥

When more than one Development Team needs to work together to create a Regular Product Increment, inter-team coordination warrants explicit attention.

Multiple Development Teams working on the same product need to coordinate their work and explore inter-team dependencies. [1] But you often cannot know in advance all of the dependencies and how to resolve them. Even with extensive up-front planning, during the Sprint unforeseen dependencies may emerge that need to be handled by the teams.

A Development Team should be able to completely develop a Product Backlog Item (PBI) in isolation. In that case you only need to worry about integrating multiple independent PBIs into one product. In some cases however, it is not possible or desirable for a single team to develop a PBI on its own. And we end up with strict dependencies between Development Teams. An example is when one team develops a PBI that lets a user buy a product X with the website part of the system, while another team develops a PBI that handles the billing of product X via the administrative part of the system.

Frequent collaboration and synchronization enable the Development Teams to produce a Regular Product Increment every Sprint. Each Development Team develops independently, but all Development Teams together should produce an integrated whole.

No single team should be responsible for integrating the work of multiple Development Teams: it is the responsibility of all Development Teams. If a separate team is responsible for integrating the work, it introduces unnecessary hand-offs and feedback delay. On the other hand, if no explicit team is accountable to produce an Increment, ownership and commitment suffers and integration could be left undone. All the Development Teams involved should therefore share any overlapping integration work.

In a Development Team the coordination emerges between the developers as the Sprint progresses; there is no special coordination role. With multiple Development Teams, you also do not want any special role coordinating between the Development Teams because the developers doing the work can do it best themselves.

Therefore:

Introduce a recurring Scrum of Scrums event where a representative from each of the involved Development Teams coordinate to create a plan to best deliver the Regular Product Increment. At the Scrum of Scrums the teams discuss and resolve inter-team dependencies, impediments and shared work.

You can identify Development Team interdependencies when creating a Refined Product Backlog or during multi-team Sprint Planning. Sprint Planning has two focus points that answer the following questions respectively:

Answering the first question helps identify overlapping work and dependencies that need to be coordinated. The Development Teams choose which PBIs they want to implement, therefore they also know with which other Development Team they need to work together the coming Sprint to coordinate the overlapping work. In answering the second question, the involved Development Teams plan the work needed to develop and decide how to deal with the identified dependencies.

The Scrum of Scrums is a prescheduled, regular event and teams can easily organize around it. The teams need to discover what frequency works best in their particular situation. In the Scrum of Scrums events the participants explain:

  • What did my team do since the last time we met that could affect producing a Regular Product Increment?
  • What help does my team need to resolve inter-team dependencies?
  • What impediments does my team see before we meet again that prevents us to integrate our work with the other Development Teams.

Development Team members, who are actually working the overlapping work, attend the Scrum of Scrums. [2] The Scrum of Scrums can discover new overlapping work that is needed to solve inter-team impediments and dependencies. The attendees make the newly discovered work transparent to their Development Teams by bringing it back to their team's Sprint Backlog.

✥      ✥      ✥

Multiple Scrum Teams organize themselves each Sprint to plan the overlapping work and deliver Regular Product Increment. The Scrum of Scrums enables the Scrum Team to extend their Definition of Done more easily with for example integration testing. As a result there is increased feedback on dependencies so that these can be handled in the most effective way.

Although the Scrum of Scrums is an event for coordinating dependencies and discussing impediments, their resolution should not be postponed until the Scrum of Scrums event. Impediments are worked on as soon as they emerge. Development Teams are empowered to organize themselves to get their work done and minimize dependency risk using Dependencies First. The ScrumMaster helps to remove impediments to the Development Team's progress and can invoke the Emergency Procedure as a last resort.

When a Scrum of Scrums involves a lot of people it is probably a sign that something is wrong. It could be that the teams are working with PBIs that are not Ready; that dependencies were left unnoticed because of poor multi-team Sprint Planning; that the wrong people are attending and it turned into a status meeting; or that the teams are lacking in some skillset. The Scrum of Scrums is mainly for dealing with the inevitable emergent insights and problems that arise in complex multi-team development.

The Scrum of Scrums is a centralized meeting. It has the disadvantage of people tending to wait until the next meeting to discuss dependencies. When teams need to coordinate, the teams can just talk to each other without waiting for the next Scrum of Scrums.

The first Scrum of Scrums was implemented at IDX Systems in 1996. Jeff Sutherland was Senior Vice-President of Engineering, with Ken Schwaber on board to help roll out Scrum as a consultant. The first publication mentioning this first Scrum of Scrums was [3] and it is also mentioned in the Scrum Papers [4].


[1] Craig Larman and Bas Vodde, Practices for Scaling Lean & Agile Development, Addison-Wesley, 2010, pp. 200-203.

[2] Mike Cohn, Succeeding With Agile, Addison-Wesley, 2009, pp. 340-343.

[3] Jeff Sutherland, “Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies.” In Cutter IT Journal: The Great Methodology Debate, Part 1. Volume 14, number 12, December 2001, pp. 5-11.

[4] Jeff Sutherland, The Scrum Papers, http://scruminc.com/scrumpapers.pdf, accessed 11 January 2017, no permalink, draft, 29 January, 2011.


Picture from: Greg Neate, www.flickr.com/photos/neate_photos/3522905573/in/album-72157617918428883, (under CC BY 2.0 license).

Comments