A Scrum of Scrums (SoS) is a powerful tool to sync up multiple Scrum teams working toward their individual sprint goals, along with the common goal at the release or product level. The SoS meeting provides a platform for sharing information, communicating progress, identifying common blockers, and triggering resolution action.
In addition to identifying and resolving interteam dependencies and common blockers, the SoS meeting also helps with the following:
- Provides the top-level view of the product/service
- Reinforces the shared vision and common goals
- Eliminates redundancy of work
- Improves communication and collaboration
- Identifies integration points earlier and helps plan
- Provides a common update to leadership and improves visibility of the program/release
- Identifies common Kaizen opportunities
This article presents a list of five must-have agenda items for a Scrum of Scrums meeting.
1. Interteam dependencies
Status of dependent code or module:
As the development and/or testing effort of a team may depend on the availability of complete work from other teams, the availability of developed and tested code from each Scrum team is a key item to be discussed in an SoS meeting. For example, as part of an employee leave and payroll application, the key parts of an employee details module have to be made available first for the other development teams -- say, the employee payroll module and the employee leave module.
Branching and merging updates:
Though there could be a branching and merging strategy at the program level, often teams find a need to take out a branch for their specific needs. Such branching details and the possible merging issues should be brought to light. Until the teams mature to the practices (e.g., trunk-based development) that minimize or eliminate the need for multiple branches, constant updates on the status of branches should be shared among the teams, and the SoS serves as the best platform for sharing such information.
Integration and regression:
Teams mature in continuous build and integration practices would have established flows and tools for seamless integration of code and regression testing the integrated code. However, in a multi-team scenario, the specific inputs regarding timing, sequencing, etc., have to be discussed so that the established process is effective and does not throw out surprises later in the life cycle of the solution. In the case of integration or regression failures, the SoS platform should be used for root cause analysis and arriving at a lasting resolution.
Product owner inputs on priority or overlapping functionality:
Typically, the PO and the teams discuss and arrive at a decision on the MVP (minimum viable product) before commencing the sprints. However, during the course of the sprints there could be clarifications or new insights into dependent or overlapping functionalities. In turn, these could call for reprioritization of the user stories. During the SoS meetings, the team could discuss these and consult the PO on how they could be addressed either in the current sprint, if feasible, or in subsequent ones.
2. Common dependencies
In a large program there would be dependencies that are common to all the teams. These could include items such as external services and interfaces, specific environment configurations, and vendor code or patches to a vendor-supplied product, which could form the basis for development and testing work of all the teams. Typically, these dependencies are not within the full control of the teams. However, these should be discussed in the Scrum of Scrum meeting and the teams should identify the need for escalation, request approval for alternatives (e.g., to use virtualized services), and possibly refine their development, testing, and integration approach and accordingly update the stakeholders.
3. Risk, blockers, mitigation, and contingency action planning
These are common items the individual teams discuss on a daily basis during their stand-ups. However, it is critical to discuss these in the SoS as well, and to identify the cumulative impact of the risks and blockers at the program or release level. Clearly a mitigation or a resolution action plan at the program or release level could be very different and could have a more far-reaching effect than one at the team level.
"Maximize work not done" is one of the Agile principles. To optimize team effort and eliminate waste, the team could reuse services, code, components, tools, infrastructure configuration, deployment scripts, and so on. SoS is perhaps the best platform to provide pointers for reuse and trigger subsequent offline discussions among the teams.
5. Confidence level on the upcoming release
The Scrum of Scrums can also help reassess the confidence level of Scrum teams on the release slated for a given date. Typically the teams should consider factors such as the following while discussing the release date in an SoS meeting:
- Tech challenges
- Business risks and potential impediments
- Team capacity and potential changes
- Team capability
- Enterprise wide platform and technology migration
- Potential changes in domain or industry-specific regulatory requirements
Thus the Scrum teams could exploit the Scrum of Scrums as a platform for optimizing their effort, improving the quality of their work, and delivering the solution to the expectation of the stakeholders.