When it comes to the role of a Scrum Master, there are a plethora of misconceptions that can cloud our understanding of what this position truly entails. Having navigated the complexities of Scrum and Agile for many years, I’ve seen firsthand how these misunderstandings can lead to dysfunction within teams and organisations. Today, I want to share my insights on the true accountabilities of a Scrum Master and how we can move beyond the common pitfalls.
Understanding the Role of the Scrum Master
One of the most significant issues I encounter is the confusion between the organisational role of a Scrum Master and the actual accountabilities defined by Scrum. Many individuals transition into this role from various backgrounds—be it project management, development, or even traditional management. Unfortunately, this often results in a limited understanding of the core principles and philosophies that underpin Scrum and Agile.
- Common Misconceptions:
- “You must use user stories.” User stories are not a requirement of Scrum. They are merely a tool that some teams find useful.
- “Burndown charts are essential.” While they can be helpful, they are not mandated by the Scrum Guide.
- “Planning poker is a must.” Again, this is a technique that some teams adopt, but it is not a Scrum necessity.
These misconceptions can lead to the all-too-frequent refrain, “That’s not Scrum,” when teams struggle with their processes. It’s crucial to remember that just because something is common practice doesn’t mean it’s a requirement of Scrum.
The Focus of the Scrum Master
A common dysfunction I observe is Scrum Masters fixating on mechanisms rather than understanding the underlying principles. This often stems from a lack of confidence in their knowledge of Scrum’s philosophies. When Scrum Masters don’t grasp these foundational concepts, they tend to mimic what others are doing without understanding why those practices are effective—or ineffective—in their specific context.
- Key Areas of Focus:
- The Team: While it’s essential to support the team, this should not come at the expense of the broader organisational context.
- The Product Owner: Engaging with the business side is crucial for aligning team efforts with organisational goals.
- The Organisation: A Scrum Master must also consider how their team fits within the larger organisational structure and work to facilitate improvements at that level.
By balancing these three areas, Scrum Masters can avoid creating suboptimal changes that may lead to friction within the organisation.
Moving Beyond Mechanical Practices
It’s vital for Scrum Masters to shift their focus from mechanical practices to a deeper understanding of the principles, theories, and philosophies that guide Scrum. This shift is not just about adopting new tools or techniques; it’s about fostering a mindset that embraces adaptability and continuous improvement.
- Common Stances of a Scrum Master:
- Coaching: Guiding the team to self-organise and improve.
- Mentoring: Sharing knowledge and experience to help others grow.
- Teaching: Educating team members about Scrum principles and practices.
Unfortunately, I often see Scrum Masters falling into dysfunctional roles, such as acting as the “Scrum police” or merely serving as scribes for the team. These behaviours stem from a lack of competence and understanding of what it means to be an effective Scrum Master.
The Importance of Competence
Competence in the role of a Scrum Master is paramount. When Scrum Masters make decisions or engage in hiring and firing, they risk losing sight of their primary focus: enabling the team’s effectiveness. If these additional responsibilities conflict with their role as a Scrum Master, it’s essential to address this imbalance.
- Accountability vs. Role: The shift from viewing the Scrum Master as merely a role to recognising the accountabilities involved is crucial. Many individuals in organisations juggle multiple responsibilities, and it’s vital to understand how these intersect with the Scrum Master’s duties.
Conclusion: Embrace the Principles
In conclusion, I encourage all Scrum Masters to move away from rigid adherence to practices that may not serve their teams or organisations. Instead, invest time in understanding the principles that underpin Scrum. Research, reflect, and adapt your approach based on what truly works for your context.
By doing so, we can dispel the myths surrounding the Scrum Master role and foster a more effective, agile environment that benefits everyone involved. Remember, it’s not about following a checklist; it’s about understanding the ‘why’ behind what we do. Let’s embrace the principles of Scrum and lead our teams towards genuine agility.
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.
