Recently, I did a small research on Scrum of Scrums and how it could be applied in the organization I am working in. I decided to share the major findings with the community in this post. I hope you will find it useful.
Scrum of Scrums (SoS) is an approach of scaling Scrum to large project teams. Unlike Scrum itself, it is not a complete methodology, just a technique of conducting coordination meetings between Scrum teams working on a large project. As such, it leaves open many questions related to scaling Scrum. This has led many authors to be skeptical about the concept, to build their own concepts on top, or to propose alternatives.
According to Mountain Goat Software, the approach is defined as follows:
... each Scrum team proceeds as normal but each team also contributes one person who attends Scrum of Scrum meetings to coordinate the work of multiple Scrum teams. These meetings are analogous to the Daily Scrum Meeting, but do not necessarily happen every day.
The article from Mike Cohn, Advice on Conducting the Scrum of Scrums Meeting, can be considered one of the primary sources on the topic available online. He advocates that SoS attendees should change, rather than always sending the Scrum Master:
The decision of who to send should belong to the team. Usually the person chosen should be a technical contributor on the team—a programmer, tester, database administrator, designer, and so on—rather than a product owner or ScrumMaster. Being chosen to attend the scrum of scrums meeting is not a life sentence. The attendees should change over the course of a typical project.
Another idea proposed in this article is that the Scrum of Scrums meetings can be scaled up in a recursive manner, as illustrated in the picture below, coming to a "Scrum of Scrum of Scrums", etc. Note this idea is debated in the community as there is some skepticism regarding how many levels this could successfully scale.
Regarding frequency of SoS meetings, most authors agree that potentially longer meetings less frequently work better than daily meetings timeboxed to no more than 15 minutes. A longer timebox makes it easier to address any problems identified during the meeting immediately. As Mike Cohn argues:
If a problem is identified and the right people to address that problem are together, they should address it then and there. A problem that has risen to the attention of the scrum of scrums meeting participants is often a significant problem that could be affecting the work of up to 100 people. It deserves to be addressed and, if possible, resolved in that meeting.
For SoS meetings, the three standard Daily Scrum questions need to be rephrased a bit, and a fourth question added:
- What has your team done since we last met?
- What will your team do before we meet again?
- Is anything slowing your team down or getting in their way?
- Are you about to put something in another team’s way?
The meeting has two parts. In the first part, all participants answer the four key questions outlined above. In the second part, any issues that were raised during the first part, or previously identified and maintained on a scrum of scrums backlog, are addressed.
Several posts by community authors describe what can be considered advanced techniques for Scrum of Scrums, as they extend the original idea from a coordination meeting to a more holistic approach for managing a large project. In his article Scrum thoughts: scrum-of-scrums and daily scrums, Jon Moore sees SoS as a means to regularly get an overall sprint status for the product, reassess confidence levels for user stories (green, yellow, or red), and rebalancing by trying to swap resources around such that the following principle holds:
No user story should have a lower confidence level than a user story with lower priority.
In his post Scrum of Scrums: Making it Visual, Xavier Quesada demonstrates a similar approach for SoS relying extensively on a physical storyboard and tokens for visualizing the progress and status of user stories:
In the Scrum of Scrums, you only visualize stories. You create the “Scrum of Scrums storyboard” where every story that is currently open is visualized, with the team that has it and the current status indicated.
There are only two columns: “Story” and “Status”. Each story has a little magnet indicating which team is working on it.
The benefits from using an approach such as Scrum of Scrums are pretty obvious - it is simple and straightforward, and it fits naturally into Scrum. It also promotes Lean and Agile values and principles such as self-organizing, empowered teams, lightweight & visual requirements, and so on. Considering that Scrum teams working on a large project have to coordinate their efforts using one approach or another, SoS provides a very good starting point for this.
As Ilja Preuß describes it in his post:
... 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.
Issues and Alternatives
The drawbacks outlined by some authors mainly come from the fact that Scrum of Scrums is a technique, not a complete methodology for scaling Scrum in large software development groups. Some of these issues are outlined in the Scrum of Scrums: Issues and Value, by Mark Levison. In a post mentioned in this article, Allan Shalloway points out that problems with scaling Scrum can creep in on several different levels: technical level, cross-team level, and team structural level. SoS by itself does not provide an answer to any of these, and is therefore not enough for successfully scaling Scrum.
Several authors, including Allan Shalloway in the above post (see also his not yet published book Lean-Agile Software Development: Achieving Enterprise Agility), and especially Craig Larman and Bas Vodde in Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum agree that the key to successfully scaling Scrum lies in reorganizing from the traditional functional or component team models into feature teams, able to deliver complete end-to-end product features by themselves. In the latter book, the authors introduce a framework of "organizational tools" for scaling Lean & Agile, of which Scrum of Scrums is part, but does not play any essential role compared to some of the other elements.
Another stream of criticism for Scrum of Scrums focuses on the "limited bandwidth" issues that one would encounter when trying to apply this approach in very large organizations. In their post Big Org, Small Bandwidth, Matt Magurany and Will Read advocate a "mesh network"-based approach for inter-team coordination rather than the "tree network", promoted by Scrum of Scrums. Commenters on this and related posts have noted that the two are not necessarily contradicting and can be used in combination.
The concept of Scrum of Scrums is well established and have been successfully applied for coordinating multiple Scrum teams working on a large project. Agile projects and organizations, especially those having a relatively small number of Scrum teams (2 - 7), should consider implementing this technique as a starting point. However, one should remember that Scrum of Scrums is only a technique of conducting coordination meetings, not a complete methodology for scaling Scrum by itself, and therefore other approaches such as feature teams should also be taken into account in large projects and organizations stepping into Lean and Agile.
Have you implemented or considered implementing Scrum of Scrums in your own project or organization? Please share your thoughts on this topic.
