Being a Scrum Master Part 1: You are the chimera
So now I’m already more than three months into my role as the only practicing Scrum Master in my (quite small) Team. Considering I’ve studied seven years something totally different, it’s quite surreal to think I will coach another Team (yes you heard right). In November, by giving them a retrospective and one on one consulting, I will try to improve and adapt their agile process. I am quite lucky that I am considered “the Scrum Master” in my agency. It’s my key role and everyone acknowledges it. Still I have many of what I call “side quests”, but on one hand thats agency life and on the other they are outside of the Scrum process.
In order to get some information about what I will be facing when coaching this other Team, I had a phone call with their “part-time Scrum Master”. When I heard “part-time Scrum Master” I couldn’t resist taking a deep breath in and a long slow breath out.
“Well basically I’m in my role as Scrum Master, but I’m also Product Owner.” she said.
Here is one thing I don’t get: Most People love rules because they dictate them what to do, so you can turn your brain off and just do what you’re told. Scrum or “agile working methods” overall teach people to work self-organised, think for their own, work flexible, etc. etc. So basically the total opposite of working after a set of steep rules.
Yet Scrum is the method of choice by most Teams that want to start “being agile” — Why? Because it offers a framework where many things are clear and have a name: the roles, the meetings, the artefacts. It’s a good guideline when you’ve never worked with an agile method. And all roles are easily understood, all meetings are understood — except the role of the Scrum Master and the retrospective. Again, why?
A product manager, a product owner and of course the development team are understood because they directly interact with the product a company delivers. Planning, review and refinement are also acknowledged pretty easily because again they revolve entirely around the product your team builds.
But when it comes to the role of the Scrum Master and his main Scrum meeting, the retrospective, many people just don’t get a grip. Which is paradox: When you want to implement Scrum in your new team, you are in fact trying nothing else than a revolution of workflow and working culture in your company, depending on what your product is, how old your team is and many other things.
But the fact is you are planning to change things in a large scale. So when you want to change things big time while keeping up the work… wouldn’t it be common sense that you need someone who has the time and devotion to overlook this process?
The role of the Scrum Master can be seen as a failsafe and backup of Scrum: He is the one that takes all his time and effort into overlooking the process, the meetings, the roles. He keeps track of everyone in the Scrum team, he listens to their complaints, he sets the pieces in motion to refine or rethink the process. He pushes the team in good times to improve themselves even further and he works against the impediments in bad times so that the “ship” can be sailed out of the storm.
He is the one that closes the leaks, so that the people on deck can do their job properly. When there are no leaks, and everyone can do their job, he thinks about the ship can be improved.
Yet, three months into being a Scrum Master I was already asked if I think a full-time Scrum Master is needed when one wants to implement Scrum. I really have a hard time answering questions like these because they give a deep look into how little the asking person knows about Scrum, but on the other hand they often already do some kind of Scrum in their team.
Let’s get back to the main topic: people love rules, people understand things they are used to. Why in the world then, would you give your product owner also the role of the Scrum Master??? Especially these two roles are the ones you really shouldn’t mix because they cancel each other out in certain situations. You as Scrum Master must sometimes defend your development team from your product owner. You see where we are going right? So what’s the thing here? What’s so strong that the human love for rules can be cast aside and chimeras like these are the outcome?
Money. At least that’s my guess.
Most people just don’t get why they should pay a Scrum Master. Or maybe they do but they also think: Ok, that isn’t that much work, at least person XY could do something else besides that. We don’t pay people for doing nothing. Well, on one hand thats an insult to the work a Scrum Master does. When the work is so easy why isn’t everyone applying to be Scrum Master, why isn’t the market flooded. Getting your certificate isn’t that hard.
On the other hand you are sabotaging yourself and your team by giving your Scrum Master a double role. Evaluating, improving and (servant) leading a Scrum team takes time. When you are also working on the product, or working with your costumers this whole process will fall under the floor because the product will always have priority.
And that’s why you have a Scrum Master so that other people have the time to work on your product while your team tries to successfully implement Scrum into their working culture.
So here you have another slice of life from my work as (junior?) Scrum Master.
Don’t let them make you a chimera.
Because if you are, your team will never
be agile enough.
