The Evolution — And Importance — Of The Scrum of Scrums

July 27, 2010 Category Scrum 4 Comments

Since its introduction, the Scrum of Scrums has been a mechanism for dealing with the complexity of the dependencies in multi-team Scrum projects. Every day, after the individual teams have their Daily Scrums, representatives from each team assemble for a “Scrum of Scrums.” At this meeting, each team’s representative reports what his or her team did yesterday that might affect other teams and what the team might do tomorrow that could have the same effect, focusing on areas most likely to present problems. It’s just  like the Daily Scrum, but at the next level up.

The Scrum of Scrums is meant to provide transparency for  teams that aren’t collocated and don’t have ongoing communications. Many failures occur, of course, because the individual teams’ representatives can’t always remember and anticipate perfectly or communicate clearly what problems their team might cause for other teams.

As engineering, build, and testing platforms have improved over the years better, I’ve been augmenting my recommendations around the Scrum of Scrums. Today, it should be a requirement that all Scrum teams present a single, integrated piece of fully-testing functionality at the end of the Sprint, at the Sprint Review meeting. This ensures full transparency into true product progress and doesn’t require people to try to logically assess whether n individual increments add up to one integrated increment. When teams try to do this, they discover that waiting until the last day of the Sprint to integrate is a plain old bad idea. They start implementing integration builds and tests at least weekly, until they back themselves up into at least daily and often continuous build and test. As this occurs, the Scrum of Scrums gains teeth. No one has to struggle to remember or to anticipate. Instead, they have concrete and immediate things to discuss, such as, “I thought I told we were going to be in that part of the code, what were you doing there has caused a build failure.”

This is sophisticated stuff, and it requires additional infrastructure and skills. However, it stops undone work from accumulating. Undone work, of course, usually occurs where dependencies haven’t been thought through. If these build up until the end of a release, the final few Sprints become an unpredictable “stabilization phase.”

If you really want to be “lean,” add the requirement that whenever the integration build or an integration test fails, no developer can do any work until it is fixed. Why? Because any work the developers do may be on a shaky foundation, and it’s impossible to predict how long it will take to rebuild it later on.