What are some of the most common misconceptions you encounter about the Scrum Master role?

There are lots of misconceptions about what the accountability of the Scrum Master is supposed to entail. Focus on, um, most of this manifests because of the difference between an organisational role, which might include many accountabilities, including Scrum Master, even if it’s called Scrum Master, um, and the actual accountability as what Scrum talks about and what it genuinely leads to. Because there’s been so many people that have transitioned from whatever they did before into Scrum Master, so they might have been, um, project managers, they might have been managers, they might have been developers, right? And they transition into the role and they have limited understanding of the core principles and philosophies that underpin Scrum and underpin Agile. Um, they end up making some very common, um, mistakes. So common that you’ll see, um, one of the most common responses when people say, “Oh, Scrum’s not working, we did this,” and the most common response is, “That’s not Scrum.”

The reason that’s the most common response is because the thing that they describe, RBE, is not talked about in the Scrum Guide. It’s not part of Scrum; it might not even be part of anything to do with Agile. Um, and people will say, “Well, but in Scrum you have to…” Great example: “You have to have a user story.” User stories are not a Scrum thing. “You have to have a burndown; if you don’t have a burndown, you’re not doing Scrum.” Burndowns aren’t a Scrum thing. Burndowns come from before Scrum, and yes, they might have been encouraged, uh, for a while, but they’re not in the Scrum Guide anymore for sure. Um, user stories were never in the, I don’t think they were ever in the Scrum Guide. I would need to go look at the history of that thing, but, um, I’m pretty sure they don’t. Planning poker? Not a Scrum thing. User story points? Not a Scrum thing. All of these things are mechanisms that people have chosen to use and might be quite common within the context of Scrum, but that doesn’t mean there’s something that you have to do.

Right? If it’s not working for you, stop doing it or pick something else, right? Um, so one of the most common, uh, dysfunctional behaviours that I see Scrum Masters time after time doing is focusing on mechanisms. And the reason this goes back to the confidence story that we have, the reason they’re focusing on mechanisms is they have no skills and abilities and knowledge within the context of the philosophies, principles, and theories. If you don’t understand the philosophies, principles, and theories, you can’t apply them in new and interesting ways. You’re going to look at what other people are doing and just copy that. So you end up copying planning poker. “We’re just going to do planning poker; we’re going to do user stories; we’re going to have a burndown.” We’re going to do those things that everybody else is doing because I don’t understand why they’re doing it. I don’t understand the principles, philosophies, and theories that underpin the reason this thing isn’t successful for this particular team or this particular company.

Competence, right? Move away from these mechanical practices that are a choice and move towards understanding the principles, theories, and philosophies. Another great, uh, most common, um, Scrum Master thing is actually the reason that Agile Coach exists, even though there’s no such thing as an Agile Coach, is people think the Scrum Masters focus on the team. It’s not; that’s one-third of their focus. Scrum Masters should be focused on the team, the product owner, so the business side, and the organisational structure and capability. All three of those things in equal measure are the accountability of the Scrum Master. So focusing on the team means that you’re perhaps creating suboptimal improvements within that team that then create an overall dysfunction in the organisation because you’re not doing, you know, all of… If you’re working in a team and it’s within the context of an organisation and you’re trying to help that team and you get them to do something that causes friction with the rest of the organisation, right? You probably got a suboptimal change.

What you should be doing as a Scrum Master, instead of making that change in this team and making them unpopular within the organisation because they’re not doing the things they need to do, is to work on changing the organisation. Or perhaps it’s the right thing to do, right? Just change it, and they see it’s being successful, and now we can do that. But that’s a strategy. Are you using the correct or most effective strategy within the context of your understanding as a Scrum Master of the theories, principles, um, and philosophies that you’re trying to fulfil, right? That will help you make those choices.

Um, there’s a whole bunch of, uh, stances. Uh, we talk about stances of the Scrum Master, um, and for me, the stances: coaching, mentoring, uh, teaching, right? These are stances of the Scrum Master, and the ones that we see time and time again, actually, I have… They’re so common they’re included in the advanced Scrum Master class because they’re so common. Does the Scrum police, right? “That’s not Scrum,” or “If you’re not doing user stories, you’re not doing Scrum,” or, um, “Oh, you… The team shouldn’t be talking to the customer,” right? All this crap.

Um, you’ve got the scribe of the team, so the Scrum Master writing things down for the team. The Scrum Master has no, in general, I’m using this to highlight a specific context. The Scrum Master has no need to have permission to… No, no, no specific need for that. I’ve helped loads of teams that use Jira, and I’ve never touched Jira. I’ve never been an admin of Jira. Um, those are not part of the Scrum Master’s role. And that brings us to Jira admin, right? Um, being the chairman of the team, being the secretary of the team, being a hero on the team, all of these are very dysfunctional behaviours that are the result of a lack of competence within the context of Scrum Mastery, right?

Um, so anytime a Scrum Master is making decisions, they’re not being a Scrum Master, right? Any time they’re, um, hiring and firing, although those are things they might do, right? It’s absolutely possible for a Scrum Master to also be the manager of a team. Therefore, they might be accountable in the organisational context in addition to them being a Scrum Master for the team. They’re also accountable for reports, for hiring and firing, for decision-making, right? For other things. But that’s not the focus of the Scrum Master. And if those other things are conflicting with enabling the effectiveness of the team, then they become something that it’s expected that Scrum Master to try and address, right?

So this idea of the Scrum Master, the reason they moved it from talking about it as a role to talking about it as accountabilities is because most people in organisations have multiple sets of accountabilities, right? And not all of them are Scrum-related. Scrum is not your whole world when you’re a developer, when you’re a product owner, when you’re a Scrum Master. If you’re a Scrum Master, you might also be a manager. You may be a delivery manager accountable for delivery, accountable for other things, right? You might be accountable for, um, uh, uh, reviews. You might be accountable for various things. If you’re a product owner, you’re probably a product manager. You’re accountable for other things within the organisation. If you’re a developer, although you’re doing Scrum, you might also be accountable for other things in the organisation. You might support and maintain things that are different from what it is your main piece that you’re working on.

So there are so many common misconceptions, and I feel like these misconceptions are so common that they become fact. They become true, like you must do story points, you must have user stories. Try and move away from those things. Try and look at… Do your research, right? Understand why those things exist, and perhaps they are the right thing for your organisation or your team, but also perhaps they’re not.