Tribe; the various types of Scrum Master

a lighthearted look at the different people who chose to be (or are bestowed the title of) Scrum Master

Scrum Master has to be one of the most ridiculous titles bestowed upon modern working practice. It’s officially a role in the manifestation of the Scrum methodology, by someone who acts as servant-leader/coach/facilitator to the team. However, it’s been adopted across industry and is synonymous with Agile. However, where Scrum is easy to understand and difficult to master, the scrum master role is difficult to understand and even harder to master. Many have tried to articulate what the role should entail (see my previous post, for example, or ), however, there’s still a wide variance in the types that adopt the role. There’s plenty of discussion about the evolutionary stages: Scrum Dude > Scrum Mom > Scrum Master, however I’ve encountered plenty of other types along the way. Here’s a quick ‘cut out and keep’ round-up of the many different flavours of scrum master:

The delivery guy

Without doubt, the most common example. The delivery guy ensures their team meets their commitments every sprint. The team have been using “forecast” for years, but that doesn’t matter to the delivery guy — it’s a commitment. The delivery guy loves points, in fact, that’s what the team delivers — points. As everyone knows, points means prizes. The delivery guy loves story points, burndown charts, velocity, and all manner of metrics to optimise their teams’ performance. They consider things like daily burndown as an innovation. Needless to say, the team loathe him, and they game their estimation considerably, as that’s the only output they’re measured on. Delivery guy was most likely a project manager in a recent past, or aspires to be one in the near future.

The martyr

The martyr is the teams’ defender. They will fight the good fight of removing external ‘impediments’, they see it as their calling. Product Manager asks the team to work overtime to meet a major release deadline — “OVER MY DEAD BODY,” they scream. HR asks to borrow one of the developers for a few hours to go to a local recruitment event — “ NOT A HOPE IN HELL, IT’LL IMPACT OUR SPRINT” they yell. A new manager has joined and wants to observe the daily standup, as she’s keen to understand agile working — “NO WAY, YOU’LL ANNOY MY DEVELOPERS AND THEY WONT COLLABORATE” they gnash their teeth. They have built a protective bubble around their team that’s impenetrable, and ultimately, detrimental to them. There’s no visibility of their work, and any good will that was held has evaporated a long time ago. The martyr tends to burn out from fighting all the wars.

The frustrated developer

This person is a pain in the arse, because they can’t leave the code alone. Inputs themselves into every technical process; they spend most of their time in Git reading check-in comments, and providing many “useful” suggestions to reviewees. Takes up a paid seat from the limited Jetbrains IDE accounts that have been set aside for actual developers. Actual conversations, reviews and retrospectives aren’t necessary, apparently; neither is having a relationship with the PO, or humans in general.

The bleeding heart

Not as common as the others, and is the polar opposite of the frustrated developer; they tend to be from a non-technical background. They love the coaching aspect of the job, and feel it necessary to provide the safety net for the team to discuss everything. They just want everybody to be happy and collaborative. BH has a range of games for every occasion, however none of these actually improves the delivery. BH tries to ensure everyone is involved in the conversation, to the point were work doesn’t really get done because everyone’s collaborating. Loved by the team, but sadly, Bleeding Heart struggles to understand why delivery is slow, and lacking a breadth of technical knowledge, also struggles to clearly articulate this to senior management. Gets eaten alive.

The guru

Knows all the answers, been around since the beginning, remembers when it was the only the new product development game, and not the New New Product Development Game. Would’ve been at Utah for the signing of the Manifesto, but didn’t think it was going to be that important. No longer a team member, they’ve achieved next-level state, and feel that the team should empower themselves just by being near this force of nature. Spend most of their time in an advisory capacity, or checking into conferences.

The old sweat

These are the folk who’ve come up through the ranks, and see Scrum Mastering not as a promotion, but as a way of actually improving the working conditions for their team. Tend to hold a great deal of cynicism towards management. Generally has a story handy to provide as an example of the hardship they’ve endured so their team doesn’t have to; “I remember the great Cloud migration of ’12; we worked 25 hours a day, 8 days a week to get the damn thing live, and our seniors didn’t even buy us a drink after…” On that point, they tend to get ranty after a few drinks, but they have their teams’ best interests at heart.

It’s not all bad…

Most of the types I’ve mentioned have some positive aspects to the delivery of their craft, however, when amplified as above, can be detrimental and counter-productive. It’s good to understand the context of why they operate the way they do. I would suggest that a blend of all of the above is no bad thing:

• Delivery is super-important, however, focusing on points and not value is detrimental
• Removing impediments and allowing the team to concentrate on their work is a good thing, however, visibility is necessary to achieve understanding and support
• A breadth of technical understanding is good — however, you have to accept that that’s not your role now, and you need to adapt to the human challenges of scrum mastering
• Empathy and collaboration are key to getting people to working together, but not all people need to be involved in all conversations
• Learn from the old sweats/gurus. They may be either arrogant or cynical, but they’ve been around and have seen/know a lot.

In the end, you’ll develop your own style — do what’s best for you, your team, and your customers.

(thanks to Alan Jennings for ideas, and davey.mcglade for proofreading)