You must be signed in to see that page

Agile Basics

The basics of successful Agile adoption for organizations of all sizes

This is a public Discussion Area  public

Agile Pattern

  • Scrum of Scrums
    Agile Pattern posted 12/01/06 by Alex, last edited 11/25/08 by Mike Alber
    1820 Views, 4 Comments
    Name:
    Scrum of Scrums
    Description:
    On larger projects or programs, a Scrum of Scrums helps with the big picture
    Body:

    When multiple teams are working together on a project, there are many cross-team issues and dependencies that need to be resolved. Significant organizational change is generally needed to support agile development; often this change is more than one team can create on their own.

    A Scrum of Scrums is a scrum team made up of representatives from each of several other teams. Usually the representatives are the ScrumMasters for each team, although sometimes technical leaders and product owners also participate. An Uber ScrumMaster acts as the facilitator for the Scrum of Scrums.

    Just like a regular scrum team, the Scrum of Scrums works iteratively to deliver value in the form of removed organizational obstacles. Usually this group's meetings lag just behind the regular Scrum meetings. For example, if the Scrum teams have their daily meeting at 9AM, the Scrum of Scrums might meet at 9:15AM.

    Some tips to make this group successful:
    1. Remove any unintentional or intentional hierarchy or power associated with this meeting. (This is only a role!)
    2. Remind people of the intent and purpose: to remove escalated
    obstacles or resolve dependencies between teams.
    3. Have the SOS team create a backlog to work through iteratively
    4. Engage the team in a mission/value statement exercise for clarity when stuck
    5. For Daily Scrum of Scrums Meetings, stick to the point and stay after to solve problems, just like in the other daily meetings.
    6. Bring an expert with you or send him in your place if he is better equipped to solve the problem; it's all about waste and obstacle eradication
    7. Make SOS progress visible to the organization via demos
    8. Hold retrospectives
    9. Don't give SOS power to inflict decisions on other teams.

    Consider this pattern when:
    • You have multiple interdependent agile teams
    • You have a large backlog of organizational impediments
    • You are transitioning to Agile development

Comments

    • posted 01/12/07 by Cindy

    Great post Alex. I had questions regarding step 3, "Have the SOS team create a backlog to work through iteratively". I wondered if creating another backlog was helpful. Seems like we are getting quite a few backlogs of product backlog, iteration backlog, release backlog, and now the SOS backlog. Could you please elaborate on what types of Stories I might find in the SOS backlog? Thank you.

    • posted 02/22/07 by Alex

    The backlog for a Scrum of Scrums usually includes different organizational changes that need to be made, or cross-team preparations for a future release. Obstacles that come up during daily standup meetings that can't be resolved right away get added to this backlog. Recommended changes from retrospectives are good items for this, too, like "Get faster machines for developers" or "Figure out how to educate the Sales team on setting expectations with customers"

  • What would you consider to be the upper limit in terms of the size of a Scrum team? I've seen recommendations that say at a team size of 15-20, you might want to consider a Scrum of Scrums, but what is the upper limit in practice? Anyone care to comment?

    • posted 07/16/08 by Alex

    I've done single scrum teams up to 15 people.  15 was very difficult; perhaps a better ScrumMaster could have handled it, but I really struggled.  One reason is that with that many people, there's too much going on for any team member to hold it all in his head.  People start to focus on getting their own tasks done and lose sight of the whole iteration. 

    Also, it's really hard to have good collaborative discussions with more than 10 people.  6 or 7 people can carry on a design conversation naturally, but getting bigger requires heavy facilitation, and some people are going to start tuning out regardless.

    You'll usually be able to tell if your team is getting too big because you'll just start having problems meeting commitments.

    I would say if you pass 10 people, start suspecting team size as a possible cause for any dysfunctions you see.