Having worked as a Scrum Master, alongside Scrum Masters, and having managed & mentored Scrum Masters for the last nearly 9 years I have seen several patterns of behaviour that can characterise the way in which different people perform the role. Many articles have been written over the years about the Scrum Master role, how damaging it can be and how wrong it is for the team. I believe that these thoughts are the results of witnessing anti-patterns in the role, when the people performing the role have not yet embodied a way of being that is most helpful to the team. Here I’m going to give five examples of patterns that I have seen and sometimes strayed into myself. This is how I would characterise them.

The Consultant tells everyone how things will be done. They have an opinion on everything and aren’t afraid to express it. They run all the conversations, instruct the team and generally direct everything that’s happening. It’s their way or no way. They are prescriptive, directive and a borderline dictator.

The Enforcer is there to ensure that the team are following the Scrum Guide – to the letter. If they catch anyone not following the ‘rules’ they will duly direct them back to The Guide. We follow The Guide, no matter what – rules are rules and there is no deviation.

The Pleaser is there to make sure that everyone is OK – they are the team happiness monitor. They are there to smooth the way, calm any conflict, make sure everyone feels good and instigate the group hugs. If someone looks at all sad, the Pleaser is there to comfort them. If a heated discussion begins to surface, they are there to calm the mood and smooth over the cracks. Everyone must be happy and they will ensure this is so, whatever it takes.

The Fixer resolves everyone’s problems before they even know they have a problem. They float around all day looking for things to fix, whether they need fixing or not and regardless of whether it is their responsibility to fix them. If they can’t see anything to fix, they’ll quiz you until they find something.

The Coach is there to ensure that the team solves its own problems. They will never answer a question – oh no! The team knows the answer and must discover it for themselves, however long that takes. They are there to ask the questions, mirror back the answers and generally ensure that the team owns every single decision they ever take, even when they are about to step off the edge of a cliff.

Each one of these is an aspect of the Scrum Master role taken to the extreme. At times, a Scrum Master must provide Agile Consultancy for the team, giving them the information and guidance that they need to proceed. The Scrum Master may refer to the Scrum Guide as a reference point, to ensure that the important aspects of the framework are not being unnecessarily missed. The Scrum Master must serve as the emotional barometer of the team, able to detect when moods are changing. Of course they will help fix impediments. Finally, they must also be able to Coach to the team, knowing when to step back and allow the team space to self-organise and own their decisions. Each one of these aspects (and there are others too) is done in balance with the others, according to the needs of the team at any moment. The Scrum Master changes their interactions to support the team in the best way they can. These characteristics only become anti-patterns when they are used persistently, in an inflexible and extreme manner.

If you’re a Scrum Master, what sort of Scrum Master are you? And what sort of Scrum Master do you want to be?

I've been unhappy with my weight for the last few months. I only wanted to lose half a stone but nothing I tried worked. I tried measuring many things. I measured the number of steps that I took each day. I measured the number of hours exercise I did each week. I counted the number of ‘bad’ things I ate. I measured many things but nothing helped and the months drifted by in frustration. Then one day I decided to measure calories. I know what you're thinking – “well duh!” – but it just hadn't occurred to me before. Knowing how many calories my body needed each day, and consistently tracking a number below this, finally got the results I was looking for.

How does this apply to success in our Agile teams? Well, we need to know what we're aiming for in order to know what to monitor and track to get us there . As Michael Sahota says in one of his Agile Transformation Traps - we shouldn't be doing Agile just for the sake of doing Agile . There has to be a reason for choosing an Agile approach. Having learned this, it reminded me of a session that I attended at the Global Scrum Gathering in Vienna where Brian Milner presented the 9 business drivers defined by pathtoagility.com. These are Employee engagement, Time to market, Market responsiveness, Customer satisfaction, Predictability, Productivity, Quality, Innovation, and Continuous improvement.

And we need to know not only what this desired reason or driver is but how we will track and measure it to gauge our success. Our leadership needs to understand what it is that will make our business successful. Then our teams need to know how to measure progress against this criterion, to ensure we are achieving the outcome we intend. For example, if we measure velocity of our teams, when what the business (and the customer) wants is improved quality in the product, we will never reach our desired results. Velocity and quality are two very different things. First, know what we're trying to achieve; second, know how to measure that. If our leadership can't tell us what we're trying to achieve then our teams can only guess. Once leadership know what it is they want to achieve, all they need to do is convey this to the teams and let the teams track what is needed to achieve this – tracking the right thing for the right outcome. In our empowered Agile teams, there is no need to track this for them. Show them the vision of where the business wants to get to and let them track their progress towards this, using the most appropriate empirical data they have available for this. Without this, teams will guess what to track and results will be random.

Three weeks after I started tracking calories, I had lost the half stone that I had wanted to lose. All I had to do was measure the right thing and I was able to get the results I wanted. Know what you want to achieve and know what to track to get there; then let the teams track their progress towards this. Then our teams, and our business, can be successful.