Tuesday, December 25, 2012

Practical Scrum - Scrum of Scrums

Scrum works best when the team size is small and co-located. In my previous blog, I talk about a co-located scrum team structure and how common IT roles maps to the Scrum team.
There will be times when the product will be too large for small scrum teams to work on. This is where you break your product functionally to smaller streams and have different coordinating teams working on it. Scrum of Scrum (SOS) is multiple scrum teams working and coordinating on the same product or towards the same goal. The word ‘same’ is key here as if the products are different you need different scrum teams altogether and no coordination is required.

You can also use SOS if the product team is at several locations and each location has fully functional Scrum teams. This makes product execution across multiple locations manageable.

Guidelines for Product work distribution among Scrum teams 

Here are the guidelines that can help you structure the work:
  • No two teams should work on same user story.
  • Strive to allot user stories by features. So, if in Iteration 1, a team was working on user stories of Feature 1, try and assign this feature to the same team in next iterations also. With multiple scrum teams you need to do some more planning. Here, you are just assigning features, the individual tasks are still up to the Scrum team to work on.
  • For ease of planning, Estimation scale has to be same for each user story. To achieve uniformity in scale, it’s recommended to have few initial user stories estimated with all teams or representatives of all teams.
  • Release planning will be done as is done in normal scrum where prioritized user stories will be divided to Iterations considering combined velocity of all Scrum teams.
  • Iteration planning will involve dividing user stories among Scrum teams in proportion of their velocity. Note that velocity will be different for each team.
  • Iteration length for each team should be same. This eases planning and coordination.
  • For dependencies, coordination is of utmost importance and Scrum of Scrum meetings is a good mechanism to share progress.

SOS Meetings for Teams Coordination 
SOS teams coordinates via a meeting in which one representative from each team participates. The meeting time is 15 to 30 min. and frequency of this meeting can be daily (if more coordination is required due to dependency) or sporadic with minimum once in a week.

In my view, Scrum of Scrums usually should be conducted during following occasions:
  • Just after daily stand-up meetings to update other SOS participants about the progress made between last meeting and now and what is planned to achieve before next meeting. Any dependencies among teams is also discussed. Any impediments are brought forward, but resolution is discussed outside this meeting.
  • Just after Release Planning meeting: With an aim to identify any dependencies on user stories that will be accomplished by coordinating scrum teams.
  • Just after the Sprint Planning meeting: To make all teams aware of their Sprint goals and understand deliverables and dependencies.

The Team Structure 
In a previous blog I mentioned the team structure of a co-located scrum team. On top of the description of roles mentioned in that blog, here are some additional points to consider:

Product Owner Role: The scrum of scrums should share the same Product Owner(s) or the Product Owner of each team should coordinate to represent one face to all the teams. They maintain the same Product backlog so that you always deliver the top most priority feature in a coordinated way.
Scrum master Role: Each team has their own Scrum master. The scrum master participates in all regular meetings and also participate in the SOS coordination meeting. However, it’s not required that only Scrum master participates in SOS meetings, it can be anyone from the team.
Developer and Tester Roles: These roles are not shared among the teams. Each team has their own dedicated Developers and Testers.
Specialized Roles (UI Designer / DB Specialist / Technical Writer / Business Analyst etc.): You might consider sharing them. Dedicated resources are always the best as resource sharing causes thrashing and context switching is a costly affair.

A Lean Alternative - Product Coordination Team (PCT)

Lean methodology suggests an alternate to SOS team. The PCT team has representatives from each team just as in SOS. Lean says that SOS tends to be biased towards their own teams and do not think of larger picture of Product Coordination. PCT picks the work from Product Backlog and in an unbiased way places it in each teams Sprint backlog and coordinate the delivery. It’s essentially SOS team without affinity to their own teams. PCT by its name brings a different perspective. A SOS team should work on this perspective for the greater good of product development.