Scrum Master for 3 Development Teams

Question

I have been tasked with being the scrum master for 3 development teams.

This is not something I would recommend doing but my boss has laid down the law.

Does anyone know or have any tips for how I should do this without letting things slip.

Answer 1

In a situation like this the key is to be available for all the team members and be there at the important meetings.

• Check the scrum meetings of the teams and make sure that they do not overlap and you have time between two meetings to prepare. If not, ask the teams to change their schedule so that you can be there

• Have a trello or any board where you list the teams and track your thoughts and ideas

• Make sure that you are available for the team members; have a regular "open door" event in your calendar

• Try to sit with the teams at least once in a week, so that you'll have first handed experiences on how they work

• Check the scrum artifacts - board, charts, impediment and sprint backlogs - so that you are up to date and be able to help them in case they'll need it

• Have a plan to "grow" the teams so that they can handle small items without you - actually this is the key to agile; teams can handle themselves (track this plan on your board)

• Have regular coffee or tea with the team members or the teams, so that you know the informal things as well, and they'll know that they can come to you with anything

• If you need, and there is a demand, grow/mentor individuals as well

• Finally, never be late and unprepared

Answer 2

I have been Scrum Master to 3 teams at once and although challenging, it is possible.

The most important thing is to have the the sprints running out of phase with each other, so that you can attend all the Scrum ceremonies.

You will need the morning stand-ups to be at different times as well. It becomes increasingly important to stay within the stand-up timebox so that you don't miss the stand-up for another team.

I would strongly advise getting the meeting rooms for the three teams booked months in advance. This helps to avoid last minute panics to facilitate meetings and also helps the stakeholders and Product Owner to plan around the meeting times.

If the three teams are close together you can get away with one desk. Otherwise you will need to hot desk, moving frequently between the teams. This is important as you need to hear the day-to-day interaction between the teams to have a good idea of what is going on.

Finally, empower the teams as much as possible. Get them to think of the Scrum Master as a facilitator of problem solving rather than the person that actively does all of the actual problem solving. As an example, a problem comes up with one of the build environments. The Scrum Master sets up a meeting between a team member and a system administrator to resolve the issue. They track the problem to ensure it is resolved and hasn't been parked.

Answer 3

TBH, I would say the primary goal of an SM is to make yourself unnecessary by transferring your knowledge, perspectives and mentality to your teams. If you can start to do this (with a steady, sustainable pace) you will free up more time to focus on things they can't do in the short term due to time constraints, external blockers or politics, lack of agile experience, etc.

Answer 4

I'm a SM for two teams. My approach:

1. I schedule all their events differently, so I can join & facilitate all of them.
2. I've analysed the sprint size and we ended up with 1-week sprint and a 2-week sprint team. But of course, this needs to fit the team and their objective / product.
3. I have a set schedule: check boards in the morning, approach the team with issues / questions immediately. Solve roadblocks immediately, never let them hanging.
4. I make sure I have catchups (1-to-1s) with each single person from each team. Mostly in case there is something happening in the team that I'm missing (team dynamics, process issues, individual dissatisfaction, conflicts, etc.) but also to make sure I know my teams well.
5. I'm training the team to become facilitators and be able to do events without me. Documentation of our discussions is the key for me to be informed about everything.
6. We also agreed to have all communications on the team slack channel, no side / private discussions related to anything that happens in the team, product-related questions, process, issues, etc. So, even if I miss a huddle, I can gauge what's happening by being present on the slack channel.
7. I push the team towards being self-sustained. I'm getting them proper Scrum training, using practices that puts the seniors into a more of a leading position (to take over the mentoring / coaching side of the SM, which I can't do for every single person in the team).
8. I have them check and follow metrics. I have them analyse the metrics and identify the underlying cause themselves, so that I don't have to be the only person who raises a flag when stuff breaks.
9. I'm close to the POs and make sure they take lead on their backlogs, develop a healthy relationship with the team (not to be seen as an outsider), and the communication between them and the team is flawless (this saves a LOT of time).

I think this is a summary of my actions to make sure I'm still doing my job, even if I'm spread too thin. 3 Teams is a bit much, I think you'll get burned out. Two is still manageable, if all things work well, it's quite ok and I have time to search for improvements and new experiments for the team. But there were sprints when we had issues and my attention was solely focused on one team and ignored the other. I basically spend more time on the team who's on fire (if the case).