Last updated on | Agile

Answered: Your Most Burning Questions About Leading 2 Teams as a Scrum Master

by Dominic Krimmer
Leading 2 Teams as a Scrum Master


Hi, everybody! This time I would like to open a discussion about a very hot thread: How to lead 2 teams as a Scrum Master! In my career as a Scrum Master I worked in many different companies and some of them, I had to take over two teams. To be honest, this experience can be very tough and challenging. In this article, I would like to answer the most burning questions about leading 2 teams as a Scrum Master.

Leading 2 teams

In some companies, there is a strong believe that the Scrum Master should take over the second team to be 100% busy. Other companies just can’t afford another Scrum Master, and they decide to assign him to the second team. There are many other reasons why organisations take such kind of decision. The reason why I think this topic is important is that there are far-reaching consequences for the team, Scrum Master and Organization which shouldn’t be ignored. I would like to raise awareness of this thread so that companies and Scrum Masters can see what impact this decision can have on their performance.

Is it a good idea?

I ran through this 2-team-situation now several times, and I developed a clear opinion on it. I also talked with many other Scrum Masters from all over the world, and most of them share my opinion: Leading 2 Teams as a Scrum Master can have many disadvantages on many levels. This doesn’t mean that it doesn’t work at all! That’s why I created two lists: Disadvantages and Best Practices to manage two teams as a Scrum Master:

Disadvantages if a Scrum Master leads two teams:

Losing Focus:
You are not only switching teams, but you are also switching topics constantly. As a Scrum Master, you should be strongly involved in the product and vision of the team. Having 2 of each can cause confusion, and you are NOT always on the same page with the team members. You will be out of context regularly. Team members need to invest more time to bring you on board every time they start a discussion. You will notice that especially in the Retrospectives and Sprint Plannings.

Losing spontaneous conversations:
This kind of conversation is super inspirational and valuable for the complete team. Coffee breaks in the kitchen or spontaneous ideas in the middle of the sprint can change and generate a lot of ideas. This is the time you might miss because you’re sitting in the other team’s room.

Less time to coach:
When you have novice teams they need coaching. They will miss important coaching moments with the Scrum Master as he is too busy.

Do you know this stupid phrase on almost every job announcement: “You have to resist stress”. I give a shit on that argument because I think there is a healthy level of stress that normally every person can resist. Then there is another level where it is getting harder and harder. My experience is very clear: Stress = too much stuff to do. Then you are either bad organised, or you just have to much shit on your list that doesn’t fit into your time. If you try to finish everything on your overloaded agenda, you’re running the risk to delivery bad quality, and this is what a Scrum Master should try to avoid in a team.

Meeting Intersection:
Apart from the normal Scrum Artefacts, there are some additional meetings that could intersect with meetings from the other team. So you have to re-organize or just skip one of them (what leads again to the Losing Focus part)

Lack of Identification:
This does not apply to every Scrum Master, but some of them develop a lack of identification. I am a Scrum Master who needs a strong connection to both, the team and the product. I love to identify myself with both components. When I had my first 2-team-situation, I felt that I lost the identification a bit. Cultures were very extremely different, and it can be hard to settle down in both teams as every team develops an own “insider language” that you might not understand due to absence.

If you have already worked successfully as a Scrum Master, you know what is possible and how satisfying it can be to lead a team to their success. This feeling is great, and you think that you made a change. This can dramatically change if you take over the 2nd team: If you could fall into the traps, I mentioned above it could cause frustration because you are not experiencing the same feelings and success you experienced before. You will be busier in fixing stuff than in developing new skills.

Leading 2 Teams: Here are ten best practices you can apply right away

Companies think they can save money by assigning a Scrum Master 2 teams. To be honest, I think this is not always the case. I think the quality of the Scrum Master can drop heavily unless you have a real hero and both teams already reached a high-level skill in Scrum (Most of the time this is not the case). As I went through such a time I would like to share some Best Practices to lead two teams:

Don’t run sprints simultaneously
I had a time where the sprints of each team started and ended on the same day. This was one of the hardest time ever because at the end of the sprint I had to run 2 Sprint Reviews, 2 Retrospectives, Plannings, etc. My performance dropped, and I could not deliver real quality.

Get even more organised
For sure a Scrum Master should be organised either way. In that special case, the Bullet Journal helped me to manage the situation even better. I increased my productivity with this analogue system, and you can do it too! The Bullet Journal is a customizable and forgiving organisation system. It can be your daily to-do list, sketchbook and notebook for your daily work.

Bring your teams close together
When you’re leading 2 teams, then they should be physically close to each other. This gives you the opportunity to communicate better and jump fast into the other team’s office.

Connect the teams
Try to bring both teams together so that they can connect to each other. Maybe both teams have similar problems or products. This could be very practical because once in awhile you can unite a Team Event where they can share experiences. What you should never do is to mix up Retrospectives or Plannings (unless both teams are working on the same sprint goal). Before you start connecting your teams, talk to each of them before bringing them together. If there is no empathy at all, then don’t mix up.

Communicate your situation
Both teams will recognise the difference and your absence, especially in critical situations. Share your experience with them and explain them your situation. This can open their eyes, and you will receive much more understanding and acceptance. Perhaps the team will help you and start doing things more autonomously.

Choose a talent for moderation
As mentioned above, sometimes the team needs certain help, but you are busy on the other team. If you’re lucky, you have a talent in the team who can jump in and help to moderate the meeting. In my case, I had a strong Product Owner who had a high social competence. She was accepted by the team and made a real good job in moderating.

Be present every day
Don’t make the failure and choose a model where you are present one week in Team A, and in the upcoming week in Team B. This is an absolute anti-pattern. Choose a healthy mix where you are in both offices every day. This is quite hard because sometimes one team needs more attention than the other and you have to find a good balance. It’s absolutely up to you how you balance the situation.

Take advantage of synergies
Sometimes you experience awesome moments and practices in a team that worked out perfectly. Be open and share these experiences with the other team. It is no guarantee that it will work but you can adapt these ideas and transform them into something very awesome. Try to use these synergies because they can save a lot of time.

Never skip the “Daily Meeting.”
Plan the Daily meetings so that you can attend in both teams because this is the shining moment where you plan what to do on that day. Furthermore, these are the 10 minutes where you can receive all the information you might have missed on the day before due to your absence.

Believe me, leading 2 teams can be challenging and if you take your job very serious, you will face difficult and stressful situations from time to time. Although you might have a huge task list, from time to time, you should disconnect from both teams. Take a step back, find a chilled room and relax for some minutes. Use the time to analyse and reflect your work in the last days to find new approaches. This time is essential for you and your brain which helps you to learn and develop your skills.


So these were my ten tips to lead two teams as a Scrum Master. I would like to know if you faced a similar situation. Let’s collect even more tips and practices so that other Scrum Masters can benefit from this article.

Thanks to Luis for publishing my guest article on this blog.


We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.

Take The Test

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team CoachingAgile Training, and Agile ConsultingOKR TrainingOKR ConsultingInnovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing TeamsScrum Team CoachScrum Master MentoringOrganisational Mastery and the External Business Accelerator.

Rate this post:
Dominic Krimmer

About Dominic Krimmer

I have been working as a Software Developer since 2001, being a Scrum Master since 2009. So far, I had the great possibility to collect cool experiences in agile methods in different companies like CHIP, Sixt, and HolidayCheck


Share your point of view

  1. Quite good insights!, I fully agree that having this big block of meeting is unconsciously less productive. Sometimes however, the company asks you leading 2 teams they might work on the same products in that case, I find fundamental to sync the cadence and start/end dates for iterations.

  2. To add to “Don’t run sprints simultaneously” which I agree with, also have fixed days (and times) for your sprint review, retrospective and planning sessions. The teams then know exactly when their meetings are going to be. Avoid changing the days even if there are public holidays – yes the sprint may change in length every now and then but if you keep changing the days to suit you’ll cause yourself a head ache in the long term especially if you have to book out meeting rooms as well.

    1. Hi Paul, Thanks for your feedback. What do you mean with “yes the sprint may change in length every now and then”? So you say it is ok to change the rhythm and length of the sprints??? If yes, I would totally disagree. It is absolutely essential to keep the sprint rhythm very strict. Rhythm gives every team member stability and orientation. So if your teams are switching sprint lengths from time to time, you should consider to stop that.

  3. This is a great experience shared. I believe “empowering team “should be the theme to have successful multiple scrum teams under one Scrum Master. This way the team will become more self driven and self organized which in turn will help the scrum master to breathe in or pick up newer “Facilitation” skill.

    1. Hi, Thanks for the feedback. I totally agree with your point of view. If you run 2 mature teams the problem and conflicts are not that hard and it’s easier because teams are more autonomous. But very often I’ve seen situations very both teams were absolutely helpless and needed help. This article focuses exactly and this situation 🙂

  4. For me all my experiences working with multiple teams at once the teams were all working on the same product which made things much easier. However I agree with the majority of the points made here regardless. Thanks for sharing!

  5. Hi, Thanks for this article, very interesting and I like the tips a lot! I will try to apply them.
    I have a complex scenario here I understand it’s a long comment but I would really, really appreciate some tip.
    I just moved from a big (> 1bn) software company (QA/scrum master) to a small software company (about 15 m but software is a new branch)
    I have this situation: Company opened branch software 3 yrs ago and mainly used consultants, now they are building internal team. In total there are 3 teams. I joined 2 months ago, as scrum master for 2 teams, coach for all POs and the second scrum master (which is a developer/scrum master), cto and now I have been asked to give an introduction to Agile to all manager of the company (about 10) and the board. It’s an amazing and challenging job, I love it because I can really do what I love and we have budget for doing things, but I have the impression that this is a bit too much for me and I need some help in regards of how to handle the situation. To be more precise:
    – I am focusing mostly on 1 team which is the biggest and the most complex of the two.
    – The first team is made of 8 people and it’s not co-located (only once a week). Calendar is complex. I don’t know yet the project very much (I know what the product is but I don’t know yet the technical details of the user stories) but I am trying to know the people and the process first. Forecast Vs Deliveries is crazy (up and down) and there is no steady velocity. However, team delivers,just not in a predictable way.
    – Second team is a platform team which provide the framework to all other teams. It’s very small (3 developers and 1 PO) and it just works fine. Due to my duties (company focus is on team 1) we have decided to remove the daily standup on hangout and they do it without me in their location (50 km from my location). I ask how is going once in a while, I speak with PO on a daily base and I just run the retrospective to help them to find what did’t work and improve in a very friendly way (we eat pizza and we play table games). For the moment it works and they deliver a lot and in a predictable way. It’s pure XP to the limit (as far as I can see).
    – Rest of the company: At the moment I am also supervising the office works (building) because we just move in a new building. So I am very busy doing this too.
    I help my manager (cto) to apply some SAFe principles to help predictability (main reason is the CEO who is not a software guy and doesn’t fully understand how complex and expensive software is).
    – Language is an issue: development team is trying to speak english but rest of the company speak local language. Which does’t help communication and team spirit.

    How would you handle this situation? I mean, here I can really do whatever I want in order to improve the situation I have full trust from all management.
    What I am doing is:
    – Dedicate 8 hrs a week to my own tasks
    – Follow team 1 as much as possible, all meetings, work, etc etc. Let’s say that in the best case scenario I am with them 50% of the time
    – Help as much as possible my manager with SAFe and getting sponsors in the board and among other departments (mainly with presentations and trainings)
    – Coordinate office work which is the main priority.
    – interviews of new candidates (about 3 hrs a week)
    Management, for the moment, is chilled out. I just don’t want to arrive to the situation where things are out of control 🙂

    Any suggestion is more than welcome!

  6. I totally agree with the problems you mention. For me the advantages are missing. A good Scrum Master should always look out for possibilities for his Team(s) to improve. One valuable source is the experience of other Teams. As a Scrum Master for two Teams, experiences can be transfered from one Team to the other.

  7. I’m running 2 teams and we had some great advice from our consultants on possible “collision ” in code development. As well as having 2 Scrum boards we have a visualisation of what development code is in each environment. Therefore before there’s no chance of blowing away the other teams development if a refreash is requested.

  8. This is a great article. However I think that if the teams who are sharing the scrum master work on 2 different products, and have similar sprint timeline, it’s very difficult to handle this scenario . Also, frequent context switching does not work very well for most of us.
    Secondly if the teams are immature it becomes even more difficult.