When IT organizations develop software across multiple dev teams following Scrum, they need a way to coordinate development across the enterprise.
Scrum of Scrums is one approach used to manage Agile development. Let’s examine what it entails and how it compares to other ways to manage Scrum at an enterprise-level.
The Scrum of Scrums framework
What is Scrum of Scrums?
Scrum of Scrums is a method that coordinates the efforts of multiple app dev teams to enable integration and collaboration among all parties. The approach is simple and provides a basic level of coordination across a small number of — ideally five or less — development teams.
Scrum of Scrums is limited to coordinating the development team’s activities and is not intended to be an overall approach to project management delivery. If each Scrum team can self-organize well, then Scrum of Scrums will be successful.
What is on a Scrum of Scrums meeting agenda?
A Scrum of Scrums meeting assesses work progress across the teams. At this meeting, the following four questions should be answered:
- What has your team done since the last meeting?
- What will be done before next meeting?
- Is anything slowing down a team?
- Are you about to put something in another team’s way?
Who should participate in a Scrum of Scrums meeting?
Every Scrum team in the enterprise should have a representative in each meeting. The representative who attends the meeting may or may not be the Scrum Master. Alternatively, each team may rotate who attends among different team members; it depends on the individual Scrum team.
Ideally, the product owner facilitates the Scrum of Scrums session. However, the project manager who supports feature delivery can facilitate the meeting in organizations with a project management office — or with distributed project manager resources.
How often should a Scrum of Scrums meeting be held?
Scrum of Scrums meetings may happen weekly or more frequently depending on the need. The cadence may also increase as software deliveries approach and/or if there are cross-team impediments to resolve.
Scrum of Scrums requirements
The product owner and representatives from each Scrum team need to provide dedicated support to Scrum of Scrums activities. In practice, the methodology’s execution can be via emails or instant messages instead of scheduled meetings. Many teams have more successful collaboration this way and find it more time effective to collaborate using a messaging platform.
The product owner may wish to consider creating group chats/channels centered around specific features. If so, the individual Scrum team engineering manager and development product manager should be invited to the channel.
Developers can also be invited; this is especially useful when a Scrum team has rotating representation in the Scrum of Scrums. Such an approach has the additional advantage of keeping the entire Scrum team aware of the cross-development effort and impediments that may arise — impediments that could, for example, directly affect individual sprints or sprint planning.
Where (and how) Scrum of Scrums can fail
For Scrum of Scrums to be effective, it needs skilled facilitators. Such leaders are tough to find and are largely the reason why Scrum of Scrums is not commonplace.
In many IT organizations, the product owner responsible for the feature’s delivery is also responsible for that Scrum of Scrums facilitation. This responsibility is even more likely to fall to that product owner if there isn’t a program management support team.
That can be too much for one person to handle; after all, a product owner already has many features they must deliver and many stakeholders with which to coordinate. Therefore, that owner may frequently hold sessions that function closer to status update meetings in lieu of a Scrum of Scrums. This approach loses some of the key benefits of Scrum, specifically the transparency and adaption found through its empirical process.
Alternative ways of scaling Scrum
There are other ways to scale Scrum across an IT enterprise. Three examples are:
- Large Scale Scrum (LeSS)
- Nexus
- Scrum at Scale
Large Scale Scrum. This framework enables the scaling up with close collaboration during the sprint to maintain the principles of Scrum. This approach is based on the existence of a single product backlog, but with each team keeping their own sprint backlogs. LeSS centers on a whole product focus and is a more tightly integrated approach than Scrum of Scrums.
In this framework, there’s close coordination among the teams at the beginning and end of each sprint. However, the teams operate much more independently while the sprint is in progress and there aren’t any Scrum of Scrums type meetings.
Nexus. This is a framework like Scrum of Scrums because there is development coordination during the sprint. However, Nexus is a more formal process with well-defined goals. One of the keys to Nexus is the formation of a Nexus integration team along with the creation of a new artifact: the Nexus Sprint Backlog, which is a combination of all individual team sprint backlogs.
The role of the Nexus Integration Team is to coordinate, coach and supervise the application of Nexus and the operation of Scrum to ensure best outcomes. The Nexus integration team includes a product owner and a Scrum Master. And — like LeSS — it has a Nexus sprint planning and retrospective. One of the originators of Scrum developed this framework.
Scrum at Scale. Like Nexus, this framework was created by a Scrum originator. Scrum at Scale layers two processes on top of Scrum: the Scrum master cycle and the product owner cycle. This framework includes a Scrum of Scrums Master who facilitates the overall process and creates new events.
All these options — as well as Scrum of Scrums — are valid methods to adopt when working to scale Scrum development to a whole enterprise.