What are the disadvantages of the Scrum Master being the hierarchical superior in the company?

Question

In a small- to mid-size company trying to implement scrum, it may very well happen that the hierarchical superior of the Team members becomes the Scrum Master (short of being able to fund a full-time Scrum Master position). For example, it could be the CTO in a software start-up company with, say, seven employed developers.

By implementing scrum, the CTO would of course agree to "lose" the authority on the team organisation, task allocation, etc. as it should be. Rather, my question is whether or not the "natural" authority that the Scrum Master has over the Team members (e.g. due to him being CTO) would be an impediment for the process. What are the issues with such a situation? Is it common? Are there any measures that can be used to alleviate the disadvantages?

Answer 1

See a very similar question I asked: https://softwareengineering.stackexchange.com/questions/213395/what-are-the-negatives-of-development-managers-as-scrum-masters

If not handled very carefully, the authority can get in the way of the honesty and transparency that Scrum relies on. I did it for 2 years, and it worked excellently in our case.

Answer 2

In my experiences the one of disadvantages being a Scrum Master is when the organization (small to mid organization usually) not understanding enough SCRUM as a whole package, especially the new Scrum adapting organization, which mean there is still conventional project manager paradigms that organization expect from a Scrum Master.

Answer 3

In real life experience of having a superior as scrum master has a higher possibility of doing the following,

• does not listen to team during retrospect,
• skips retrospect as he thinks it is not necessary,
• marks task as done with his belief, not according to definition of done
• changes agenda of scrum activities
• skips other scrum activities and artifacts,
• fails to time-boxing activities

Measures are,

• keep reminding him scrum would bring us success if we had discipline
• or wait until scrum dissolve silently

Answer 4

We have an analogous situation on my team. Our Scrum Master organizationally is supervisor over the POs on our various scrum teams.

This has created several problems on our team:

• Our SM was previously a PM for our team's project, and as such he has a hard time stopping himself from micromanaging the PO.
• Because the SM is also organizationally the PO's boss, when he decides to steamroll over the PO, it screws up the entire team dynamic because we all know that technically he's her boss, even if within the scrum team we know he's not supposed to have that kind of authority.
• The above becomes a major issue when the PO and SM strongly disagree on how to attack a PBI. As the lead dev on the project, I've no idea which one of them I'm supposed to listen to.

We've tried to address these things in our retrospectives, and the SM pays lip service to taking a step back, but within a sprint or two he's back to micromanaging. Because of his position within the company, there's just not much we can do about it.

Based on all that, my personal experience is that I really do believe that if you're going to have the SM and PO roles be assigned to different people, the SM role needs to be someone with no organizational authority over the team, but who is still in the proper position to remove impediments. Our situation has created a dynamic where we have essentially two POs - one who is PO so long as the SM agrees with her, otherwise the SM becomes de facto PO.

Answer 5

Some good answers on this. I have a perspective on this that goes back to my military service in addition to my time with major software development shops.

I like to compare a Scrum Master to an NCO. I would compare a C level executive to an officer. In my time in the infantry, NCOs had a certain authority (more than a SM really) but they were not the same as officers. Officers were "Authorities" with a capital "A". NCOs were enlisted men with a certain amount of power, who basically used their position to go to bat for the team when necessary. NCOs would be willing to use their experience to their advantage and even take issues up directly with officers and go head to head with them if necessary. Officers might be "mission focused" and lose sight of the team, NCOs were always "team focused" and trusted the men to get the mission accomplished.

A SM should be something of an advocate for their team members with management if they need to be, like an NCO. If you have someone be BOTH a SM and a C-level exec, that can be problematic. Certainly using the military comparison, an officer would never be trusted by the men the same way as an NCO.

Answer 6

Check out the definition of Scrum Master: http://en.wikipedia.org/wiki/Scrum_(software_development)#Scrum_Master http://whatis.techtarget.com/definition/scrum-master

You'll see and probably know that the Scrum Master has two major jobs:

1. Take care of the Scrum process
2. Deal with impediments

The second one is the crucial with respect to your impediment/issues-question: The team should trust the Scrum Master to provide him insights and information to enable him to cover their backs. Flat hierarchy usually very helpful here. In addition the Scrum Master should not be afraid to argue with management to protect the (scrum) process and the team. One could think that it might be helpful to give the Scrum Master more power (in sense of hierarchy). But that will not help. More power leads to a shift of responsibility from process and team to organisational aspects which might conflict.

Is it common? - I don't know but won't be surprised because it is simple.

Are there measures? - Beside project success? I don't think so.

Is is a good idea to take the CTO as Scrum Master? It depends on his standing within the company: Does the team trust him? Is there a atmosphere of trust and appreciation? Nevertheless, he will get conflicts living two roles.