Dedicated ScrumMaster or a shared role?

#32

I’ve been a dedicated SM, and also was split between two teams once. Personally, I have never thought the SM should be a permanent, full-time position. Part of being a good SM is not getting sucked into the team system. You can’t remain objective if you fall into ‘defend the team’ mode, or get pulled too far into the team system.

#33

TLDR: A scrum master can either work himself out of the job, or be the change agent the team needs to successfully deliver.

It really depends on the scenario and situation. I’ve been part of teams that had a full time SM, and i’ve seen teams that functioned well enough without the “dedicated” role as well.
The way I approach this is by I ask the team if they are getting the value and benefit that the scrum master role is supposed to provide during retrospectives. Every role should be providing value towards the team delivering in some fashion anyhow right? Some scrum masters have tons of skills and traits that enable them to stay with teams longer (or even be a semi-team member) like assisting with XP logistics, team gamification, or product owner soft skills. A scrum master is only as valuable as the team’s improvement and progress indicates. Improvements and progress can be “measured” in a plethera of ways whether it’s team synergy, collaboration, quality, delivery, morale, trust, innovation, etc. Some scrum masters have enough knowledge and experience to drive those things, others don’t. Since the norm for most scrum masters is the basics of scrum/agile processes, people tend to think that they can be weeded out fairly quickly (and most of the time, they wouldn’t be wrong…thanks CSM). There is the concept of diminishing returns when team members start to “assume” the role of a scrum master. Teams naturally tend to start gravitating towards normal processes or ways of delivering after a while, which is why I would advocate to have a scrum master pushing outside the box thinking or approaches (if he/she has the mindset and those skills to begin with).

I could also argue that any position is really supposed to “work themselves out of the job”. A developer that routinely codes business rules and logic services could simply build a system interface CMS that removes the need for that backend functional coding. A quality assurance person who routinely tests code or writes automation could implement/utilize a framework that auto detects functions/logic within the code and wraps test automation functions with variable property outputs (property based testing). IMO, it’s not about working themselves “out of the job” but “out of the current problem”. If a developer realized he/she wasn’t providing value with his old frameworks and coding style, would they technically be worked out fo the job too? I see the scrum master role to be no different.

#34

I just found this thread, sorry I am so late to the game, but I’d love to share my experience as I have this conversation often. I have worked in both XP and Scrum organizations so I have experienced the benefits and drawbacks of both having a dedicated Scrum Master and having those duties distributed among the team. So, I am strongly in the “it depends” camp, like I am with most things.

In XP the typical duties of the Scrum Master are distributed among the team and the manager. The manager typically for removing impediments and the team is responsible for their continuous improvement and moderating team ceremonies, etc. In my XP organization it worked out wonderfully. The entire team was dedicated to improvement. I certainly would not be so passionate about agile if I wasn’t in a position to share some of those Scrum Master duties and level up my coaching skills. That team was working together for a long time so they were much closer to ri than shu, so I think that definitely helped.

I’ve also worked on Scrum teams and appreciate the full-time Scrum Master / coach. Especially if the team is just forming, new to Agile, skewed towards junior team members, etc.

#35

Let the team decide what works best for them! Offer opportunities, provide choice, run experiments so they can learn what works - especially if the team is unexperienced. But, let the team decide where to start and where to go.

That’s my summary after reading almost the whole thread. And I would wonder if there are many who disagree :wink: