When one of my heroes says something like this I can’t but pause and really think about things… I was fortunate to be a part of the SA Agile Coach Camp this weekend and so I took this question/fear to the group: When are Scrum Masters helpful and when do they hurt? I wanted to hear stories and have a vulnerable conversation about what it might mean if our role is causing more harm than good. I was both scared and curious going into this conversation. Ultimately, I learned a lot and left with some ideas, a little hope, and no definitive answers. This is my attempt at sharing the conversation.

It was not difficult reaching a consensus that the potential for harm with this role is high and that we have all seen some pretty bad examples. We decided to explore cases where we’ve seen the role help and hurt to see what came up.

When does a Scrum Master hurt?

The following stances/approaches if taken by a Scrum Master can seriously disempower teams, create an unhealthy reliance on the role and possibly build resistance towards Agility:

• The Scrummy mummy: overly nurturing, protective and mothering towards the team
• Project Management: chairing meetings, asking for status updates and driving activities related to task management
• Too attached: when attachment (to the team or project) robs the Scrum Master of his neutrality or ability to take action
• The secretary: the admin person
• Too nice: when the desire to fit in and be liked interferes with doing what is best for the team
• The 1 trick pony: when the Scrum Master only has knowledge in one discipline, ie. only knows about Scrum
• Scrum zombie: a cold, un-empathetic enforcer of Scrum
• Expert mindset: when the team or Scrum Master sees the role as being ‘the expert’ on Agile

When might a Scrum Master help?

The following is a list of things that we felt improved the Agility of teams and systems without creating an unhealthy reliance on the role. Scrum Masters help teams when they:

• Enable connections: Seeking opportunities for connections across the organisation, a Scrum Master is able to connect people without a reliance being created on herself
• Become a change agent: Influencing (rather than dictating) change leads to stronger, healthier teams and systems (leveraging Agile values, principles and frameworks to notice opportunities for change)
• Value both process integrity and context: Scrum Masters ought to know when not to compromise on a framework and have a deep enough understanding of the discipline to be able to take the team on this journey
• Journey together and have humility: The Scrum Master acknowledges that she is growing and learning with the team. The Scrum Master is able to say, “I don’t know”
• Value support from other Agilists: The Scrum Master becomes stronger when he is immersed in a community in which he is able to learn and grow

To avoid verbosity, I won’t expand on the rest (let’s have a chat in the comments if anyone would like to explore these further): People first (Care about humans), high EQ, mindset based approach, influence not authority, notices the dysfunctions, healthy detachment and courage.

Is this an education problem?

The conversation moved to discuss the possibility of this being an education problem. What is the path of a junior Scrum Master? How can mentoring and shadowing help? How can we reframe the role as one of a ‘constant learning journey’ rather than the expert, so that the Scrum Master might learn with the team as they go?

“Good Scrum Masters should work themselves out of their job” — really?

We felt that this somewhat overused statement doesn’t help. It feels like it creates the perception that Scrum or Agile are fixed destinations rather than journeys. In complex environments, things are changing and the need to adapt remains constant. Teams hopefully become stronger and more effective with the help of their Scrum Master — and the knowledge and focus of the Scrum Master will hopefully, always add value to the system, even if that focus shifts over time.

Is the name the problem?

We concluded the conversation by looking at the name of this role, “The Scrum Master.” A lot of what we saw as hurtful was actually implied in the name. The master, the expert, the Scrum ‘enforcer’ — all of these associations came to mind for us when we thought about the name.

So we thought of different ones: Scrum leader, Scrum enabler, Agile facilitator, Agile custodian, Agile navigator, Agile evangelist, Agilist, Team Coach and ultimately, the one we loved the most: the SCRUM GUIDE. A guide is not a master, a guide connects routes, creates a path but does not dictate and ultimately serves the group.

In conclusion…

Reading Ron’s tweet hurt, it stung and triggered a bunch of insecurities for me. I don’t think that this is a bad thing. I think it’s good that we feel like this from time to time. I think it’s important that we question what we do and tread lightly if we might be doing harm. I continue to believe the role can add value to teams and organisations and I hope we continue to question this.

A big thank you to the wonderful humans that joined this conversation: Malene Jacobsen, Laurent Fillis, Alex Whyatt, and Chris Garvey.