Scrum of Scrums

Well… we got Agilepalooza in the bag. It was a great day. We had David Hussman, Guy Beaver, Jeff Sutherland, and Joe Little do talks. I did my Agile PMP talk… and FINALLY feel like I’ve got the slide deck telling the story I want to tell.

The day before the ‘palooza… I got to do a talk on Agile Project Management with VersionOne for a local client. Jeff Sutherland was in the audience… and I’ve got to say… it was a little disconcerting talking about Scrum with Jeff in the crowd. He is a good guy and had nice things to say… but still.

Getting to spend some time with Jeff was pretty cool. One of the questions that came up had to do with handling a Scrum of Scrums. Jeff had an interesting take on the Scrum of Scrums concept that I had not heard before. He described the Scrum of Scrums as an abstraction mechanism. The Scrum of Scrum ‘hides’ the Scrum teams from the rest of the organization.

So often I hear people talking about the Scrum of Scrums as a place where the ScrumMasters get together to coordinate and share information. I don’t think that definition is wrong… but it is incomplete. Jeff’s description was big enough to accomodate some of the coordination teams I talk about here on Leading Agile.

The amount of coordination required is dependent on the number of dependencies between the teams:

No dependencies? Use a basic Scrum of Scrums. A basic Scrum of Scrums is where the ScrumMasters get together daily to go over impediments and coordinate activities between teams. This team is the abstraction layer between the Scrum teams and the rest of the organization.

Requirements dependencies? Use a Product Owner team. In addition to the normal coordination activities… the product owner team is reponsible for managing requirements across the Scrum teams. Any decisions that cannot… or should not… be made at the individual team level get made by the Product Owner team.

Technology dependencies? Use a Product Owner team with Architects. Adding the architect allows the Product Owner team to take into consideration the critical technology decisions that are going to span teams. In real life, this coordination can be as simple as lightweight design notes on the user story.. or as heavy as a simple architectural representations that the team uses as a baseline.

Integration dependencies? Use an Integration team. Integration teams are like feature teams that consume components or features generated by other Scrum teams. If you are in this place… you are almost guaranteed to have requirements and technology dependencies. The integration team has an actual staff of developers and testers that pull everything together.

While I have no idea if Jeff would agree with these four Scrum of Scrum models… I think they are consistent with his vision of the Scrum of Scrums as an abstraction mechanism between the teams and the rest of the organzation. For a little more on the whole Product Owner team idea… take a look at the post I did earlier this year on that very topic.

Photo source: flickr.com/photos/32286042@N00/3292030662/