6. The Scrum Master Advanced – Part 2
Next, a manager. A quick reminder from PSM One The Scrum Master oversees the implementation of Scrum. But the scribe doesn’t manage the people. This includes assigning tasks, managing budgets, and so on. He or she does not have the formal authority to conceal fire or theft, raise salaries, or promote someone. So the Scrum Master is not a traditional manager, but the Scrum Master manages impediments. Eliminates waste.
By the way, eliminating waste is a lean principle. The latest change in the Scrum Guide says that, besides empirics, Scrum is founded on lean thinking. I hope you remember that management is distributed among all members of the Scrum team. For example, the product owner manages the product backlog, the product goals, and the product vision. The developers manage their own work. Nobody tells them how to turn work into increments of value.
The scrum master, as I said, manages the process. So management is there, but it is not vertical; it is horizontal. Next, impediment removal. I pointed your attention to the change in the Scrum Guide: now the Scrum Master causes the removal of impediments to the team’s progress. But in previous versions of the Scrum Guide, it was stated that the Scrum Master removes impediments to the developer’s progress. And then I got feedback from students. Asking Vladimir, does that mean the Scrum Master doesn’t remove impediments anymore? Perhaps it is as simple as identifying the impediments. And this is a good question I would like to address. The scrum master still removes impediments. The Scrum Master is still regarded as an obstacle remover.
But here is the important part: removing impediments should not get in the way of self-management. That is, if the developers can solve the problem, the Scrum Master should respect that and refrain from interfering. But sometimes impediments go beyond the organisational capabilities of the team. Remember, this is my favourite definition for thinking on an organisational level. This is where the scribe steps in. What can be done? The scrum master may create a list of all obstacles that prevent the team from working optimally. And then the scrum master may show up and discuss that list with the respective people outside the scrum team. Most of the time, these are different types of managers. Think of middle management, but not only CEOs as well.
So what did we do here? We made the impediments transparent to everyone. As you can see, this goes back to empiricism and increased transparency, so the decisions we make are not flawed. Finally, a catalyst for change In his book Scrum Mastery from Good to Great: Servant Leadership for Agile Teams, the author writes that a good Scrum master helps a Scrum team survive in an organization’s culture. A great scrum master assists in changing the culture so that scrum teams can drive. From my perspective, this is one of the hardest things Scrum Masters should be able to do. Scrum teams do not work in isolation. You already know that by now.
But Scrum teams work within organisations with established cultures, and quite often the organisational culture does not support Agile and Scrum principles and philosophy. A quick example: imagine an organisation transitioning from traditional management to Agile. In traditional management, you do not have self-managing teams. You have project managers who assign tasks. They ask for reports, they set deadlines, and they do estimations. Generally, they practice micromanagement. So this is a way of working. It is a culture that doesn’t support agile and Scrum principles. A great Scrum master acts as a change agent so that the Scrum team can reach high performance in combination with the other stances. For example, as a teacher and coach, the Scrum actor initiates changes in the organisational culture, helps the managers understand how empiricism works, and explains the benefits of self-management. One of my favourite quotes by Gunter is that teams require autonomy to achieve exobus, introduce the concept of feature teams, cross functionality, and so on and so forth. Again, this is extremely tough, especially in rigid organizations. They’ve heard about Agile and Scrum.
They want to give it a try, but they do not do it fully. They do not follow the principles. And if a project fails, some people might say, “Scrum, yeah, that doesn’t work.” We’ve tried it, and it failed. Let’s go back to the waterfall approach. All right. These are the stances of a scrum master. I hope now you have a better understanding. And I know it might sound overwhelming, which it is. One might think, “How is all of that supposed to be done by one person acting as a mentor with a lot of experience?” Teacher, coach, change agent, and so on. And my answer is this: I’m not an expert in those houses, but I will tell you how I do it. I’ll tell you my approach and my secret. I do it one step at a time. I understand that this is a journey, and I understand that if you want to develop individuals and teams, you have to develop yourself first. So this is why I’d like to take a moment to congratulate you, because this is what you’re doing right now. You’re going to the next level, and my primary goal is to help you get there. I’m not saying it is going to be easy, but I believe we can succeed. All right, we’ve come to the action item. First, read The Eight Stances of a Scrum Master by Barry Wolverine. You have already read the bad stances.
Now focus on the good ones. One quick note As of recording this video, the paper has not been updated to match the changes from the latest version of the Strum guide. Do not worry about that. Focus on the stances instead of the words “development team” versus “developers.” Hopefully, Barry will update the paper to match the changes. Second, there is an article I like very much. It is called a synchro master, facilitator, or enabler. It is a short article written several years ago, but it captures the facilitator’s stance quite well. Please do not skip these action items because I explain here my personal views based on what will help you on the PSM II exam. The paper will broaden your understanding of the stances. Now, I would like to do a quick recap. Servant leadership is the backbone of the scrum master. Depending on the context, the Scrum Master should act as a facilitator to facilitate events when requested or needed, resolve conflicts, or handle other situations without taking sides. A Scrum Master does not accept or reject decisions taken by the Scrum team. Teacher, you teach the members of the Scrum team and the organisation how Scrum works and the rules of the game. Mentor, you have a lot of knowledge and experience, and you guided the team in the right direction.
Once again, you want to bring out the best in people and achieve high performance. Coach, you are holding the mirror and helping individuals, teams, and organisations see any blind spots and make decisions themselves. Manager, you manage the Scrum process’s obstacles, not the people. The Scrum Master does not have the formal power to fire or hire people. You don’t assign tasks and micromanage. You protect the Scrum team from managers who want to micromanage obstacles. By removing impediments, you go beyond the self-management capabilities of the team. If the team can solve the obstacle themselves, you do nothing. Change agents, you are a catalyst for change. You initiate changes in the organisation so your team can thrive. You do that by applying other stances, like teaching and coaching. These are the most important points. Feel free to watch the videos several times, or at least the recaps, because these mindsets will help you answer questions from the exam, but they will also help you in your practise as a Scrum Master. In the next video, we will do a general recap. After that, we will talk about how the Scrum Master serves the organization, the product owner, and the scrum. Thank you for keeping an eye on the situation in the state, Partners for .
7. Recap #1
Let’s do a general recap of the last four videos, starting with empiricism. The scrum master supports and promotes empiricism. When analyzing PSM, consider two questions: how does this support empiricism? Look for the three pillars as keywords in the answers: transparency, inspection, and adaptation. The entire Scrum team supports empiricism. For empiricism to work, we need clear goals—the sprint goal and the product goal. The scrum master ensures transparency. With no transparency, the chance of making wrong decisions increases. Kaizen is the Japanese word for improvement. Next. The scrum values Scrum values drive behaviors.
The developers commit to the spring goal. They do not commit to the Sprint backlog or individual PPIs. Scrum teams must adhere to the Scrum values in order to achieve excellence. They also need an environment of trust. Then there are the bad stances of a scrum master. The Scrum Master should avoid the following behaviors. Scribe’s primary responsibility is to take notes during Scrum events. The secretary’s primary responsibility is booking rooms and dealing with schedules. Scrum police follow the Scrum guide word for word, without empathy or any consideration of the context. The team boss is using command and control leadership instead of servant leadership. The administrator’s primary responsibility is fixing any issues with tools. For example, Jira for issue tracking the Chairman The developers report progress to the scrum master during the daily scrum. The superhero. The scrum master resolves all obstacles.
This hurts self-management. The coffee clerk’s primary responsibility is getting coffee. The good stances of a Scrum Master are next. Servant leadership is the backbone of the scrum master. Depending on the context, the scrum master should act as a facilitator. You facilitate events when requested or needed, conflicts, and other situations without choosing sites. A Scrum Master does not accept or reject decisions taken by the Scrum team. Teacher, you teach the members of the team and the organisation how Scrum works and the rules of the game. Mentor, you have a lot of knowledge and experience, and you guide the team in the right direction. Once again, you want to bring out the best in people and achieve high performance. Coach, you’re holding the mirror and helping individuals, teams, and organisations see any blind spots and make decisions themselves. Manager, you manage the Scrum process and impediments. You do not manage people. The Scrum Master does not have the formal power to fire or hire people.
You don’t assign tasks and micromanage. You protect the Scrum team from managers who want to micromanage obstacles. By removing impediments, you go beyond the self-management capabilities of the team. If the team can solve the impediment, you do nothing. Change agent, you are a catalyst for change. You initiate changes in the organisation so your team can thrive. You do this by applying other stances, like teaching and coaching. Congratulations on getting this far! Thank you for your patience, and please stay focused.
8. The Scrum Master Serves The Organization
In this video, I want to focus on service to the organization and direct your attention to a few key concepts. I want to go beyond the Scrum Guide. First of all, scrum masters want to create environments where scrum teams can thrive. From previous videos, you’ve learned that this has to do with organizational culture and management style. The more traditionally oriented the organization, the harder it is for the Scrum team to perform. This is also an excellent opportunity for the scrum master to use change agent styles.
But in reality, change is hard—not only in management but in anything. For that reason, the scrum master has to build good relations with people outside the scrum team. For example, project managers, portfolio managers, line managers, programme managers, CEOs, CTOs, people from different departments, sales and marketing, HR, and so on and so forth. To make it simple, the people involved with the product—which Scrum calls stakeholders—generalize. I was doing practice exams, and I saw one question about the project manager asking for a report expressing a concern or something similar. And one of the options that people thought was correct was to ignore the request. There are no project managers in Scro.
Now, let me ask you, how does this sound to you? Of course, it is not the correct option. Yes, Scrum does not have a role-based accountability project manager, but this doesn’t mean project managers do not exist. So we cannot ignore requests like that. Why am I saying this? On your exam, you may see many roles approaching and working with the Scrum team because of the self-managing nature of the Scrum team. Generally, project managers are not happy. How are they going to manage? When is the team self-managing? Project managers believe they will be laid off. They are no longer needed. How do you expect them to like Scrum? The discussion has been going on for a while, and the people behind Scrum have a position on it. and it is simple. Despite the self-organizing nature of Scrum teams, project managers can still add value and contribute to the success of the product.
However, working with the Scrum team requires a different approach, one that respects and supports empiricism, the Scrum framework in general and its accountabilities, and also self-management. Now, let me give you a few examples of what project managers might do to help the Scrum team. First, remove impediments. Second, they can help coordinate with stakeholders. Third, increase business agility and focus on the right metrics. Instead of velocity, they might focus on business value, customer happiness, time to market, and so on. By the way, you can find many useful metrics in the Evidence-Based Management guide. What I’m seeing here is just to give you an idea; the best way to change an organizational culture depends entirely on the context.
There is no one-size-fits-all solution for all organizations. So as a scrum master, Sometimes you will have to help stakeholders. Middle management, for example, understands the benefits of scrum and agile. Now, in the video about empiricism, I briefly mentioned that sometimes stakeholders might be unhappy with the results. Aside from the reasons for this, you may be tested on the best way to proceed. One reason for happiness might be that the work takes more sprints than expected. For example, the strong team estimated five sprints, but they only did one, or, let’s say, two or three sprints. And now they have more data to say that it will take seven or eight sprints to release the product in the desired state instead of five sprints. Each sprint comes with a cost to execute, as you know. So management is not happy. Other times, the issue is more about meeting a deadline.
The product is important. Everyone knows it will be released on a certain date. But unfortunately, the scrum team cannot deliver. So management is not happy. Be careful with such questions and eliminate the absurd answers first. What do we mean? For example, what if the team cannot meet a deadline? Hiring developers to work overtime is never a solution. This is against one of the agile principles. Agile processes promote sustainable development. The sponsors, developers, and end users should be able to maintain a constant pace indefinitely. The keyword here is “constant pace.” Another absurd answer might be extending the duration of one sprint for whatever reason—meeting a deadline, completing a forecast, and so on. We do not do that. We want consistency and regularity. By the way, I will explain the consequences of extending a sprint in the lecture about timeboxing. Sometimes, by removing the absurd answers, you will be left with only one option, the correct one. Other times, you will be left with two options.
Analyze them and choose the one that fits best. Scrum and an Agile Mindset Let’s do a recap. Great scrum masters create environments where scrum teams can thrive. They lead, train, and coach the organisation in its Chrome adoption. By applying the change agent stance, the Scrum Master may initiate changes in the organisational culture or at least increase transparency. Managers can add tremendous value by supporting empiricism, self-management, the scrum framework, and its accountabilities. Great scrum masters build good relationships not only with the members of the scrum team but also with other people in the organization. In the next video, we will see how the scrum master serves the product owner. Thank you for your patience, and please stay focused.
9. The Scrum Master Serves The Product Owner
We know that the scrum master serves the product owner. However, to do that efficiently, you need to have a very good understanding of the accountabilities of the product owner. Hopefully, you’ve watched the two lectures about the product owner. But in this video, I want to focus your attention on a few more things in regards to serving the product owner. Owner. First of all, you should never assume that the product owner is proficient at what they do. You might be presented with situations where the product owner is new to the scrum team and doesn’t have previous experience with scrum. So you’d need to coach the product owner from the ground up, starting with the basics: ordering the product backlog, maximizing value, frequent collaboration with stakeholders, creating and communicating product goals, a product vision, and, of course, respecting self-management, avoiding micromanagement, and encouraging empiricism.
Let’s take a closer look. Let us pretend that I am the product owner and you are the scrum baster. I’ve been assigned to the scrum team, and I have two years of experience working as a project manager in an organization using the plan-driven approach to development, or as we call it, “waterfall.” I understand the concept of a product backlog, but I would definitely need assistance managing it; then, as a Scrum Master, you take the appropriate stances as a teacher and coach and educate me on product backlog management. But you do not order the product backlog, just to show me how it’s done. You do not do that.
Where do the PBIS that would maximise the value the product delivers go? They go on top. Why? Because the developers select items from there, you tell me that collaborating with stakeholders and getting feedback from them is critically important to the success of the product. Usually, the product owner orders the backlog based on assumptions. The product owner thinks that these PBIs would bring the most value. But to validate that assumption and these assumptions, we need to release the increment. The key word here is “released,” because this is when we deliver value and this is when we receive feedback from the marketplace. Based on that feedback, the product owner and the stakeholders collaborate on what would be the next best thing to do. The result is a revised product backlog. So we are talking about empiricism next. You taught me that the product backlog has to be in good shape.
You implement backlog refinement for products. I need to collaborate with the developers to break items down and add estimates. I don’t do that. The developers do it. Add details, for example, descriptions, acceptance criteria, and so on. You need to teach me the power of asking why. Why are we doing this? Why do we need to develop this feature? Why are we making the product in the first place? Such questions help the product owner craft a product vision. This is the true north. This is the destination we call success. As a product owner, I keep this vision in mind. There is a backlog when I order the product. I’m asking myself, “What is the best thing to do now that will help us get closer to that vision?” Equally important, I need to communicate that vision to the scrum team. not just to the scrum team but also to stakeholders. Next, since I have experience as a project manager, I might act as a traditional project manager, which interferes with the self-management capability of the scrum team.
For example, I might attend every daily scrum to request status updates, even though the scrum events are not designed to provide status updates. The scrum events are designed with the purpose of looking forward. What are we going to do next? So you have to teach me the purpose. You have to teach me what the purpose of defence is. I might have the temptation to assign tasks to the developers and closely monitor their progress. This is not how it works in scrum. The developers assign tasks to themselves, and they monitor their own progress. In other words, I, as a product owner, should focus on the why and what has to be built, and let the developers focus on the how. I’m talking about all aspects here, not just assigning tasks. The developers know best how to turn PBIS into incremental value. But for me to be good at answering the question “why,” I need to be constantly looking for feedback.
For that reason, the product owner has to collaborate closely with the key stakeholders. Yes, I’ve mentioned this several times already. But you know what happens when they receive no feedback? the impact that has on empiricism. But communication is also important on a team level. The product owner should answer questions the developers have. But that’s interesting. How much time should the product owner spend with the developers? It’s an interesting question. The scrum guide doesn’t tell us that. We do not have a rule about that. But if you see a similar question, you must think of an answer that has to do with the word “enough.” It is not 10%, but it is; it is not 100%, but it is not. Whatever the developers decide, the product owner spends enough time with the developers so that he or she is not surprised at the end of the sprint with the result. with the increment. There may be times when I need your assistance. What would be the best thing to do in a particular situation? And here I want to say two things when you analyse situations like this: First, among the given answers, look for those that do not break scrum rules.
For example, pauses between sprints, different types of sprints, such as sprint zero and technical sprints, and so on. And second, think of the scrum team as a unit that has all the skills and accountability needed to make product decisions. Now, why am I bringing this up? Some of the latest changes in the scrum guide relate to removing the US versus them mentality. Product owners versus developers chromeMaster vs. product owner When the product owner is faced with a difficult situation, instead of thinking about a solution all by himself or herself, why don’t they bring the problem to the entire Scrum team? We are a team. We have common goals. We collaborate and support each other. All right, this is what I wanted to share with you. a broader perspective than what’s written in the Scrum Guide. There is no action item for this video. Just a quick recap. The scrum master serves the product owner. If necessary. The scrum master helps the product owner define and communicate the product goal and vision. Ordering and maintaining the product backlog while focusing on value delivery and return on investment ROI facilitating stakeholder collaboration, supporting empiricism, and frequently seeking feedback. respecting management and avoiding micromanagement. Identifying agile metrics to measure value As a service leader, the scrum master helps all members of the team grow, including the product owner. In the next video, we will see how the Scrum Master serves the Scrum team. Thank you for your patience, and please stay focused.
10. The Scrum Master Serves The Scrum Team
By now, you have a pretty good idea of how the scrum master serves the scrum team. But let’s add a bit more detail. Scrum teams evolve. It takes time, and the team undergoes change, before reaching peak performance. As a scrum master, you play an active role in this process, starting with the two basic characteristics of self-management and cross-functionality. Up until this point, we have been discussing how people outside the scrum team should respect self-management. The self-management capability of the scrum team The product owner should do that as well. All good. But in reality, there might be developers who are not familiar with this concept.
They expect someone to constantly tell them what to work on and how to do it, to assign tasks to them, and so on. Again, concepts from the traditional management paradigm. What do you do? In this case, it is simple. You teach the team how to manage themselves. Next, to develop a high-performing scrum team, you need to make sure that all members are aware of the two fundamentals of scrum. Number one: creating a done increment every sprint. And number two is setting clear goals. Sprint goals and product goals By the way, the two lectures that follow this one are all about these two principles. I’ll give you details and situations to consider. Next, if necessary, you need to facilitate the Scream events and coach the team on what the purposes of the events are. Underline the importance of time boxing and explain what happens when the team skips events. Or if members do not participate, explain how that affects empiricism. Opportunities to inspect and adapt are lost. Effective scrum teams make the most of scrum events. Looking forward. Remember: receive feedback, adapt.
Receive feedback, adapt. Continuous learning. Continuous improvement. And this brings me to the next point. If at all possible, release quickly. Why? Because in this way, you reduce risk. You, as a scrum team, validate assumptions faster, add value, and get feedback from the marketplace. And you might be wondering what kind of risk I’m talking about. Let me give you a few points. The product owner and the stakeholders think that a set of features would be great for the end users. The scrum team works on these features for a few sprints and doesn’t release them. The stakeholders are coming up with more great, cool ideas. Before the release, let’s add a little bit more. Added a few more features You do that, you make a major release after that, and you see that this is not what the end users wanted.
You can look at metrics like the customer usage index. This will tell you which features end users are using the most and the least. That’s basically what happened. The team has generated costs for the organization. Maybe the ROI return on investment is negative only because we haven’t sought feedback from the marketplace. Again, if at all possible, release quickly. I say if possible, because releasing is not always easy. There are many considerations. For example, will the new release restrict current users in some way? Can the end users deal with the frequency of the releases? Do they need training after a release? Are there any regulations? Next, the scrum master identifies and removes obstacles to the team’s progress. One of the good stances of the Scrumaster impediment remover We’ve already talked about that. Probably. This is one of the first things people learn when they are introduced to Scrum. But when you dig deeper, you see that you need to consider self-management. If the team can solve it, you let them. The scrum master should not remove every obstacle to the developer’s progress. Remember the bad-stance superhero? Yes. Help them teach, Coach. But let them come up with a solution.
Whenever this is possible, let them own the solution. Let’s do a recap. The scrum master serves the scrum team if necessary. The Scrum Master helps the Scrum team by coaching them in self-management and cross-functionality. Helping the team create dumb increments Ever Sprint explained the importance of clear goals. Sprint-level spring goals; product-level product goals Identifying and removing impediments to the team’s progress while respecting self-management teaching what the purpose of the Scrum events is. ensuring the events are productive and kept within the timebox. Creating an environment of trust by leading by example and being a true leader Remember, absence of trust is the first dysfunction out of the five identified by Patrick Lancioni. Creating a learning environment where the scrum team can experiment underlines the importance of seeking feedback and collaborating with stakeholders. encouraging the team to release quickly when it is possible and appropriate. In the next video, we will do a general recap, and after that, we will talk about the first fundamental Scrum principle: creating Dun Increments. Every sprint. Thank you for your patience, and please stay focused.
