Friday, August 29, 2008

Should the Scrum Master also be a member of the team?

This question is raised frequently. I prefer that a Scrum Master (SM) not be a member of the team, but this is not a strict rule of mine. An SM as team member can create problems:

  • A focus on their own tasks over the team issues.
  • Prioritizing their own impediments over those of other team mates.
  • It can impede team ownership through the “Scrum Master as Team Lead” anti-pattern.
These problems are usually created subconsciously, but they do create barriers to team commitment. Sometimes there is no choice but to have the SM be a member of the team. There may not be enough teams for the SM to fully occupy their time. An SM can handle 3-4 teams before it starts becoming a full time job (your mileage may vary).

If the SM has to be a member of the team, keep an eye out for these problems. Raise them in the retrospective. It’s not easy, but it has to be done. One great way to overcome this is to rotate SM duties. If your current SM is the only one certified or experienced, they should coach the other people who rotate into the role.

Rotating the SM role has many benefits. Team members appreciate and understand the role much better after trying it.


Anonymous said...

This is quite an interesting topic which I got plenty of hands-on experience lately. It indeed can be often very hard for both team and scrum master if scrum master is considered as equal member of the team.

The major disadvantages I have personally noticed are.
1) The roles are hard to be separated by team members. If scrum master brings some issues out as team member, or suggests some possible solution for on-going discussion, it is often regarded as the holy word and ultimate solution and does not get required criticism.
2) The scrum master is regarded as superior. If there are members in the team that are new to scrum and scrum master is for example also working as programmer of the team, it very easily gets into situation where someone sees it as easy way to go ask every now and then from scrum master what he should be doing instead of actively interacting with the whole team.
3) Scrum master is tempted by easiness of development. Scrum mastering can be often hard, it is about dealing people and finding solutions into situations that one has never encountered before and which of results are hard to evaluate. This may lead to situation that scrum master uses too much of time to implementation tasks and pushes those harder, yet most important, scrum mastering tasks a bit forward causing them to pile up and slow down the team as whole.
4) Product owner or high level stakeholders get get confused of the scrum master's dual role. This can lead for example to situation when scrum master is addressed of any failures that team occurs during review sessions, leading into situation that team really does not seem to get hold responsible of their own work, but instead it is all seems to be success or failure of the scrum master. This can lead to both overburdening the scrum master by making him responsible for whole team's commitments as well as taking the major factor out of team's commitment as the meaning of success or failure decreases for them.

What I found as some solutions to these were.

1)I tried out several things to solve this, I have even tried wearing some specific cloth on me when I am acting as scrum master and when as programmer. That was not very successful approach though. The best way I've found is just to change way I act, trying not to suggest anything, until I'm absolutely sure that everyone has brought their own ideas out. That is no good solution either, but currently the best I've come up to.
2)This I've started handling by making clear decision that if someone comes asking anything related to what to do next, I always ask if they are speaking me as programmer or scrum master. If they speak as scrum master I try to find out if there is some confusion in process, and sort that out, if not tell to go talk with fellow programmers. If they come with programmer I usually tell that maybe you should ask if he remembers who has been working with similar things and go discuss about it with him.
3) Observe myself a lot. Whenever I start implementing I ask myself if there is any scrum mastering to be done before that, and if there is it has to be done first.
4) Most useful solution that I've found for this is the naming of point person for each feature and whenever in for example review any feature is brought up for either good or bad I ask for the point person to speak out for it.

Even though already having written way too long post I have to question a bit if it really is good for scrum master to have more than one team? I have heard it somewhere that good scrum master can have up to three teams running effectively, but great scrum master can have only one. If scrum master is really dedicated, pushing for major improvement, it really is full time duty even for only one team. My opinion is that scrum mastering is not only taking care of on-going scrum processes but actively develop processes pushing those forward. And such a process development takes a lot of time and commitment.

Clinton Keith said...


Thanks for the information!

Good point on the cloth. I have heard of scrum masters wearing hats when they are in the SM role.

Great points.

I can't disagree enough on the idea that a "great scrum master can have only one [team]". If the SM role is full time for one team, something is highly dysfunctional! The team needs to examine its organization and try to determine why there are so many impediments that only the SM can solve. More than likely it's something like having component teams than feature teams.

Anonymous said...

I think the difference if scrum master could and should have more than one team is sum of many things.
The size of team(s) is probably one major factor as is the maturity of team in sense of how familiar they are with scrum. My own opinions are probably biased by the fact that I worked with quite a big scrum team in times when we were taking our first steps in the scrum both as team and individuals. So I agree that things are not black and white.

However, I wonder if by having multiple teams, the commitment of the scrum master to any single team can get hindered by duties for the other teams?

As told, I also see duties of scrum master, even though focus is mainly on his team, to consist also the general development and improvement of agile practices in-house. Also, the human nature seems to be such that if you let things just flow on and untouched (even though everything would seem to be going just brilliant) for some time, the concentration starts going down and the team effectivity follows. Therefore it is very important for scrum master to carefully observe both the team as whole and the individuals in team and keep adjusting the working practices with team just enough to keep the things fresh and focus clear, but also all the time so gently that it does not disturb the flow of the team.

And as last but not the least, I consider scrum master as useful buffer for the team. Even though how talented the team would be, there always will be times that surprises occur during the sprint, and if scrum master has time to work as buffer, taking part of that work (be it testing, programming or maybe finding and evaluating new tools) to balance the workload and help team on it's way to successful sprint.

So, to summarize, I think it is all about the perspective. Most of the things I described could be also addressed by other means, fore example organizational changes or different kind of work practices. The funny fact in scrum strikes again, as we are speaking of framework that is to be adjusted by the people who is working with it, the things are never black and white but the environment seems to be a major factor.

Thanks for disagreeing with me, it made me think a bit harder today. :)

Clinton Keith said...

Your definition loads the SM role a bit more than I like to see. E.g. the SM is not responsible for continuous improvements, but insuring that the team is seeking ways to improve productivity.

It's important that the SM role is a facilitation and coaching role. The more the SM does for the team in detailed improvements, the less the team will learn to do things on their own.

I agree, that if you add "and does general development", then yes the SM will have less time to SM multiple teams, but then we're back at the original question.


Anonymous said...

In an ideal world, the SM would not be a member of the team.

The pitfalls were laid out in earlier comments. Where I work it runs both ways, some teams choose a team member to be SM, some teams have SMs that are not members of the team.

The team I am on has a team member as SM. We were recently given the chance to get an 'outside' SM (outside the team, not outside the company), but when put to a vote, the team wanted to keep things as they were.

Clinton Keith said...


That sounds like an extremely "healthy" way for a team to work. Very few teams take the initiative to elect an SM. It sends a strong message to every SM that they work for the team and it gives multiple people on the team insight into the role by doing it for awhile.


Thanks for sharing that.

Unknown said...

You mentioned "Scrum Master as Team Lead" antipattern. Do you know if there is a collection available for scrum-specific antipatterns, like this one? I tried to google around and did not manage to find anything. Taking a look at antipatterns and smells is, in my opinion, a good way to spot things to improve.