11. Recap #2
Next, a manager. A quick reminder from PSM One The Scrum Master oversees the implementation of Scrum. But the scrum master 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 obstacles. 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. Then comes the impediment remover. 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 scrum master 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 obstacles 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. Quite often, the organisational culture does not support agile and Scrum principles in 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 practise 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 Scrumactor initiates changes in the organisational culture, helps the managers understand how empiricism works, and explains the benefits of self-management. “Autonomy is required to achieve excellence,” says Gunter Team in one of my favourite quotes. Introduce the concepts 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. I know it might sound overwhelming, and 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 Override. You’ve 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 synchromaster, 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, 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 and impediments. You do not manage 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 things in state.
12. Fundamental Scrum Principle #1
In the PSM section of the course, you’ve already watched a video about their definition of them.
So consider this one an extension, or as I like to call it, a deep dive. I do not want to emphasize the importance of my videos because they are all going to help you analyse situations on your exam. But please pay special attention to this one. Let’s get down to work. One of the fundamental principles in Scrum is to create a done increment. Each sprint done means that the work meets the definition of “done,” and the increment can be released at any time. Testing is also included, so no more work is pending. Consider purchasing an ice cream cone. The work on the product is done. You buy it, and you can consume it immediately.
You do not wait for milk, sugar, or artificial colors to be added before you eat it? No. And this is a fundamental rule in Scrum: at least one done increment per sprint, not yet released but done. We can release as many times as we want during the sprint. There are no rules about that. Or we can release the sum of the increments from the past few or several sprints. No problem. While we are on the topic of releasing, I want to clarify a few things. In previous versions of the Scrum Guide, the product owner was accountable for releasing the increment. This is not the case anymore. Now the Scrum team makes the release decision, but it can also come from other places. I’ll give you an example in a second. The product owner still plays an important role. He or she wants to make sure that the value does not get out of line with the marketplace.
But as you can see, details about releases are removed from the Scrum Guide. And how do I know what I’m sharing with you is true? First, I asked many professional Scrum trainers, but I got different answers, and I was not satisfied. Then I posted in the Scrum forum. I got logical answers, but some of them were not true at all. Once again, I was not satisfied. And lastly, I wrote an email to scrum.org. directly, who decides when to release the increment? And the answer I got was to focus on the definition of dumb. Now the Scrum team decides when to release. But sometimes there might be regulatory factors that influence the release decision. They gave me an example of pharmaceutical companies that create medicines. The final release decision comes from the FDA. This is the Food and Drug Administration. It is a federal agency in the United States. The whole idea of the Scrum Guide is to be less prescriptive. Finally, I got a satisfactory answer. I was quite adamant about that, because I knew that my students would rely on me to present the most accurate information. Now let’s go back to their definition of them.
What are the benefits of having a definition of “done”? Yes, the definition of “done” is mandatory. Scrum is quite firm about that. You must have a completed increment. You must have a definition of “done.” Okay, good. But what are the benefits? First, as it is written in the Scrum guide, it creates transparency. We show completed work PPIs during sprint reviews. We are not allowed to present items to stakeholders that are almost done. You know why? We might generate the wrong feedback. If we do so, the increment becomes incompletely transparent. And if the item is not done, we bring it back to the product backlog for future consideration. Second, the definition of “done” helps the developers when they select PBIS for the Sprint backlog. You are already aware that the selected PBIS are the Sprint forecast. Also, during the sprint, it helps them see how much work is left to create the increment. Now, what happens when we make changes to their definition of them?
We know that their definitions can change over time, right? We can add or remove points from it. What happens to the quality of the work when we add items? It increases, but it takes longer to do so. That is normal. Imagine you have a definition of “done.” The code is written, the code is reviewed, acceptance criteria are met, a unit test is written and passed, and a few more points remain. All good. But now imagine that you add more tests. Performance testing, low-level testing, regression testing, and security testing By the way, you do not need to know them. This means more work, and that takes time. So changes to the definition of done were made by the entire Scrum team. But we have to be careful when we remove points from the definition of done. What’s the role of the scrum master? Here? The Scrum Master doesn’t accept or reject the decisions, as you already know by now. The scrum master simply asks what the result will be. Why are we doing it? What do we want to achieve? One idea that comes to mind is this: okay, if we remove some tests, let’s say we remove integration testing, It doesn’t matter.
If we remove some tests, we will be able to complete PBIS faster. As a result of this, our velocity will increase. Instead of completing PBIs worth 30 story points, we will be able to complete 50 story points per sprint. Management will be happy. Okay, but what happens to the quality of the increment? Do we still have a usable increment? What happens to the transparency? These are the questions and considerations of the scrum master. The last thing about changes to the definition of them is that we do not do them every sprint. It is not, for example, appropriate to conduct acceptance testing (user acceptance testing) every other Sprint.
Either you do it or you don’t. We want consistency and transparency. The action item for this video is an article. Scrum is a framework to reduce risk and deliver value sooner. It is a bit long, but do not worry. You do not need to read all of it. Just a few paragraphs. Every sprint, you go to two driving principles that deliver a dumb increment. Let’s do a quick recap. One of the fundamental principles in Scrum is to create a dumb increment every sprint. Dumb means no more work is pending. Testing is included. The increment is relinquishable. The definition of “done” may change during the project. The entire stream team makes decisions regarding adding or removing criteria from the definition of “done.” Benefits of Having a Definition of “Done”: Everyone in the Team Knows What “Done” Means Transparency During the Sprint The developers know how much work is left to create an increment.
The developers consider the definition of “done” while making a sprint forecast. The product owner knows the progress of the sprint. The product owner and the stakeholders know what they inspect. Sprint Review: When the team makes changes to its definition, the scrum master knows the right questions to ask: Why are we making the changes? And what do we want to achieve? Will this change reduce transparency in some way? Will we still be able to create valuable increments every sprint? In the next video, we will talk about the second fundamental, which is having clear goals. Thank you for your patience, and please stay focused.
13. Fundamental Scrum Principle #2
Let’s talk about the second fundamental Scrum principle: setting clear goals. As you know by now, product goals are a much younger concept than spring goals. But in any case, goals help scrum teams stay focused on what is important. You might be thinking, “But during sprint planning, haven’t the developers identified the work necessary to achieve the sprint goal?” The answer is yes. This is the initial forecast, but that work changes as more is learned.
Not all the work is equally important with regards to the sprint goal. There may also be PBIS that have nothing to do with the sprint goal. Now, I’d like to show you an example of a Sprint goal product. Let’s start with what is not a sprint goal. Complete tasks 322 through 422 and 212. This is not a good idea. The Sprint goal should be written in business language that anyone can understand. It is not just the developers but the stakeholders as well. Now, imagine that you own several wine shops in New York City. Your business is doing well, but you want to increase sales. And you know that if you start selling online, your revenue will increase. The problem is, of course, that you do not have a website. But on the other hand, you’ve gotten great feedback from the customers who physically went to your wine shops.
One of the things they like most is that you put a little card that says what foods go best with the wines they’ve chosen. Now that you’ve hired an agile company to help you with your website, you collaborate closely with the product owner and yourself to come up with a product vision. Here it is. Become one of the leading online wine shops in the United States. Now it’s time to come up with a product goal. As you know, in Scrum, we do one product goal at a time for the entire project. We might need to achieve maybe five or four; it doesn’t matter. We might need to achieve multiple product goals. This is fine, but we do them one at a time. So for goal number one, create and publish a modern-looking website where customers can purchase wine. The Scrum team does short sprints once a week or maybe twice a week. It doesn’t matter. The fact is that they would need to achieve a few or several Sprint goals to achieve the proper goal. Let’s see. Sprint goal number one is to create a basic website with sign-up and sign-in functionality. That means users will be able to create accounts and login in the future.
Visitors will be able to track the progress of the orders, view order history, and more. But this will be done in the next print. The first print goal is about creating a basic website with sign-up and sign-in. That’s it. The site will be empty. Basically, there won’t be any wines to sell yet. Sprint goal number two is to create a small product catalogue and display the top ten best-selling wines on the home page. The product catalogue is not huge, but since we’ve been selling in physical stores, we know the best sellers, so we’ve added them to the homepage. Spring goal number three: extend the product catalogue and support credit card payments so visitors can order wine. Here we can start taking and fulfilling orders if necessary.
We set more spring goals to achieve the product goal, which was to create and publish a modern-looking website where customers could purchase wine. Once the product goal is achieved, we set another one. For example, create and launch Apple and Google apps to educate customers about wine and give them the option to buy it. This product goal will move the product closer to the product vision. You know, the top five competitors—they all have apps. You see that ratings are high; people are using them. You’re asking the question, “How can I add more value?” I hope this example gives you a better idea of sprint and product goals. Now, what you have to know in regards to the example first—and I’ve already mentioned this—is that during the sprint, the sprint team commits to the spring goal and not to the initial forecast. Not all PBIS are in the sprint backlog. So the single objective for the sprint is the sprint goal period. Next, the sprint goal provides creativity and flexibility to the developers when they identify the work needed to achieve the goal and, of course, build the increment.
It allows flexibility to negotiate or renegotiate the work to achieve that goal. As you remember, during the sprint, the scope may be clarified and renegotiated with the product owner as more is learned. When I said the product owner, a question came to mind based on: how does the Scrum team craft its spring goals? The answer is based on a business objective the product owner presents during sprint planning. This is what the product owner would like to achieve. Stephanie Akerman’s blog post Getting to Them: Creating Good Sprint Goals is your action item for this video. She will give you some perspective. For example, if the spring goal is too big or vague, or maybe it’s not meaningful at all, let’s recap.
During sprint planning, the product owner presents an objective based on which the sprint team crafts the sprint goal. The sprint goal helps the team stay focused and answers the question, “Why are we building the increment?” A sprint goal allows developers to be flexible and creative in terms of what they work on and how they work. Each sprint has a sprint goal. This is mandatory. The sprint goal never changes during the sprint. Without a sprint goal, there won’t be an incentive for the members of the scrum team to collaborate. Everyone will be working on their own thing daily. Scrum loses its value. You’ve got nothing to inspect and adapt to. It is getting harder for the developers to determine which PBIS are important and which are not. The developers will commit to all the work in the sprint backlog. All sprints become the same. Creativity and flexibility are lost as a result. In the next video, we’ll talk about feature teams versus component teams. Thank you for your patience, and please stay focused.
14. Component Teams vs Feature Teams
Scrum teams are cross-functional. Another phrase that says the same thing is “scrum.” In Scrum, we have feature teams. Feature teams have all the skills needed to create an increment. On the other hand, there are component teams. Component teams rely on other teams to continue or finish the work to create a done increment. Now, there are pros and cons for both types of team formations. Usually, organisations adopting agile and Scrum make the transition from component teams to feature teams. As a scrum master, you have to know the consequences of that. Now, I’ll ask you to look at the sketch I prepared for you. This is a software architecture that consists of three layers. To create a finished feature, you need all three.
The user interface is the first layer, followed by the business logic layer and the database layer. And now a component team works horizontally on one component or layer. For example, consider the user interface. But the feature team works vertically. As you can see, a component team cannot create a feature from beginning to end. They can only do one layer or one component of the feature. And they have to hand off the work to another component team that will do the next layer, and so on. As you know, this is not typical for the waterfall approach. And let me tell you a funny analogy that helped me remember this concept. One of my teachers said, “Vladimir, think about slicing cake.” Now, let’s talk about some characteristics. First of all, feature teams are harder to form. You need complementary skills within the team so an increment can be created without relying on other teams or people outside the Scrum team.
On the other hand, component teams are easier to form. Feature teams deliver value faster than component teams. Changes in the team’s composition have a bigger impact on feature teams than on component teams. Why? Usually the learning curve is higher when a new member joins a feature team, and as a result, productivity or velocity goes down. I’m talking about at the team level. The reason is called knowledge transfer. Let’s say that one or two new developers join a feature team. The other members of the Scrum team have to spend time with the new developers and get them up to speed with the project, with the technologies, with the working agreements, and so on. Yes, of course, knowledge transfer is also true when you add a member to a component team. But the impact is not that significant. When you form a new feature team, you cannot expect high productivity from the get-go.
Such teams require time to perform well. And there is a concept I like. When you form a new team, it usually goes through four stages: forming, storming, norming, and performing. So to get to stage number four, performing, the team needs time. Of course, they need another team member: a good scrum master. Okay, so up until now we’ve been talking about cross-functionality, but you also know that Scrum teams are self-managing. Previous versions of the Scrum guide used the term “self-organizing.” Therefore, if you are asked to help with team formation, you set the boundaries in terms of the agile and scrum concepts. You explain that it is important for a team to be able to pull items from the product backlog and turn them into increments of value without outside help. But this is important. You do not assign people to teams. And let me repeat that you, as a Scrum Master, do not assign people to teams. The action item for this video is a blog post by Mike about the benefits of feature teams. Let’s go. Recap feature teams have all the skills they need to turn PBIS into increments that deliver value. Feature teams are harder to form, and changes to the composition have a bigger impact.
As opposed to component teams, newly formed feature teams are not immediately productive. It takes time to reach high performance levels. Storming Norming: When you perform as a Scrum Master, you set the scrum and agile boundaries within which a group of people can self-organise into teams. The scromaster does not assign people to teams. Feature teams deliver value faster than component teams. They help teams reduce waste created by handoffs. Handoffs refer to the transfer of work from one person to another or from one team to another. In the next video, we will do a general recap, and after that, we’ll talk about a very important concept in regards to the PSN to exam conflict resolution and how the Scrum Master deals with that. Thank you for your patience, and please stay focused.
15. Recap #3
It is time for a general recap. Let’s do it. A done increment is one of the fundamental principles of scrum. Every sprint done means no more work is pending. Testing is included. The increment is relinquishable. The definition of “done” may change. During the project, the entire scrum team makes decisions regarding adding or removing moving criteria from the definition of “done.” Benefits of having a definition of “done”: everyone on the team knows what “done” e team knows what “During the sprint, the developers know how much work is left to create an increment. The developers consider the definition of “done well.” When making a sprint forecast, the product owner knows the progress of the sprint. The product owner and stakeholders are aware of what is inspected during the sprint review. When the team makes changes to the definition of Dunw, the Scrum Master knows the right questions to ask: Why are we making the change?
And what do we want to achieve? Will this change reduce transparency in some way? Will we still be able to create valuable increments every sprint? Next, during sprint planning, the product owner presents an objective based on which the scrum team crafts the sprint goal. A sprint goal helps the team stay focused. And it answers the question, “Why are we building the increment?” The sprint goal allows developers to be flexible and creative in terms of what they work on and how they work. Each sprint has a sprint goal. This is mandatory. The sprint goal never changes during the sprint. Without a sprint goal, there won’t be an incentive for the members of the scrum team to collaborate. Everyone will be working on their own thing daily. Scrum loses its value. You’ve got nothing to inspect and adapt to. It is becoming more difficult for developers to determine which PBIS are important and which are not.
The developers will commit to all the work in the sprint backlog. All sprints become the same. Creativity and flexibility are lost as a result. Next feature teams have all the skills they need to turn PBIS into increments that deliver value. Feature teams are harder to form, and changes to the composition have a bigger impact. As opposed to component teams, newly formed feature teams are not immediately productive. It takes time to achieve peak performance and establish norms. When you perform as a Scrum Master, you set the scrum and agile boundaries within which a group of people can self-organise into teams. The scrum master does not assign people to teams. Feature teams deliver faster than component teams. They help teams reduce waste created by handoffs. Handoffs mean handing work from one person to another, or from one team to another. Thank you for your patience, and please stay focused.
