Defining a Scrum Master Plus profile

The performance of the Scrum Master reflects the success of the team. The impediments they face are often organizational ones.

• Is the success of the team, in this case, proving difficult for management to gauge? If so, why?
• Do Scrum Masters ever recognize their poor performance in this regard, and bring it to the organization's attention, so they can then be helped to succeed? If not, why not?

I was once invited to apply for a position titled "Scrum Master Plus" when I was looking for my first full-time Scrum Master position.

It was in the Netherlands, so perhaps there's even a chance that it's the same company, or someone in the same network was inspired by the concept.

I wasn't offered the job, but I didn't feel there was sufficient appreciation for the Scrum Master role, nor did there seem to be respect for the ability of the (remote) Development Team to self-organize. It seemed like a cost-cutting exercise and more like paying lip-service to Scrum than having a clear purpose for implementing it.

If I remember correctly, I would have been expected to propose architectural and infrastructural solutions. I pointed out why I thought this was a bad idea during the interview, and although I don't believe it's the only reason, perhaps that contributed to me not receiving an offer.

Now from what you post, it does sound different, but I'd be inclined to have a conversation with the employer and really get to grips with what they're expecting, and how that relates to empiricism and self-organization.

Do they want you to add transparency, enable inspection, and facilitate adaptation as part of a self-organizing team; or do they expect you to stand up for an unhelpful and disrespectful way of working?

Perhaps you can drive this conversation around outcomes. What meaningful outcomes would your manager want to achieve? How would this manager react if your propose to dismantle the Infrastructure department and presumably the one that employs current Development Team members, and instead create space for all of those individuals to organize themselves into cross-functional Scrum Teams that have a purpose — each capable of delivering working software without relying on another team?

With respect to the answers to my initial post, here are more details:

I totally agree with: The performance of the Scrum Master reflects the success of the team. The impediments they face are often organizational ones.

With respect to the following:

"Is the success of the team, in this case, proving difficult for management to gauge? If so, why?"

It is not about difficulties with measuring the success of the team. Today the organization has around 25 scrum teams. Some of them perform poor and some of them are great. As an example, for life cycle management some teams work with a software package that is not supported anymore and other teams work with (other) software package that has the latest version. The problem is that management want Scrum Masters to instruct, manage and monitor the team on life cycle management. While I do think it is totally the development teams responsibility, in other words they need to bring forward stories to the PO and the PO needs to prioritize. For some teams this is not a problem , for others it is difficult, that's why management thinks it is a good idea to make the scrum masters responsible for all the bullet points mentioned (including the lifecycle one. 

"Do Scrum Masters ever recognize their poor performance in this regard, and bring it to the organization's attention, so they can then be helped to succeed? If not, why not?"

I am not sure these items are the responsibility of the scrum master in the first place. The scrum master should help the team in recognize the importance of these items. Put stories on the backlog and have the PO prioritize these. 

The poor performance could be linked back to teams that work with legacy software, business pressure for new features, important audit issues, legal requirements with short deadlines, ... which get presedence over the above mentioned items.

My fear is this super scrum master role description could soon turn into a project manager role description, because that is what they have been working with their whole life and that is what they know.

In answer to the following from Simon Mayer:

"I wasn't offered the job, but I didn't feel there was sufficient appreciation for the Scrum Master role, nor did there seem to be respect for the ability of the (remote) Development Team to self-organize. It seemed like a cost-cutting exercise and more like paying lip-service to Scrum than having a clear purpose for implementing it."

Wow, this is exactly how I feel. I have written an email talking about lip-service Scrum and the disrespect or more not listening attitude to the Scrum Master knowledge with respect to applying Scrum! But sadly enough this had no effect.

"If I remember correctly, I would have been expected to propose architectural and infrastructural solutions. I pointed out why I thought this was a bad idea during the interview, and although I don't believe it's the only reason, perhaps that contributed to me not receiving an offer."

Well this sounds all too familiar, indeed it looks like they want the Scrum Master to have architectural and infrastructural (and IT) knowledge and "impose/lecture/manage" it on to the teams. Looks to me like a project manager description.

"How would this manager react if your propose to dismantle the Infrastructure department and presumably the one that employs current Development Team members, and instead create space for all of those individuals to organize themselves into cross-functional Scrum Teams that have a purpose — each capable of delivering working software without relying on another team?"

I already proposed to move to Devops, however because that would solve the infrastructure decency. However they do think it is too early to move to Devops. The Agile transition only started 2 years ago.

"Perhaps you can drive this conversation around outcomes. What meaningful outcomes would your manager want to achieve? "

I did not yet go this way, maybe this will help. Need to think how these points relate to outcomes though.

This gets me thinking, maybe it would be an idea to address it from another angle. What is it that the manager don't see happening (like what outcome) and why that is not covered with the scrum master role in the scrum guide?

If my organization would put a Scrum Master above me with more or less the same responsibilities I have, but additionally intervening into the self-organization of the team, I would question if they know what they are doing.

On the other hand, I see some points here. It is correct that there are impediments within organizations and those may be valid for more teams. So it makes sense to have a Scrum of Scrums and therefore a Scrum of Scrum Master. This is mostly targeted when you have several teams on the same product, but does also make sense for several teams in an organization. Then you may not need it in the same frequency as you have the Sprints, though.

But that Scrum of Scrum Master should not interfere in the work of the teams and should only coach the Scrum Masters

In answer to Tim Moeker:

The Scrum master plus role is not related to scaling. There will be no hierarchy within the scrum master community.  The Scrum master plus role will be applied to all scrum masters. 

If I read your original post correctly I believe you said that all of those things are being added to the Scrum Master job description and not to define a position that is above Scrum Master.  If that is the case I really have no problem with it. 

Scrum defines a role and not a job title.  Frequently job titles/descriptions will elaborate on specific things that are important to the organization that the individual with the title will work inside. 

Most of those things I read from your post seem to fall within the scope of the Scrum Master role as described in the Scrum Guide.  Most of them fall under the Service to the Development Team for

• removing impediments or
• "coaching the development team in organization environments in which Scrum is not fully adopted or understood".  

A few fall into Service to the Product Owner for

• finding techniques for effective Product Backlog Management. 

A couple could be seen to fall under the Service to the Organization for

• "Causing change that increases the productivity of the Scrum Team", 
• "helping employees and stakeholders understanding and enact Scrum and empirical product development",
• "causing change that increases the productivity of the Scrum Team" and
• "working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization".  

I have seen Scrum Master job descriptions that had things listed that I really did not agree with.  But all of the ones you listed I could live with.  

I already proposed to move to Devops, however because that would solve the infrastructure decency. However they do think it is too early to move to Devops. The Agile transition only started 2 years ago.

If it's already taken 2 years, maybe it stalled.

It seems there is some evidence that these current practices are unhelpful, but there is some impediment to doing things differently.

Now, instead of focusing on resolving that problem, the organization appears to be adding extra responsibilities on top of the Scrum Master role, to try to manage it in some way. Not only are these extra responsibilities a form of waste, they preserve the status quo and are likely to impede the Scrum Master in helping to fix the underlying problem.

Who is sponsoring this agile transition and wants it to be successful? Is the current situation transparent enough to them that they can understand the empirical case for removing this impediment.

I am not sure these items are the responsibility of the scrum master in the first place.

I would suggest that a Scrum Master's success is reflected by the success of the team, and that he or she ought to have a low tolerance for organizational impediments. An effective Scrum Master helps everyone to understand Scrum better and to succeed, from the team itself to the organization's senior executives.

In response to Daniel Wilhite, the examples you give look to me indeed like that it seems fine, and most of these fit within the realm of the scrum master role as described in the scrum guide. Thank you for your answer, it looks like these all fit within the scrum master role already. By taking a step back, I grasped your idea. Sometimes the heated discussions on the scrum master role can get me on the edge.

Though there is one thing that is bothering me still and that is the monitoring of the work for the infrastructure department. The department is understaffed and due to the high demand from the different scrum teams it is clear that work gets not done, because of that the infrastructure work gets delayed. Now the idea is to set up an administration and weekly returning meetings all led by the scrum master. However in my view that will not solve the problem, you can set up as many meetings and administration you want, in the end it will not solve your problem, i.e. too few infrastructure engineers. So, now instead of dealing with the problem at hand, too few infra engineers, now you are going to bother the teams with administration and meetings, which they soon will know, will not help at all. I have tried to get this across to management, however they don't listen and think it will be solved by administration and meetings.

[1] We already have position similar to Scrum Master growth path.

Example: SAFe has RTE, STE [https://www.scaledagileframework.com/#]

[2] Scrum Master can become Agile Coach (More working on Coaching, Mentoring then Facilitating, Teaching) and working at organization level or department level then working for specific team/teams.

Though there is one thing that is bothering me still and that is the monitoring of the work for the infrastructure department. 

This paragraph is troubling.  If you were the Scrum Master for that team, I can see where making visitble the work that needs to be done and the work that is able to be done would be useful. It could be seen as part of the duties to the Organization of "Helping employees and stakeholders understand and enact an empirical approach for complex work;".  It indicates that the work can be done but not as staffed and something needs to change.  Could be stretched to be part of removing impediments but that would be a loose fit. 

Monitoring the work of another team isn't what Scrum Masters do.  Coordinating with another team on work that is needed is more Product Owner than Scrum Master.  But I am really struggling to see how Scrum Master of Team A can be required to monitor the work of Team B.  What if Team C is in need of work from Team B?  Does every Scrum Master monitor the work of every other team?  This reeks of Waterfall and Project Management Office duties and isn't something I would consider to increase agility. I'm not sure what to suggest for you but I do agree that this is not a good idea. 

Wondering if the update to the Scrum Guide reframes this discussion a bit. Scrum Master is no longer defined as a role, but as an accountability. As Scrum Master we are accountable for establishing Scrum (as defined in the guide) and we are accountable for the Scrum Team’s effectiveness. We do this by helping the Scrum Team to improve its practices. I think the key here is that we do so within (or without violating) the Scrum framework. Is this a question of being outside of the Scrum Master’s accountabilities? Or that the items listed somehow violate the Scrum framework?