There have been many discussions about how to conduct Program Increment (PI) or Big Room planning. Initially, it was done in the format of being physically present and would last for 2-3 days in one location. With the arrival of the coronavirus, the concept of Remote PI Planning emerged, where individuals would join virtually as a part of the planning session.

Given all its pros and cons, the PI Planning concept works mostly, due to a significant push from the management, business, and relevant stakeholders. PI Planning greatly helps in producing shared goals, plans, and dependencies.

During the execution of the Program Increment, Scaled Agile Framework (SAFe) and other scaling methods talk a lot about Scrum of Scrums as a way to keep track of the goals and plans. Key team stakeholders, like Scrum Masters, are encouraged to talk to each other regularly, in order to discuss inter team dependencies, as well as highlights or impediments to help the program or organisation to deliver value and capture roadblocks at the earliest opportunity.

Scrum of Scrums is conducted once or twice a week. Below you will find a few pertinent aspects to understand this novel activity.

Participants of Scrum of Scrums

Release train Engineers (RTE) and Scrum Masters from each team are the typical participants for the Scrum of Scrums. It’s good to limit participation to ensure quick and focused sessions, but sometimes you may invite product owners on a need basis, although it is not often.

As with every Agile process and method, there are exceptions. The same happens for Scrum of Scrums too. Sometimes program managers, delivery managers, or other program-level participants may join. This tends to happen in larger organizations where SAFe is implemented but still in many, middle management is required to push and report on the compliance, releases, and other corporate processes.

Inviting these participants always helps as decisions can be made that assist in unblocking development. Whether plans to get highly prioritised features are still on track or just to get a feel of the overall progress, input from a larger attendance occasionally definitely helps.

The format for Scrum of Scrums has not been as clearly defined as other Scrum ceremonies. However, it is mentioned that the general theme will be similar to that of the Daily Standup of which the main points would be:

• What did you accomplish yesterday?
• What problems did or will you face?
• What will you try to accomplish today?

The Scrum of Scrums should have similar discussions on a higher level as the event should represent the program level. Therefore, it would make sense to discuss dependencies, impediments, and sprint executions.

What’s wrong when Scrum of Scrums is too much like the daily scrum

As a natural extension of the daily scrum for the Scaled Agile Framework, RTEs tend to conduct Scrum of Scrums sessions on similar grounds. They tend to go through each team scrum master or representative and ask them to share the updates including the impediments and dependencies that are blocking them.

It does help produce valuable output, however, there are some challenges observed.

• Scrum of Scrums is at a much higher level in comparison to the daily scrum. Team members at the team level are usually familiar with what others on their own teams are working on so it’s easier to understand the context in the daily scrum.
• In Scrum of Scrums, each team context can be quite different, especially in remote calls. It can be difficult for other Scrum Masters to grasp the issues and impediments being discussed as part of a team update by Scrum Masters. This is especially true for component teams.
• Since teams are usually geographically dispersed, it is difficult to have a centralized place to write down things. The sessions are short so normally there would be updates given verbally. The only things that may be recorded would be some impediments or action points.
• Using Wiki or Confluence to keep a track of the action points or dependencies introduces yet another place to retrieve the important prior discussions and to source that truth. Making it difficult for the RTE to follow up on highlights or impediments.

A Proper Solution Would be

• Allowing each Scrum Master to record and share the precise points or the “Highlights” prior to the start of the Scrum of Scrums session. These may include the request for help from other teams, sharing their challenges, or talking about particular dependencies, impediments or risks.
• Allowing management or members on the program to focus clearly and transparently on the top Impediments and how they can be unblocked.
• Enabling the RTE at the program level to note the key impediments, program-level risks and the dependencies that can cause serious problems, all in a central location.
• Setting up a virtual call and openly discussing the factors that will impact the Release Train or the Program.
• Attaining follow-ups on previous action points and impediments and ensuring that they are being carried out proactively.

After interviewing tens of RTEs and going through multiple proofs of concepts, the Kendis team has come up with a solution. Keeping in mind the challenges and opportunities, this solution will assist the RTEs and Scrum Masters to engage in an optimal and effortless way of having Scrum of Scrums.

This solution will help ease the burden of all RTEs and Scrum Masters in reducing the amount needed to copy and paste open action points, reminding participants, and collecting important dependencies and risks in different tools. Similarly understanding what is completed, what is pending, and what is blocked and without going through tons of views and clicks.

Here is the snapshot of the upcoming release of Kendis with Scrum of Scrums functionality.