Serving Multiple Scrum Teams


Can a Scrum Master effectively serve multiple teams and help them become higher performing, self-organized, and more in tune with an agile mindset? Or do you get the case of team and individual stagnation? Here are the obstacles and the lessons learned from my experience transitioning from serving one team to serving three teams.

Challenges in Serving Multiple teams

First, let’s review challenges that increase the difficultly of helping multiple teams:

  • Daily Team Collaboration time

  • The team’s understanding of the “why” of Scrum and what an agile mindset is

  • Team’s belief in and willingness to create a self-organized team

Insufficient collaboration time within the team and coordinating the Scrum Master’s schedule with their scrum events can be a showstopper. Daily Team Collaboration time is the amount of time the entire Scrum Team is present and available to collaborate directly.  Time zones across the team and individual working constraints can reduce this time. Offsetting the sprint start and stop days for one or more of the teams to shift the longer scrum events can create more scheduling options. However, the availability window can still be too short. For example, if you typically require 90 minutes at a retrospective to come away with improvement experiments and your daily collaboration time is 90 minutes, how can you serve other teams that day?  Figure 1 show how longer scrum events in two-week sprint affects sharing a Scrum Master.

Figure 1: Scrum Event scheduling for three teams in a two-week Sprint

Figure 1: Scrum Event scheduling for three teams in a two-week Sprint

The second challenge is the team’s understanding of the “why” of Scrum and what an agile mindset is. The teams’ maturity in understanding Scrum and agile drives the time the Scrum Master will spend. Similarly, the third challenge, their desire to become a high performing team also affects your time. If you are required to be fully engaged with any team, the other teams suffer. More time is required to help the teams embrace continuous improvement, learning fast, collaborating in a safe environment, and self-organization. You can ask questions around day to day events and behaviors trying to help them think about their own problems though until they want to solve them and value inspecting and adapting, their progress can level off or regress.

Distributed and remote teams across multiple time zones face additional challenges though improvements in collaboration technologies have reduced the effects.  The challenges arise due to lack of face to face interactions and reduced daily collaboration time. There are many sources of information describing how distributed teams can work better together that will not be reviewed here. The main point is being apart physically reduces everyone’s ability to observe nonverbal signals and challenges communication. There is a noticeable reduction in the observation opportunities and communication compared to co-located teams.

Scrum Master Tips

To work through these challenges, I learned that there were some practices that improved staying organized and allowed reflection as the observations multiplied.

1.      Get organizational support for at least 3-6 hours of Daily Collaboration Time

2.      Scrum Master Check-In

3.      Team Ownership of Scrum Events

4.      Keeping a “Scrum journal”

5.      Retrospective Actions Board

Organizational Support

Studying scheduling options for three teams using the same or offset sprint cadences revealed that the longer scrum events on the first and last day of a sprint put constraints on Scrum Master scheduling. The key learning, depending if you keep the sprint cadence the same and accept compromises in team and Scrum Master attendance, is the team setup should allow at least 3- 6 hours a day of team collaboration time for at least part of the sprint.

Scrum Master Check-in

The Scrum Master Check-In is a regularly scheduled one on one conversation with team members to understand how they feel about working within the team, what their challenges are, discussing observations I had about them or the team, and asking for feedback. They had the following structure:

  • Daily schedule posted in team area

  • Daily sessions with one member of each team

  • Prepared set of “open” questions based on recent observations

  • Team member stopped by when available

  • Skipped first and last days of sprint to keep team focused

  • Combination of coaching values and principles with gathering viewpoints

  • Notetaking and follow-ups from previous sessions

  • Reviewed patterns of impediments and challenges with agile managers

Some examples questions:

  • What challenges, frustration, or confusion do you have?

  • On a scale of 1-10 what is your stress level? What would make it go down?

  • What could the team do differently to focus on retrospective actions?

  • What do you think about how the team handles preparing for refinement?

  • What have you seen, heard, or experienced that you wish went differently?

  • What single change could we make to Daily Scrum to foster more collaboration?

Team Ownership of Scrum Events

Teaching teams how to run Scrum events and letting them take an active role allows you to do more observing and frees time up that you can use for other purposes. Team ownership of Scrum Events fits into how high performing teams operate. Otherwise, with teams struggling to become high performing, there is a more coaching and transitioning time. Some events like Daily Scrum should be run by the team after some brief coaching. That meeting is for the team and your role is primarily listening for impediments and making observations. Other events like retrospectives require facilitation skills and experience that you can teach. Some team members are uncomfortable with facilitation, and you help them become more comfortable. There are several facilitation options such as sharing facilitation with one or more team members, preparing retrospective agendas for them to use, or having them partner with a team member. You can arrange rooms, offer to facilitate, and then let the team decide what to do. They do get busy so gentle reminders of your offer to help are useful though don’t be surprised with a last second request to run a retrospective! Being able to run several different exercises off the top of your head helps.

Keeping a “Scrum journal”

This is any medium that allows you to transcribe your observations of individual or team behaviors that you notice. This data source is input into your design of Scrum Master Check-in questions, spontaneous coaching sessions, possible workshops, retrospective input, or self-reflection on the value of where you are spending your time. Typically, I jot down brief notes and try to expand on what I noticed and reflect on what questions I could have asked. Review your observations each week to shape your future focus.

Retrospective Actions Board

Getting any team to take action on the results of retrospective is a common challenge to Scrum Masters. I tried reminders, creating a task to track the item in the sprint, finishing the retrospective by completely designing an experiment, and partially designing the outline of an experiment and asking for a volunteer to flush it out. While there were successes and failures using these approaches, a visual reminder system present in the work area allows simplified management of tracking and holding up the mirror of progress to the teams. To support this reminder, you can involve your agile managers. For example, the discussion during performance reviews could include how the individual contributed to continuous improvement for their team.

Figure 2: Retrospective Action Board

Figure 2: Retrospective Action Board

  • The Retrospective Action Board is portable whiteboard that shows how ideas flow to completion. The workflow steps are:

  • Candidate - Retrospection action topic with multiple team votes without an owner. If you see repeated topics, that is typically a call to action for the team.

  • To Do – Committed to starting or finishing the definition of the experiment by assigned owners.

  • In Progress – The owners are actively defining a detailed experiment for team discussion.

  • “Experiment Implemented” – Team approved experiment is part of teams’ behaviors or practice in the current sprint. Experiment is subject to modification during this phase.

  • “Adopted/Cancelled” – Team has accepted the experiment into standard practice or has cancelled the experiment.

After the retrospective, new candidates without an owner that received multiple team votes enter the “Retrospective Candidates” column.  If an owner is identified, the card enters the “To Do” column.  Experiments partially or completely defined during the retrospective go into the “In Progress” or “Experiment Implemented” columns respectively.

There are two inspection points of the Retrospection Actions Board. Mid-way through the sprint after daily scrum, the Scrum Master asks about updates to the To Do and In Progress cards and if there are volunteers for any Candidate cards. At the start of the retrospective, the team reviews the To Do, In Progress, and Experimented Implemented columns for updates.

Get more information and get organized using the tips that make sense for your teams or adapt them. Effectively serving multiple teams is possible. Contact for questions or to share your tips.