Shouldn't the SM always be an integral part of the team?
Hi there,
In my company (mid-sized worldwide company of ca. 200 employees) it is customary to have SMs that aren't an integral part of the team, e.g. they can evolve themselves as developer in another team whereas they are to show up during the stand-ups and the planning meetings of the team whom they are assigned to as SM.
This has been decided so since the very early times of Scrum in our company, it is apparently even sort of appreciated between the SMs themselves... however this is something that tends to bug me, and as far as I know that tends to bu other colleagues as well.
In fact, regardless the good efficiency of some SMs rather than others, I this strictly goes against what Scrum is supposed to be. The main reason is simple, I do believe that one cannot feel, see and get rid the impediments if he's not part of the daily team work. End of the story. I've evolved in two different teams over my first three years and I can clearly see the difference. Our first team was a disaster, the project got aborted and dismantled after two years of an unfruitful work, for several reasons and surely not because of the SM... but on the other hand I wouldn't say that the SM, in spite of his good will, necessary stood against or for what he should have been standing against and for on a daily basis within the team itself. My main opinion is that since the SM was out of the pressure and the daily routine he could not clearly ponder the situation and be apt to modify it.
After the team's dismantlement, I was moved to a new team but working on our 30-year-old cash cow and by then I wouldn't say that the situation and the vision of the team was as risky and pointless as my former one, nevertheless one thing leading to another, it turns out that the SM is himself a part-time developer in our team and I can concretely see a difference in his approach here (although I believe he's got the same proficiency with Scrum that our former SM). But still... that makes the point for me.
So, SM not part of the team, pointless or meaningful?
Cheers,,
Here are three fundamental roles in the Scrum method of agile software development: the Product Owner, the Scrum Master, and the team. The second role I’d like to examine is the Scrum Master, who, serves as a facilitator for both the Product Owner and the team. He or she has no management authority within the team and may never commit to work on behalf of the team.
In Scrum, the Scrum Master demands a distinct personality type to succeed. The best Scrum Masters are real team players, who receive as much satisfaction from facilitating others’ success as their own. They must also be comfortable surrendering control to the Product Owner and team. For those two reasons, traditional project managers don’t usually make great Scrum Masters.
So, specifically, what does a Scrum Master do? The Scrum Master remove any impediments that obstruct a team’s pursuit of its sprint goals. In other words, the Scrum Master does everything he or she can to facilitate productivity. When a developer’s computer dies, it’s the Scrum Master’s job to ensure it is back up and running—or get another one. If developers are complaining about the high temperature in the team room, the Scrum Master must find a way to cool it down. It might be easy to summarize a Scrum Master’s work in a sentence or two, but scenarios he or she could face are truly infinite.
The second role for the Scrum Master is to own the success of the teams process. This might means helping helping the Product Owner maximize productivity or helping the team turn the sprint retrospective meeting into an evolutionary / Kaizen experience. Facilitating for the team or Product Owner might also include tasks like helping maintain the backlog and release plan or radiating Scrum artifacts to ensure the Product Owner or The Team is informed about progress.
A Full Time Facilitator?
An adequate Scrum Master can handle two or three teams at a time. If you're content to limit your role to
organizing meetings, enforcing time boxes, and responding to the impediments people explicitly report, you can
get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation
at your organization, and probably nothing catastrophic will happen.
But if you can envision a team that has a great time accomplishing things no one previously thought possible,
within a transformed organization, consider being a great Scrum Master.
A great Scrum Master can handle one team at a time.
I recommend one dedicated Scrum Master per team of about seven, especially when starting out.
Thanks for shedding a light! So typically, being an integral part of the team, or not, does not hinder from being a good Scrum Master as far as I can understand.
This sort of makes sense but it is also it is also somehow contradicting with you can hear from Uncle Bob:
https://www.youtube.com/watch?v=hG4LH6P8Syk&feature=youtu.be&t=20m53s
As you say, one of the two backbones of a good Scrum Master should be a strong sense of empathy and the needed pro-activity that should come with it in order to overcome any impediment.
In the end, I believe like that having a Scrum Master who's not part of the team can lead to the risk of having someone totally disconnected from the team's universe, eventually feeling superior from all that, and therefore not always be able to see the pressure and the impediments the team is facing.
That's a risk, indeed, that doesn't make all that wrong though, but shall we agree nevertheless that it's risk worth being considered?
Hi,
Is it fair to summarise your concern to be that the Scrummaster should be engaged and aware of what is going on.
The framework states that someone is to be in the role.
The danger of being in two roles within a team is that confusion emerges around which role you are operating in. A Scrummaster as a full time standalone role is a widely used pattern to be engaged with what is going on, and objectively detached from the development work.
All three roles (PO, SM, and Dev Team) need to be integrally involved, as otherwise the potential of the team will not be achieved.
What scares me is that it 2 years of waste to figure out you were going nowhere. I would hope that having all 3 roles engaged and objective the decision to stop should have come sooner.
Regards
A Scrum Master can, in principle, be a servant-leader for more than one team at the same time. What matters is that his or her ability to do the job properly isn't compromised.
I've been a Scrum Master for two teams simultaneously on three occasions. If team sizes are small and the risks are understood and controlled, and if the teams are co-located, then it is plausible for two Scrum Teams to be served. However the SM *must* be an integral member of each one. If this is not observed then the team is, by definition, a disintegrated one and the risks to delivery will increase.
"However the SM must be an integral member of each one. If this is not observed then the team is, by definition, a disintegrated one and the risks to delivery will increase."
I guess that's the most important word to retain of this thread then. Thanks!
According to the Scrum Guide, the SM facilitate the meetings "if required".
Seeing the SM as a facilitator looks very reducing to me.
I facilitate some meetings for several teams when the SMs ask me to do so, in order to bring some fresh air.
But I am not part of these teams and as a external facilitator I can't coach the teams to learn how to be self-organized. That is the main role of the SM.
The SMs can coach their Scrum Teams because they spend time together, because they know each other well.
I do not think there are only yes-no answers in such situations. I remember once we had SM on board who was also developer, his knowledge at this point was priceless cause of understanding of architecture issues and helping nail down impediments. On the other hand when the sprint is danger where to react in own team as development team member or in team where is in Scrum Master role. I also know case when SM is rather agile coach in team and also full time developer in the same team. Team and financial results of this company prove it is working for them.
According to how many teams good SM can handle - I can figure out situation when one is not enough for beginning:)