Eight misunderstood stances of a Scrum Master: my take on the ‘Scrum Master Vices’ - Kingmaker

Reading time: 5 minutes

In a previous article I talked about the eight stances of a Scrum Master, as described in the whitepaper by Barry Overeem.Overeem also described eight misunderstood stances: the shadow side of the virtues, and the scrum master mistakes most of us have quietly made. As a Scrum Master, these are worth knowing. Not as a cautionary tale from someone who has never fallen into them, but as a map drawn by someone who has walked into every single one. Here are the vices.

The scribe

There is a particular anxiety that lives in the body of a new Scrum Master: the creeping fear that you are not doing anything. You are not coding. You are not writing user stories. You are not building anything tangible. So you reach for a pen and start taking notes.

Wrong call. You don’t have to prove your own *raison d’être* by doing the administrative work. The recording of retrospectives, the minutes of refinement sessions, the notes from Sprint Planning — none of that is yours to own. A self-managing team can manage its own documentation. When you grab the pen, you are quietly signalling that they cannot. That is the opposite of the message you are there to send.

The secretary

The same logic applies to scheduling. Someone has to plan the Scrum Events. There are part-time schedules and public holidays and calendar clashes to navigate, and the team looks at you. You are the organised one, after all.

Planning one event is not a problem. Making yourself the permanent keeper of everyone’s calendar is. It removes a small but meaningful piece of self-management from the team, and once you have taken it, you will find it very hard to give back. Try not scheduling the next event. Watch what happens. A revealing conversation about ownership might break out. That conversation is the point, by the way.

The scrum police

Passion for Scrum is good. Turning that passion into enforcement is where it curdles. Every context is different. What the Scrum Guide describes is not a set of rules; it is a framework, intentionally lightweight, intentionally incomplete. When a team deviates, the more useful response is to coach them back toward the reasoning behind the framework, not to cite chapter and verse and demand compliance. Scrum is not a religion. You are not its enforcer.

The team boss

The team boss has a very clear mental model of what a leader looks like: at the front, directing traffic, solving ambiguity by decree. It is a seductive model. Uncertainty is uncomfortable, and someone has to answer for it.

Except as a Scrum Master, that is not your job. What gets built is the Product Owner’s territory. How it gets built belongs to the Developers. The 2020 Scrum Guide says: “The Scrum Master is a true leader who serves the Scrum Team and the larger organization.” and “There are no sub-teams or hierarchies within a Scrum Team, regardless of what domains need to be addressed.” The SM’s accountability is to team effectiveness, not to direct the work — the authority structure is flat by design. The Scrum Master serves in three directions: the team, the Product Owner, and the organisation. Authority does not come into it. There is no hierarchy.

The admin

The Jira-junkie. The one who tinkers with the automation, owns the board configuration, and gets blamed when the workflow breaks. It is easy to slide into this role: infrastructure problems feel like impediments, and impediments are yours to fix, right?

Not quite. Maintaining the digital workflow is a shared responsibility of the Scrum Team. The moment it becomes solely yours, you have created a single point of failure and, more importantly, you have removed the team’s ownership of its own environment. What would happen if the entire team owned the workflow? You might be surprised at the insights that follow.

The chairman

This one I lived. My very first Sprint: a Product Owner who would not attend the Daily Scrum, would not engage with the team during the Sprint. Waterfall background, client-contractor mindset, not interested in collaboration. The Developers would report to me each morning — what they had done, what they planned to do. I would collect the information and relay it by email. The Product Owner would respond: “Yeah okay, carry on.”

I was the chairman. I was the middle layer between the team and the person accountable for the product. It felt like facilitation at the time. It was not. It was a replication of the exact project management structure Scrum exists to disrupt. The Daily Scrum is not a status report addressed to the Scrum Master. That it took me longer than it should have to understand that is not something I am proud of.

The super hero

You may not wear a cape. You might as well.

The Super Hero Scrum Master solves everything. Broken keyboard, expired software licence, interpersonal tension, unclear requirements: it all lands on your desk because you said you were there to remove impediments, and now “impediment” means anything that is mildly inconvenient. The team stops problem-solving because they know you will do it.

You are not Batman. *(I am also not Batman, regardless of what my wardrobe suggests.)* The team is the superhero. Your job is to help them act like one, not to replace the function. When issues exceed what the team can address through self-management, you step in. Until then, let them work it out. The technical term for this is Alfred. Be Alfred.

The coffee clerk

Bring coffee. Bring snacks. Be a decent human being. These things are not wrong.

But they are also not your primary contribution to team well-being, and if you have started to think they are, something has gone sideways. Daniek Pink’s (Drive, 2009) research distinguishes “if-then” extrinsic rewards (do X, get Y) from intrinsic motivation rooted in Autonomy, Mastery, and Purpose. For complex cognitive work (which is exactly what Scrum teams do) if-then extrinsic rewards can actively undermine intrinsic motivation over time. No snack tray closes that gap. The well-being of the team is a collective matter. If you want to invest in it meaningfully, invest in the conditions for genuine collaboration. That produces something the biscuit tin cannot.

You have probably done all of these

So have I. All eight. Some of them repeatedly.

The pattern beneath most of these vices is the same: a Scrum Master who is anxious about their own usefulness, reaching for visible activity to justify their existence. The pull is strongest when the organisation expects a Project Manager and has hired a Scrum Master by mistake. You can feel the pull toward the old role-shape. You grow out of it. Or you don’t, and the team pays the price.

If you want to stay honest with yourself, pick the one stance on this list you recognise most clearly right now. Not the one you used to do. The one you are still doing. That is the more useful question.