According to Mike Cohn, author of Agile Estimating and Planning, The Scrum of Scrums (SoS) meeting "is an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration."
Allan Shalloway is writing a new book "Lean Software Development: Scaling Agile to the Enterprise" and he asked for people's experience "on Scrum-of-Scrums for coordinating teams (which I've had success in) vs scaling Scrum to the enterprise (which I've had several people tell me they couldn't make it work for a variety of reasons)." Alan sees problems creeping in with large groups (350 people in one example) doing Scrum, in this case there are several different products being built with shared common components. He cites three examples of problems that occurred:
- Technical level. Given we're doing iterative development, teams are hopefully following the principles of emergent design. This means that we're writing high quality code, but not adding functionality or design structures until they are needed. Team A may write an encryptor without the use of an interface simply because they have need for only one. Team B may later need an encryptor which is slightly different from Team A's. What would be the best way for the organization to proceed is for team A to modify their code and have an encryptor interface - something that wasn't needed before. First, it's unlikely team B will even know about this. But if they do, Team A has no real incentive to help by modifying their code.
- Cross-Team Level. How teams work together when there are different Product Owners and Scrum Masters for the different teams is not always obvious. Again, a bigger picture helps. This is especially true when there is a component team doing support work for several other teams. To drive from business value requires looking across the product owners. They may cooperate, but then again, they may not.
- Team Structural Level. Many scrum teams working together have serious problems delivering an end to end feature when several teams are involved. I have seen three separate teams, one comprised of UI people, one of mid-tier people and one of database people, get much more effective when they reorganized into three different teams organized around functionality. The people in the organized groups still performed more or less the same functions but were now able to swarm around features, not parts of a feature that was on a layer. This caused some integration problems across the teams but enabled end-to-end functionality to be built more quickly. This is also what Bas Vodde and Craig Larman recommended in: Choose Feature Teams over Component Teams.
Mike Dwyer says that is up to the SoS and Meta Scrums: "to coordinate the decomposition of the stories so that you don’t end up with the same thing being built by many teams. Those things are to be worked out through the daily and frequent conversation that occurs at all levels." In his experience well coached teams focused on the infrastructure, data and architecture do a good job of harvesting shared code. Finally he says that of key importance was getting management and product owners to work together to define the theme of the release, as it helped give teams the direction and support they needed.
Ilja Preuß says the SoS provides value for his teams: "it helps us to get a feel of what happens to the system by the other teams; it helps identify situations where we can help each other; it helps identify situations where the teams need to coordinate; and it simply helps in keeping up the feeling that we are in the same boat and in keeping people connected by making sure that at least one member from each team sees one from every other team once a day."
Christophe Louvion has also used SoS to manage daily integrations across product teams. The meta team, composed of the Senior Engineers from the sub projects, was responsible for:
- setting standards (APIs, SLAs, error logging, code repository structure, automated build process, automated deployment scripts used by all teams, etc)
- daily integration testing (automated)
- cross sub product code / architecture reviews
- early in a large release, the team would trigger set base design tests across multiple teams for unknown solutions
The SoS was actually the first team to start, setting the ground for scaling. The team was extremely senior. Over time, each member of the SoS became a lead of sub product teams, working both at the SoS level, and down into a sub product.
Finally Walter Bodwell shares his recipe for SoS success: "Keep it Short 15 minutes tops, Keep it focused. What is it that others want/need to hear? The first two questions people answer in the SOS can really help in collaboration by making others aware of what you are working on. They can give suggestions, make you aware of something, etc. But discussions should be split off to a separate meeting to keep it short and focused. Bring up blocking issues every SOS until they're resolved. Identifying / giving urgency to blockers is one of the biggest benefits of the SOS." Because the SoS is often held across time zones and with different accents, he finds it often helps to share brief notes in advance.