Revitalize Scrum of Scrums

When working during a scaled agile model we need a way to coordinate work among teams and that is one of the most important activities to keep the teams synchronized. Scrum of Scrum is well adopted across groups.

Before we jump into the topic of Scrum of Scrums, let us revisit the Daily Scrum event as defined in the scrum guide which enables transparency, inspection, and adaptation. Daily scrum as defined in Scrum Guide is for developers and the development team to identify the best way to conduct the 15-minute timeboxed meeting. Scrum Masters usually remain outside the standup circle and observe daily stand up and support the team to be self-managed and guard the scrum framework.

Scrum of Scrum is a practice that must also adhere to norms of daily standup and scrum values and principles, but it is not a practice that is recommended by Scrum Guide .

Scrum of Scrum is standard practice and is well adopted by teams when scaled agile is in practice. These meetings get multiple teams’ stakeholders to talk together and teams resolve cross dependencies, share progress, resolve impediments, and much more.

In my experience as a scrum master and coach I’ve gone through various formats of a scrum of scrums, in this article I’ll share my experience with two forms of Scrum of Scrums events with their pros and cons, so we could understand which format is most optimized and support Self-Organization and scrum values and principles.

# Flavor 1: With participants as Delivery Managers, Managers, and Scrum masters

Usually in this meeting Scrum Masters discuss the team's progress and usually document the status reports ahead of the meeting. In this meeting status report is discussed, risk registers are updated, and a risk mitigation plan is shared with the development team.

This flavor of the meeting usually takes 30 mins or longer because once Scrum Masters update the status to the group, Delivery Managers (Or sr. Stakeholders) alter the reports which get published to clients or further up the ladder.

This group often discusses the delay, recovery path, and any other resource, bureaucratic, or governance issues.

I see value in this meeting but is not relevant in case Agile Software Delivery Methodology is adopted. This can’t be called Scrum of Scrum as this breaks the guidelines of scrum guide and agile values and principles.

This format has the following de-merits when Agile Software Delivery Methodology is adopted

1.?????Include waste in the process by having teams document status, and paraphrase these in a language understood by SMs or Management.

2.?????In-efficient use of existing metrics like Burndown charts, burn-up charts to reflect the actual state.

3.?????Generates actions and strategy which teams need to follow, and this information is then translated to the team via scrum masters and creates waste in the process.

4.?????This meeting does not support in problem-solving.

5.?????A waterfall or legacy way of execution is not aligned with agile values and principles.

6.?????In a few sprints, Scrum masters are mutated as Project managers.

# Flavor 2: With participants as Development Team

Instead of re-writing or paraphrasing the right way of setting up scrum of scrums, I recommend reading the article by Mike Cohn on scrum-of-scrum .

This format has the following merits when Agile Software Delivery Methodology is adopted

1.?????Teams learn to collaborate and are empowered to make decisions.

2.?????When team members are nominated (from the scrum team) to join this meeting they gather more information which could be acted on immediately with the teams

3.?????No handover of information and SM do not become a bottleneck to the process.

4.?????Team members are updated on the progress made by another team directly.

Not all scaled agile frameworks will recommend scum of scrum events and they may have other prescribed approaches. If we involve development team members (technical staff) to collaborate together outcomes will be relevant and decision-making will be quicker.