A Scrum of Scrums (SoS) is what it sounds like: a meeting of Scrum Masters in which issues affecting more than one Development Team are coordinated. This technique has for years been used (and taught) as the primary communication technique for scaling Scrum across multiple Development Teams.
Often, the Scrum of Scrums follows a similar format to the Development Team’s Daily Scrum, with one additional question posed to attendees.
- What has your Development Team done since the last Scrum of Scrums?
- What will your Development Team do before the next Scrum of Scrums?
- Is anything in their way? (Do they need help with anything?)
- Is your Development Team about to put something in another Development Team’s way?
The idea here is to try and predict Impediments before they arise and get in front of them. A laudable goal, but one that flies in the face of empiricism. Empiricism essentially means we make decisions based on evidence, rather than hope or guessing. While a given Scrum Master at the SoS may have good reason to predict an upcoming interruption, why get in the way? Why not let the Development Teams self-organize to address the issue? Scrum is founded on empiricism and self-organization. Scrum Masters trying to predict doesn’t seem to support those values.
An alternative many teams find effective is to require more frequent integration of code across multiple teams. The coordination directly between Development Teams increases substantially when they are all required to deliver integrated software regularly. Issues that will interrupt the integration can now be managed in real-time by the teams doing the work. There is no longer a need to wait for a SoS event or to hand off an “Impediment” to a Scrum Master.
Scrum of Scrums has been a tried and true coordination technique for years. Now that engineering practices like Continuous Integration are mainstream, the engineering practices can drive positive behaviors. In this case, Continuous Integration can promote self-organization of Development Teams.
|
Scrum of Scrums |
Multi-Team Integration |
| Wait until the next meeting to discuss Impediments. | The blinking red light and siren of a failed build force action immediately. |
| Managers are talking about the issue. Scrum Masters. | Those who can actually fix it address the issue. |
| Happens on a timer. | Event-driven. |
| Development Teams act individually. | Development Teams coordinate work themselves. |
scrum of scrum is not for scrum masters. It is for and by team members.
Some good points David. I definitely like the “Multi-Team Integration” model. I don’t really think they are mutually exclusive though are they? I can see value in having both. A key benefit we have found in the SoS is that group can do a good job of keeping an eye on the release burndown that all that teams are working on and discussing and dealing with any issues found at that level. For example, if we have multiple scrum teams working toward a single release date, they can see things like if one team is struggling and could use help from another team so that we, as an organization, can reach our shared goal. It may have nothing to do with a broken build and there may be no dependencies between the work, but if one team has the capacity to help out another team to ensure we all reach our shared goal, we definitely want that to happen.
I was careful to position this as preferring one over the other. You make good points.
That’s not my experience nor the experience of most companies I have worked with.
If SoS is being managed by Dev Team members, that is a bit better because now you have an Integration Committee. Call it what you will, I suppose, but when the folks doing the work are doing the intra-team coordination, life is better.
David, I think this is a great idea even though I do think the teams doing it might need some coaching to achieve to desired output. I agree with the comment below, that the meeting is supposed to be for the team, not scrum masters but rarely have I seen that happen in practice. The goal is to get the doers together and just get the work done without the need for someone to tell them, and I applaud that outcome.