In the world of Agile, one of the most common misconceptions I encounter is the idea that there exists such a thing as a “junior Scrum Master.” This notion is not only misleading but also detrimental to both the individual and the organisation. I’ve seen organisations mistakenly believe that the Scrum Master role can be filled by anyone on the team, often selecting the least productive member to take on this responsibility. This approach does a disservice to the individual and undermines the entire Scrum process.
The Reality of the Scrum Master Role
Let’s unpack this. The role of a Scrum Master is far more complex than merely facilitating a few meetings. It requires a deep understanding of the team’s dynamics, the product, and the broader organisational context. Just as a football coach must grasp the rules of the game and the nuances of league play, a Scrum Master must possess a solid technical foundation relevant to their team.
Understanding the System: The Scrum Master is not just a facilitator; they are a system coach. They focus on the effectiveness of the system itself, encouraging the team to reflect on their processes and identify areas for improvement. This requires a comprehensive understanding of how the team operates within the larger organisational framework.
Navigating Complexity: The Scrum Master must navigate the complexities of the organisation, understanding how different teams interact and how changes in one area can impact others. This is not a task for someone who is new to the role; it demands significant expertise and experience.
The Misconception of “Junior”
The term “junior” implies a lack of experience or skill, which is simply not applicable to the Scrum Master role. Just as there is no such thing as a junior CEO or a junior CIO, there should be no junior Scrum Masters. While someone may be new to the role, they should have a proven track record of skills and competencies that qualify them for this position.
To illustrate this point, consider the analogy of a gunnery sergeant in the military. There is no junior gunnery sergeant; rather, individuals are promoted through the ranks based on their demonstrated skills and expertise. They may be new to the specific role of gunnery sergeant, but they bring with them a wealth of knowledge and experience that is crucial for success.
Building Competence
For those aspiring to become Scrum Masters, my advice is straightforward: gain experience within a relevant context. For instance, I once spoke with someone from an accounting background who wanted to transition into a Scrum Master role. I encouraged them to immerse themselves in a team within their field, leveraging their existing knowledge to help that team excel.
Learn the Processes: By working closely with the team, they could learn the specific processes and practices that are effective in that context. This hands-on experience is invaluable.
Demonstrate Competence: As they contribute to the team’s success, they will naturally build their reputation as a knowledgeable and capable Scrum Master. When the team begins to look to them for guidance, they will have effectively stepped into the role.
Conclusion
In conclusion, the idea of a junior Scrum Master is a misconception that can hinder both individual growth and team effectiveness. The role requires a blend of technical knowledge, system understanding, and the ability to navigate complex organisational dynamics. If you’re considering a path to becoming a Scrum Master, focus on building your skills within a relevant context, and remember that true competence takes time and experience. There may be new Scrum Masters, but there is no such thing as a junior Scrum Master. Embrace the journey, and you’ll find yourself well-equipped to lead your team to success.
So there’s no such thing as a junior Scrum Master. I wrote this post because I see and continuously see a lot of multiple things. I see a lot of organisations thinking that the Scrum Master can be or teams thinking that the Scrum Master can be anyone in the team and going, “Well, they’re just facilitating a few meetings, so we will just pick who’s the least productive on our team.” Okay, it’s this junior person. “We’ll pick them as the Scrum Master. You go do this stuff.” And that does that person and themselves a complete disservice. Let’s tackle that one first, right? So that’s the first part of why I wrote it.
The other part is on the Scrum Master side. There is a belief in the industry that if you want to get into it, then a good way to do it is to come in through the Scrum Master because you don’t need to do anything technical. And that, for want of a better expression, is total BS. You do need to be technical within the context of the team. Just like if you wanted to coach a professional soccer team—you’re probably, football in my words—you’re probably going to want to understand the rules of the sport. You’re probably going to want to understand the nuance of not just the sport itself, the league tables, how you move between the leagues, right? The mechanics and the mechanisms of not just the sport but the leagues and how do you navigate your team through that story. How good do the individuals need to be? How well do they need to work together? How do they thread that needle of becoming a high-performing team in that league? And perhaps going to the next league if you can. And maybe you don’t want to go to the next league, so maybe you deliberately need to lose a game, right? Because you don’t want to be pegged high and have to go to the next league, and then you’d be the bottom of that league rather than the top of this one.
All that kind of stuff—the understanding of what we’re doing, how we’re doing it, why we’re doing it, and how we’re going to get to where we’re going from a strategy perspective—that’s not the in Scrum’s perspective, in the perspective of a Scrum team. The product owner is going to take care of the what. I’m pushing it off to the product owner. The whole Scrum team takes care of the how, but the product owner has the accountability. We’ve got this what that we’re looking at, but we’ve also got the system that we’re using, and that system needs to be as effective as possible. So no matter what comes through the system, we’re able to deliver them as quickly as possible.
The system coach, the person who is most focused on the system itself and encouraging people to reflect on the system itself and figuring out how the system itself needs to change in order to maintain that, and how the systems around that system need to change. So that could be things in the organisation or things in other teams that would enable us to be more effective if they changed. But is that good for the overall system or just a local optimisation, which might be good for us but negative for the rest of the system? How do we fit into that whole story? That’s not a junior who figures that out, right? That’s somebody with deep knowledge and understanding of the type of work that the team does.
So in my case, that’s usually engineering teams. They have deep technical knowledge in the type of work that the product owner does, so the context of the business, right? Because the system has to operate inside of a bigger system. The system of the team has to operate inside of a bigger system that is the whole organisation. So understanding the systems of the organisation and how we navigate that. And then they also need to understand the things that we see most, which are the tools and practices around how do we actually do those things.
So I think too many people look at the outcome and look at the tools people used to get to the outcome, and they focus on the tools, but they don’t focus on how did we pick that tool? How do we get to that tool? And does that tool continue to support our needs over time? And that’s the purview of the Scrum Master. They are a system mechanic. They’re a mechanic for the system. And if you’re going to be a mechanic for a system, you want to understand the systems. And that system is made up of the way the team works, the capabilities of the team, the knowledge of the team. It’s made up of the knowledge of the product owner and what they’re picking and what direction they’re going, and that informs what knowledge the team might need in the future.
And we’re looking at the organisation and what the organisation understands about the system, what the organisation’s system is. It’s just such a big ball of worms that you need somebody with significant expertise, significant history to be able to do that. So that’s why I use the phrase, “There’s no such thing as a junior Scrum Master.” There is no such thing as a junior Scrum Master, just the same as there’s no such thing as a junior CEO or a junior CIO. There might be somebody who’s new to that role, but how did they get in that role? They were selected. They were picked for their demonstrated skill and ability already. They didn’t arrive fully formed, right? That’s a little bit of a misnomer.
I think a good example is that idea of a gunnery sergeant in the military, right? There’s no such thing as a junior gunnery sergeant. You have a person who demonstrates skill at different levels and is promoted through the ranks, right? And then they get to that. They’re now a gunnery sergeant. They may be new to the role of gunnery sergeant and have to learn things about that role, but they bring with them significant skill and expertise in what we’re doing already. You’re not going to make gunnery sergeant if you don’t understand the organisational structure, if you don’t understand not just the hierarchy but also that network of how you actually get things done inside of the context of the organisational structure.
So there really is no such thing as a junior Scrum Master. There should be no route to Scrum Master for somebody who doesn’t have any skills within the context of the team because they’re going to do the team and the organisation a disservice. They’re not competent within that context. So my advice for people—I’ll use a concrete example. I had somebody set up a meeting to have a chat about becoming a Scrum Master, and they worked in accountancy. They worked for an accounting firm, and they wanted to get into the idea of the Scrum Master that they’d heard about. My advice to them was to find a team or a group inside of the world of accountancy, right? So you already know the context. Hopefully, you have some skills in that context. And make them try. Work while you’re doing the work with the team to enable them to be the best team anybody’s ever seen within that context.
And by pursuing that goal, you learn the processes and practices that are required within that context of an account team doing accounts. What are the actual processes? What are the systems that make sense within that context? How do I educate the people on that team and in that group and the wider organisation on those practices and convince people? And that will build your skill, and eventually, the people in your team and the people in the organisation will look to you for those things because you have demonstrated competence in them. If they’re looking to you for those things, you are the Scrum Master, right? You are the coach. You are that person. And you arrived at it almost—you became it fully formed because you’ve demonstrated that capability. But it took a long time to learn the things you needed to go over that line and become that thing. And then yes, you’re a new Scrum Master, but there’s no such thing as a junior Scrum Master.
