The Evolution — And Importance — Of The Scrum of Scrums

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.

4 thoughts on “The Evolution — And Importance — Of The Scrum of Scrums

  1. Hi Ken, with my teams we use pre-commit hooks against our automated build scripts, which includes coding standards tests and continuous integration. This actually prevents the source from making it into builds and release candidates before the end of the Sprint, if the code doesn’t match various points of quality.

    We use Mercurial for distributed source control for multiple Scrum team projects, this allows per Sprint and per Scrum Team a team-based repo and the ability to merge up to the Sprint “gold candidate” release, only once the code has passed existing checks and the combined teams Sprint tests.

    We only demo the “gold” repo during our Sprint Review and the merging of code to gold is the only way a User Story moves from In-Progress to Done. This ensures that our definition of done can be enforced through our build and testing process, which we employ an SQA team to assist Scrum Teams with.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s