Let’s have a look at one of the Scrum roles, highly acclaimed, but often misunderstood, in the context of implementing agility in our company. 

I will not start quoting the Scrum Guide, in terms of responsibilities and interactions. I’m sure if you are reading this you are aware of them. But I will share some personal experiences and mindsets I have stumbled on, working as a Scrum Master.

 I’ve encountered this mindset among some senior / middle management I’ve had the chance to interact with over time and it sounded something like – “It’s not hard to be a Scrum Master. You just schedule some meetings in a calendar, send some invites, book some rooms, and create some reports. Most of them you don’t even create, Jira is doing that for you, so what’s the big idea with this role?” (Yeah, it sounded just like that).

Now, allow me to retort, I think this mindset can be as harmful as it sounds, and this harm is not only for the person that is filling the Scrum Master role, but, most important, for the entire organization.
Why do I say that? – You may ask yourself.
Well, one of the main keys for an organization that is trying to have an agile approach would be to let go of command and control chain, work on empowering people, have trust in its employees, and let them steer along the way while only knowing where the organization wants to go, what point to be reached. 

One of the key roles that are helping an agile organization and its employees to steer along that way is the Scrum Master.  Let me tell you what it will happen when Scrum Master role is diminished in front of all organizational levels by having a mindset similar to the one described in the beginning.

For the Development Team, it will be seen as just another layer of control. They will lose trust, not only in the framework, but also in the SM. Any kind of impediments will just go under the rug, without the SM being aware of that.

For Product Owner, Scrum Master will become just a clerk that can carry tasks around, replace her/him in some ceremonies, and fill in some reports for the stakeholders (if needed).

For middle / senior management, Scrum Master will become a resource available to take care of some other tasks, inside or outside the team. They will also constantly ask themselves – “why are we paying this guy for?”

In front of all of this, even the most experienced Scrum Master will become disengaged, will lose focus, will stop shaping team and organization on re-enacting the Agile Values, or at least a part of them. Instead, Scrum Master will stay in its own circle and firefight small conflicts between his coworkers, this being done in between some other tasks.

 Is there a recipe, some miraculous tablets, or maybe some unknown type of remedy for a Scrum Master to overcome all of these obstacles in such type of harsh environment?

I’m sure that every person that took, accepted or maybe was forced into this role of Scrum Master, had learned, over time, that you will get to make the right things, once you stick with the Values, Principles, framework, and constantly improve yourself by learning how others are applying all of these in their own environment.

How you can help Development Team to overcome the fear of another layer of control or gain more trust in you, is by your day-to-day interaction with them, taking no sides when it comes to Product Owner wishes, remove impediments when they arise, hear their needs and address them accordingly, facilitate everything to the best of your skills and knowledge, and always stick with the framework.

Collecting and implementing expectations from Product Owner side can manage your clerk status. Coaching sessions with the Product Owner to improve his skills in writing stories, prioritizing product backlog, communication with the development team, and with stakeholders would be something that will not get unnoticed when it comes to improving Scrum Master status in front of the Product Owner.

In order to calibrate with the organization and step over, “what is that guy doing?” thing, a Scrum Master should constantly ask for feedback, implement the received feedback, share success of his teams (with everyone), experiment with new approaches in ceremonies (should start with retro), keep what is good, also experiment with new frameworks, methodologies or parts of those that best suit the teams he is working with. 

I’m sure I don’t have the perfect answer for the mindset like the one described in the beginning of this article, but this is my approach when it comes to this, and I know for a fact that it is working for me.

In the end, as an organization, you are as agile as your senior leadership is, so you, as a Scrum Master, have the task to make it happen.