 the Scrum Master in a nutshell. The Scrum Master role has been around for over 20 years now, but there is still confusion about what it actually is. So in homage to Henrik Nieberg, who created his product owner in a nutshell video, I thought I would create a similar explanation of a Scrum Master in a nutshell. Now, the first thing to bear in mind about a Scrum Master is that they are an enabler, not a doer. They're there to help the people who are doing the work do their work to the best of their ability. They're not there to do the work themselves. So in short, I see the role as bringing together the people who want something, our customers, our users, and the people who are going to build or provide that thing, the developers. And there are actually two very different sides to the Scrum Master role. There's a mechanical side and there's a cultural side. Now, we're going to focus on the mechanical side first because on the surface, the Scrum Master is there ultimately to ensure that the team and the organization use Scrum to build valuable products well. They're going to ensure that the Scrum events happen effectively, efficiently. The Scrum artifacts are created and used and maintained effectively, and that the inspector at that point within the Scrum framework had taken advantage of. Like I said, we'll come back to the cultural side in a minute, but for now, let's just look at the mechanical side of doing Scrum. All right. In short, the Scrum Master's basic aim is to facilitate the Scrum framework for the benefit of the Scrum team and the wider organization. And Scrum, as you probably know, is a way of working where a self-managing cross-functional team works directly with customers or customer representatives to deliver value in short iterations and then learn how to make both the product that they're building and the process that they're using to build the product better every couple of weeks. And this Scrum framework is made up of a number of elements and the Scrum Master is in some way involved in all of them. And the first element we're gonna start with is the product goal. And the purpose of the product, the product goal, is ultimately the responsibility of the product owner. But product owners are very, very busy and we all suffer from short-term thinking at times and we've all got cognitive biases. So the Scrum Master is gonna help the product owner ensure that the product goal is there, that it's good, that it's clear, that it's well understood, that it's engaging and it remains relevant over the course of the product development effort. Because the product goal is what sets our overall ambition for the product development effort. It's really important in enabling the self-management of the team and setting goals for outcomes rather than outputs. The product backlog is another aspect of Scrum. But really, really simply, it's a prioritized and ordered list of what our customers, our users need. And they are going to help us achieve our product goal. And just like the product goal, the product backlog is ultimately the responsibility of the product owner. But it's very easy for this artifact to very quickly become unwieldy, to become bloated. So the Scrum Master is going to help the product owner. They're gonna help them by making sure it's available, by making sure that it's well maintained, that it's ready to be worked on, that the items are understood enough to be able to get started with, that it's small enough to fit into iterations and so on. And the first time we're really going to make use of the product backlog in anger is the sprint planning meeting. And every sprint starts with a sprint planning meeting. And this is where the Scrum Master is going to bring the product owner, the developers, perhaps other stakeholders together for a couple of hours to work out what increment is possible in this iteration, in this sprint. Together, we're all going to plan, as well as we can, with the limited and unknown information that we have, the next sprint. And the Scrum Master's main job is to do a little bit of preparation, structure it, and then facilitate it. They're gonna respond to the interactions in the meeting to help those stakeholders, to help the product owner, to help the developers come up with an achievable and valuable sprint goal. And then we've got our sprint, which is basically just a fixed amount of time. It's usually one to four weeks. And in this fixed amount of time, that Scrum team is going to work every working day of the sprint towards the sprint goal by turning product backlog items into valuable deliveries. Valuable deliveries that our product owner and our customers and users will find valuable. Now, in an ideal world, that would be that, but most Scrum teams operate in a complex environment with unknown unknowns and challenges. So every now and again, that team's gonna come up against impediments. Now, an impediment is anything that stops that team from being productive, from being effective. And the Scrum Master's responsible for getting those impediments removed. Don't have to necessarily remove them themselves, but making sure that the team is able to carry on with their development, to carry on with the work of delivering valuable functionality. And so there's a lot of coaching that the Scrum Master will do to help that Scrum team carry on doing their thing and delivering great product backlog items. Another part of the Scrum framework that the Scrum Master will help out in is the Daily Scrum. And this is an interesting one, not least because I get asked how often should we have a Daily Scrum? And there's a clue in the name. Every day during the sprint, the Scrum team is going to check in with each other. And they're gonna be checking in to inspect and adapt the progress that they're making. As a self-managing Scrum team, against the sprint goal, they're gonna make or remake their plan for the day ahead based on the knowledge they have now, not the knowledge they had at the sprint planning meeting, but the knowledge they have now. Remember, it's a self-managing unit and they're going to do whatever they need to do in order to deliver. So the Scrum Master isn't there to manage this team. They're not there to check up on this team. All they're doing is they're there to ensure that the Scrum team is able to do what they need to do. They're capable of managing itself. And well, yeah, this is a great opportunity for Scrum Master to find out what impediments the team are facing that they might need some help with. But ultimately, it's there to make sure that the Scrum team are able to check in in this complex environment to either stay on track or get themselves back on track. Another aspect of Scrum that's emerged over the years is what's become known as product backlog refinement. Now, what product backlog refinement is is the Scrum team taking a little bit of time out of delivering this Sprint's goal to just look forward and prepare a bit for the next Sprint planning meeting. Now, they're only looking at the highest priority items on the product backlog and it's only a short amount of time because ultimately, the stuff that's in this Sprint is by definition more valuable and more important to get done than the preparation of the next Sprint's work. But the Scrum Master will see there being some value in having a little bit of preparation for the next Sprint planning session so that it's able to go smoothly. There aren't significantly unanswered questions that will slow down or impede the ability to plan the next Sprint. So the Scrum Master's role here really, yes, it's largely facilitatory from a mechanical point of view, but ultimately, they're there to help the product owner and the developers spend just enough time discussing just the right things so that the next Sprint planning meeting can run smoothly while not taking too much attention away from delivering on this Sprint goal. And then at the end of the Sprint, we've got a couple of events. The first one being the Sprint review meeting. Now, this is where the Scrum team gets to demonstrate, tangibly demonstrate the progress they've made. They get to share the tangible results of their work with an audience of effectively anyone who's interested in what the team have been working on. And this is the point where the Scrum team can inspect and adapt the work, the increment, the plan, and they can reflect on the consequences for the direction of the product, just on what they've actually built or not built, but also what they've learned. Now, the Scrum Master's gonna do a bit of preparation for this event. They're gonna ensure that the right people are there, that it's run effectively and wherever possible efficiently. And that the learning we get from this is built into the product goal, the product backlog, the Sprint coming up. And then we've got the Sprint retrospective meeting, the other event that takes place at the end of every Sprint. And this is where the Scrum team take a little bit of time out to reflect not so much on what they've built, that happens in the Sprint review meeting, but more on how they built it. So the point here is for the Scrum team to inspect and adapt their ways of working. And again, the Scrum Master is going to take a largely facilitatory and coaching role here. They're gonna ensure it happens, that it happens well. So they'll prepare for it, they'll set it up to maximize reflection, to maximize learning. And then they're gonna ensure that the improvements to the ways of working are built in to the team's process and taken forward. Now, after all of that, if the product owner decides they want to continue with this product development effort, there'll be another Sprint planning meeting, and the cycle repeats itself. But that's just the mechanical side of being a Scrum Master. I mentioned there's a cultural side of the Scrum Master as well. And a good Scrum Master can fulfill the mechanical nature of their role relatively easily, just by ensuring that the Scrum framework's followed, that they tackle impediments to the productivity of the Scrum team. But the real value that a Scrum Master adds is how they go about doing that. And that's where the cultural side of the role comes into play. Because, and listen carefully here, the Scrum Master exists in order to not exist. Their aim is to do themselves out of a job. And they do that by helping to embody the values of agile and Scrum into the culture of the Scrum team and the wider organization. Essentially, a great Scrum Master uses Scrum to get the team and the organization past the need for Scrum. A great Scrum Master builds up the self-management of the Scrum team and the effectiveness of the surrounding organization so that Scrum Masters aren't actually needed in the future. So when they're facilitating events, when they're removing impediments, they're always conscious that they aren't creating a dependency upon themselves as a facilitator, as an impediment remover. Scrum Masters are always looking at ways to help teams become able to solve their own problems, rather than being the person that teams come to as a problem solver. That's a subtle but really important distinction. Now I see the Scrum Master as something of a servant leader. Now you might have heard that term before, if not you'll probably hear it again the more involved in Scrum teams you become. Now the term itself came from a guy called Robert Greenleaf many years ago and he suggested that the purpose of a servant leader isn't to create more followers, but to create new servant leaders by helping them grow as people. He created this ultimate test of servant leadership which was to ask, do those people being served become healthier, wiser, freer, more autonomous and more likely themselves to become servants? And I think great Scrum Masters guiding Scrum teams and organisations past the need for Scrum fits that test. Now it takes time, so you've got to be patient. There's going to be a number of bumps along the road, lots of learning along the way and great Scrum Masters will always assess the context because they're looking for a balance between effectiveness now and the long-term maturity and growth of the team and the organisation. Now I mention this because unfortunately in my experience a lot of organisations just focus on the mechanical side of Scrum Masters. But at the Agile Mastery Institute we focus our time on creating great Scrum Masters, great product owners, great Agile teams who are all focused on being Agile and embodying the values and principles of Agile and Scrum not just mastering the mechanical aspects of the role.