Net Objectives started using Scrum in 1999. Three-four years later, we started using Scrum with larger organizations and adopted Scrum-of-Scrums as a way to coordinate multiple teams working together. While it sounds great in theory, we could never get it to work. And, although it is still promoted by many Scrum consultants, it still has a spotty track record at best. The challenge we believe lies in the fact that the intra-team dynamics that makes Scrum effective, are not the same as the inter-team dynamics required for Scrum-of-Scrums to work. We feel the entire approach is based on the misguided notion that management is not necessary for Agile to work.

The theory behind SoS is based on the fractal nature of organizations. That is, a multi-team product could be considered a team of teams. You can take this structure all the way to the top. However, what is overlooked is that a team comprised of members from different teams works considerably different than the way a normal team of individuals, working on one thing work. In other words, how a team that works together every day on a project (e.g., a Scrum team) is quite different than a collection of folks from different teams (e.g., a Scrum of Scrums). This insight is the key to scaling Scrum – so I’ll discuss this a little before going on to what works.

First of all, let’s be clear there are two different uses of Scrum of Scrums. One is for coordination – that is, keeping different teams informed of what each other is doing. The SoS works reasonably well as a vehicle for information sharing. However, using Scrum of Scrums to scale requires the SoS team to make decisions together. This is considerably more difficult when they have different goals, different motivations and different ways of being evaluated. In low complexity situations this is enough – just keeping independent teams informed. In medium and high complexity situations, however, this is not enough. This is likely the reason that SoS has a dismal track record in scaling Scrum at larger organizations.

There are several better alternatives to Scrum of Scrums for groups of teams up to 100 or so people. These are:

• Product coordination team (see Lean-Agile Software Development: Achieving Enterprise Agility for chapter)
• Shared backlogs (see Coordinating Teams with Shared Backlogs for an article or Scaling Agile With Multiple Teams for a video)
• Dynamic feature teams (see Scaling Agile With Multiple Teams)

These are proven methods which we have used for almost a decade.  They work.