Challenges and hints of being the Scrum Master of two teams at 50%

Are these teams working on the same product or different products?

From what I've experienced, an experienced coach or Scrum Master shouldn't have many problems working with 2 (or even more) teams that are working on the same product.

The problem in a single-product/multi-team environment comes when there are multiple "immature" teams - teams that need more direct teaching or coaching on effective practices, more frequent hands-on facilitation of their events, and similar. If the Scrum Master is still needed to be facilitating events for both teams, that reduces the scheduling opportunities and takes away some freedom and self-organization or runs the risk of teams having less effective events.

In a multi-product environment, it also becomes slightly less intensive with mature teams, but there's a bigger cognitive load on the Scrum Master as the teams evolve their ways of working independently. When not working on a single product, there's more room for the teams to diverge in how they do things. On top of this, you run into a lack of common ground with respect to key stakeholders, Product Owners and Product Backlogs, and event scheduling.

I would have two recommendations:

1. Avoid early scaling. Having two "immature" teams is not effective. Having one team, growing that team, and organic division can help make sure that teams remain effective over the long run without taxing the coach.
2. Align Scrum Masters with products. Assuming the teams share sufficient working hours and existing healthy practices, an experienced Scrum Master should be able to work with 2, 3, or even 4 teams that are working on a common product. At 4 teams is when you may want to consider scaling up the Scrum Master role.

As @Thomas said, the maturity of the teams makes a big difference.  At one time, I was Scrum Master for 4 teams, each on separate products.  Each time I added a team, it was newly formed.  However, I had time with the other teams to get them to a state where I was not needed as much.  

I have worked with 2 newly formed teams on separate products at a company that was undergoing an "agile transition".  It is possible but it does take a lot of effort.  Because they were on separate products, they were willing to work with me to stagger their Sprint cadences.  This was easy for them since everyone was just starting out and trying to find their cadences.  

A piece of advice I will give is that you need to remember that you are not there to lead or manage the teams. You are there to help them become self-managing and self-organizing.  You are there to help them understand the Scrum framework and how it will aid them in producing usable increments of product that are valuable to the stakeholders. When dealing with more than one team, you may have to stop yourself from saying "I can do that for you" and instead say "how do you see yourselves accomplishing that?". Don't do work that the rest of the team is capable of doing or that they will need to do again.  That makes them reliant on you instead of being capable of doing the work on their own.  

Compared to being a Scrum Master for only one team, what changes in being the Scrum Master of two teams at 50%?

50% of what? If you're 50% committed you're the Scrum Master of neither. I'd suggest that therein lies the challenge.

First of all, thank you for all your prompt and valuable insights!

1- Let me please share a question/remark about the following paragraph:

"Align Scrum Masters with products. Assuming the teams share sufficient working hours and existing healthy practices, an experienced Scrum Master should be able to work with 2, 3, or even 4 teams that are working on a common product."

Please let me know if I am having a good perspective on it. As of now, I believe that when it comes to agile scaling, organization tend to “align practices” and ways of working for the simplicity of handling/managing and supervising teams: one example of it could be "For reason(s) X(s), we want to have 1 Scrum Master for Y teams, so let's try to align those teams" and I prefer to avoid that e.g. "to make it easier for the Scrum Master" or similar. In my personal experience, the discussions which will follow tend to be about having the same Sprint length and/or similar event scheduling (e.g. Sprint Planning all on Mondays) which restricts the boundaries of team self-management (which I know is "up to a given extent" necessary), but above all hindering the team perception to take initiative and customize/experiment practices/WoW. On the contrary, I guess we should handle and consider all of this like a framework (e.g. Nexus), but I may be wrong and I am open to hear from you and change my mind about it. :)

2- @Thomas Could you please elaborate a bit what do you mean by "scaling up the Scrum Master role"? Thank you!

3- I agree with you @Ian. I almost see it like "committing to two different Sprint Goals in the same Sprint" :)

Please let me know if I am having a good perspective on it. As of now, I believe that when it comes to agile scaling, organization tend to “align practices” and ways of working for the simplicity of handling/managing and supervising teams: one example of it could be "For reason(s) X(s), we want to have 1 Scrum Master for Y teams, so let's try to align those teams" and I prefer to avoid that e.g. "to make it easier for the Scrum Master" or similar. In my personal experience, the discussions which will follow tend to be about having the same Sprint length and/or similar event scheduling (e.g. Sprint Planning all on Mondays) which restricts the boundaries of team self-management (which I know is "up to a given extent" necessary), but above all hindering the team perception to take initiative and customize/experiment practices/WoW. On the contrary, I guess we should handle and consider all of this like a framework (e.g. Nexus), but I may be wrong and I am open to hear from you and change my mind about it. :)

"Scaling agile" is a broad term. It can mean growing from 1 team to 2, 3, or more teams working on a single product. It can also mean spreading agile practices throughout an organization, whether its across an organization's portfolio of products and services or across functional areas or both. If you have multiple teams working on a single product, there are certain practices that need to be shared across those teams in order to make sure you're building a stable, cohesive product day-over-day. If you're working on a portfolio of products or services that share common stakeholders, there are practices that need to be shared to make sure that the customers and consumers of those products and services can readily accept them without overhead. But if you have disjoint products or services that are offered to different sets of stakeholders, what needs to be aligned across the teams working on those products or services is (and should be, to maximize self-organization and self-management) minimal. It's not about making it handling/managing/supervising teams or making it easy for the Scrum Master, but making it easier for the key stakeholders by ensuring a "common interface".

We know that there are things such as limits to the amount of information that people can store in the head or the number of relationships that people can effectively maintain. We also know the impact of context switching on being able to effectively work. These all apply to Product Owners, Developers, and Scrum Masters. You want to reduce things like the number of events that a Scrum Master needs to potentially facilitate, variations in the ways of working, the number of people (not just on the Scrum Teams, but external stakeholders), and overall things that the Scrum Master must do. Since teams working on a single product share some Scrum Events (see LeSS or Nexus), share many of the same key stakeholders, have the same Product Owner, and end up with integrated ways of working, it only makes sense to have these teams share the same Scrum Master.

Could you please elaborate a bit what do you mean by "scaling up the Scrum Master role"?

Scaling up means having more than one Scrum Master.

There's a lot of knowledge needed by a Scrum Master - lean and agile values and principles, teaching, facilitation, organizational behavior and change management, product management and business development, and development technical skills. Although all Scrum Masters should be aware and somewhat skilled in all of these areas, it's too broad for someone to have deep expertise in all of them. You may need to scale up a small team of Scrum Masters who all have the general expertise to work closely with teams (or teams-of-teams working on a common product/service), but also have differing areas of deep expertise to help each other grow or to provide very specific teaching or coaching, perhaps beyond the team they primarily work with.

There's also a need for redundancy, especially to roll out lean-agile methods across an organization. If you have less mature or experienced (in lean-agile concepts/practices) teams, those teams are going to need more hands-on teaching, mentoring, coaching, and facilitation and will more likely need a more dedicated Scrum Master. Having multiple Scrum Masters can make sure that you account for sick time, vacations and holidays, and other (planned or unplanned) absences.

Once you have two teams working on disjoint products/services or 4 teams on a single product or service, you want to grow to at least 2 or 3 Scrum Masters, and continue to grow the number of Scrum Masters as you have more Scrum Teams across the organization.

I may butcher this, and I don't recall who said it, but it went something like... A good Scrum Master can serve many teams. A great Scrum Master serves one.

I have been Scrum Master for 2 teams aligned to the same product. Given our collective focus was on one product, with one product goal and one Product Owner, it worked fine.

I have also been Scrum Master for up to 3 distinct Scrum Teams at the same time. It is...manageable. With multiple teams with different products, I found I focused less on the products themselves, and more on establishing Scrum and team effectiveness leveraging Scrum. I upheld Scrum Master accountabilities, but little more. Echoing Daniel's comments on self-management and stopping yourself from saying "I can do that for you" when they can/should do it themselves is important.

The times when I have been Scrum Master for 1 team are when I was at my best and was able to better serve the team and the organization.