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.
Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this communityI 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.
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
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.
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.
I'm a SM for two teams. My approach:
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).