21. Multiple Scrum Teams – Everything You Need To Know
Many students ask me if they need to study the scaling framework for the PSM II exam. and my answer is no. There is no need to research Nexus or Less or any other scaling framework. It’s not a bad idea to read the Nexus guide. In fact, I recommend it to my PSM I and PSPOL I students. I highly recommend that you read it too. But the idea is to get the key concepts around scaling. And this is my goal for this video. It’s an important one. So let’s get down to it. First of all, when you analyses questions on your exam and see multiple scrum teams, you must pay attention to the number of products being developed. For most of the practice exams I’ve done, there were multiple scrum teams working on the same product.
So one product that we know from PSM One still applies here. One product has one backlog, one owner, and one goal at any given time. And one of the biggest challenges Chrome teams face when scaling is called dependencies. And this is why scaling frameworks are usually designed in a way to reduce cross-team dependencies and increase transparency. Next, there is one metric from the evidence-based management guide: time spent context switching. Basically, it tells us that the more tasks we switch between or the more interruptions, like meetings, calls, et cetera, the less productive we are. Also, this decreases our ability to innovate. Why am I saying this? We must keep in mind that Scrum team members can work part-time. One person may act as a scrum master for a few scrum teams. No problem. In a few Scrum teams, one person may serve as the product owner. This is fine. But when that happens, we have to know how to scale the accountability of the product owner. It is not by adding product owner proxies; it is by delegating accountabilities. For example, when writing PBIS, divide it into smaller chunks to fit into a single sprint.
The same applies to the developers. Let’s say that every working day, John, who specializes in back-end development, works 4 hours for Chrome Team A and 4 hours for Scrum Team B. These teams might be working on the same product. So we have one product backlog. This is good, but they have those two teams; they have different sprint backlogs; they have different sprint goals; they have different team dynamics; and so on. As a result, John’s productivity would be lower than if he worked solely with one screen team full-time. Yes, we acknowledge that fact. But again, Scrum team members can work full-time as well as part-time. This is fine. There is no rule stating that you must work full-time. No. Next, what happens to the strong framework when we scale? We know that there has to be a change to accommodate scaling and working with multiple teams. But does it change radically? Let’s take a look at Nexus and Less, which stand for large-scale Scrum. Nexus does not change the core design or ideas of Scrum, leave out elements, or negate the rules of Scrum. Doing so covers up problems and limits the benefits of Scrum, potentially even rendering it useless.
What about the Less framework? Let’s is a skeletal version of one team Scrum, and it maintains many of the practises and ideas of one team’s chrome unless you find a single product backlog because it is for a product and not a team. One definition is done for all teams: one potentially shippable product is intermittently available at the end of each sprint. one product owner with many complete cross-functional teams without a single specialist team in one sprint. Now what do we do with this information? Well, we have to remember that the core design, as the Nexus Guide says, of Scrum does not change when we scale to multiple Scrum teams. Another topic that causes a lot of confusion is the definition of “done.” What happens to their definition when we scale? First, all Scrum teams agree on a shared definition of “done.” All Scrum teams mutually define and comply with the same definition of “done.” And the confusion comes here when we ask the question: Can the screw teams have different definitions of “done”?
The answer is yes, to some extent, because they use the same definition of “done” as a basis or baseline. They just add a few more points to it. That’s it. Why do I say to some extent? Well, the individual teams cannot remove points from the agreed-upon definition of them. They can only add in this way, which is different, and that means 100% compatibility. But if this is somehow confusing to you, do not worry at all. What you have to remember is that all scrum teams agree on a shared definition of them. This is mandatory. Let’s say five Scrum teams are working on the same product, and when they combine their work, they create what’s called an integrated increment. So the shared definition of them applies to the integrated increment as well as their individual work before it is integrated. Another important topic is coordination. When we have many teams, they have to coordinate in some way. What do you do as a scrum master? Do you act as a coordinator? The answer is no.
The Scrum teams are self-managing and cross-functional. If the Scrum master acts as a coordinator between developers and different teams, that would actually create another dependency. Dependencies are already a primary concern when we scale, so we do not need more dependencies. There are different ways to coordinate work. One simple method from the last framework is called “just talk.” Do not wait for special events; go to the other team and share your concerns. Scrum of Scrum is another method you’ve probably heard of. It is similar to daily Scrum, but it is on a multi-team level. This improves coordination at the node. There is also an integration team, and one of their main responsibilities is to help coordinate work among the teams and to raise awareness of dependencies as early as possible. But I’ll stop here honestly for your example—you’re not required to know coordination techniques. I just want to give you a few points to consider. That’s it. What you have to know is that the scrum master does not act as a coordinator when we scale. The coordination lies within the responsibilities of the Scrum teams.
Let’s do a recap. When scaling Scrum, one of the biggest challenges we face is dependencies. All members of the Scrum team can work part-time as well as full-time. That means one member can work on two or more teams. The downside to this is called “context switching.” The more we switch contexts, the less productive we are, and our ability to innovate goes down to scale. Because of the accountability of the product owner, we do not add multiple product owners to one product. We do not use product owner proxies; instead, the product owner delegated work to other members of the scrum team. When scaling scrum, the core design and ideas of scrum did not change. When scaling Scrum, all Scrum teams must agree on a shared definition of it. Coordination between teams lies within the responsibilities of the Scrum teams. The scrum master does not act as a coordinator. Once again, this is a critically important video. So please watch it more than once. Thank you for your patience, and please stay focused.
22. Timeboxing – The Agile Concept Behind All Scrum Events
Timeboxing is an important agile concept that is used throughout the Scrum framework for all of its events. You are already familiar with time boxing, but in this video, I just want to give you a few more perspectives. First, let me share with you my favourite definition. It is from Scrum Ink. Timeboxing is the use of a fixed maximum unit of time for an activity.
This unit of time is called a “time box.” The goal of time boxing is to define and limit the amount of time dedicated to an activity. So what limits the work in progress? It’s called timeboxing. How? Imagine you’re working on an open-ended task. If you left it alone, you could be working on it for an unknown amount of time. So your work is in progress. But if you use a three-hour box, then you can finish sooner. For example, in 2 hours and 30 minutes That’s fine. But whatever you do when you hit the three-hour mark—the three-hour time box—you have to stop working. And this leads me to the next point. We have to respect the time boxes of the Scrum event. As you know, the Scrum team should not extend the duration of the sprint just to complete a few more PBIS. This does not mean that once we choose a sprint duration, it is fixed during the entire product development. No, we can discuss it during the sprint retrospective.
If we should adjust the sprint timebox, maybe the market is quite volatile and we need to receive more frequent feedback so we can adapt faster. Okay, let’s do shorter sprints. In this case, this is completely fine, but once you select the new penbox, you keep going with it. On the other hand, it is not okay to have each sprint have a different duration just because you need a bit more time to complete PBIS. And many people think, “Okay, but what is the problem?” We do one-month sprints. Let’s say, for example, a one-month sprint. What is the big deal about extending just a few more days? First of all, the Scrum guide says that the sprints are fixed because this creates consistency. On the other hand, consistency helps with dealing with complexity. We do not want to fight complexity with more complexity. quite the opposite. We want to fight complexity with simplicity. This is why regularity or consistency is important. Let’s talk about the problems that extending the sprint creates.
Let’s say in a one-month sprint, we extend it by just four or five days. Someone might say it’s not a big deal, someone might say. But my question is, how will the developers calculate their velocity? As you remember, they consider their past performance during sprint planning when they select PVIs for the sprint backlog. And will they only look at the PVIs taken during the sprint, or will they include those taken during the four- or five-day extension? But if they include them, wouldn’t that be misleading for the next sprint? Maybe they would end up in a situation where they needed a few more days to extend the sprint. Another question appears: when are we going to do the events in the upcoming sprint? Maybe the product owner coordinated with stakeholders, and everyone knows that the last week of every month on Thursday we do a sprint review. Will we be able to keep that time? Or maybe we’re going to change it five days in advance. So we need to coordinate with stakeholders for the new data.
This is not good. As you can see, it creates complexity. Another important perspective is this: why weren’t we, as a scrum team, able to achieve the sprint goal in the allotted timebox? Are we going to spend any time during the sprint retrospectively analysing the calls? Some teams will do that, others won’t. After all, the sprint goal is achieved; why should we worry? I think we have to always look deeper into a problem and not just on the surface. One might say, “Vladimir, what is there to analyze?” We didn’t have enough time. Yes, on the surface, this sounds like a reasonable explanation. But maybe there is another reason that led to this. What about the skills of the team members? And this will be the topic of the next lecture. I’ll present a quite interesting metaphor. But before we go there, let’s see the action item.
Read the blog post. Agile coach toolkit number two is timeboxing. What you should focus on the most is the section on the benefits of time boxing. A quick recap All official Scrum events use the Agile concept of timeboxing. The scrum master ensures the events are kept within the time box. Timeboxing helps the members of the scrum team stay focused on the same objective. As a result, the members who work on the problem are encouraged to come up with the best solution in the time allotted. Timeboxing limits the work in progress. Extending a sprint for a few more days to achieve the sprint goal is not allowed. Thank you for watching. Stay purposeful.
23. Skills Within The Scrum Team
There is a concept, or I should say a metaphor, of people with eye-shaped and T-shaped skills. There are also people with pie-shaped and cone-shaped skills. But let’s keep it simple. Eye-shaped people are skilled in one area. For example, a test engineer is specialised in testing. But an eye-shaped testing engineer cannot write production code. This is what a programmer would do. or an I-shaped programmer cannot write tests. On the other hand, a T-shaped programmer has some skills in testing. Yet he or she may not be as proficient as a test engineer, but they can certainly contribute to the team’s success if the timebox is about to expire soon.
And I’m not talking about cutting corners or doing work of low quality. No, the developers commit to technical excellence. If there are three PBIS with different levels of testing skills required, the programmer may test the PBIS that does not require proficiency at testing. In this way, the test engineer would be able to focus on the one or two PBIS that do require proficiency. I’m just giving you an example here. But this is the concept. People with pie-shaped skills have expertise in more than one area. For example, a pie-shaped person is proficient in both testing and writing production code. A cone-shaped person is proficient in three or more skills. For example, testing, writing, production code, web design, and maybe something else. Anyway, a great scrum master encourages the members of the team to learn new skills to develop themselves. The result is a team with more T- and P-shaped people instead of only I-shaped people. Of course, having cross-functional developers is not the goal. No cross-functionality refers to the team as a whole and not to individual team members. And I know this is also a topic of great debate. Is it in the shape of T-shaped skills? If you do a Google search, you will find different opinions.
But this is fine. Now, why did they bring this metaphor up? Let’s go back to the previous lecture, where the problem was a lack of time. Maybe the Scrum team extended the sprint by five days because the members of the team are eye-shaped and there were just, you know, two or three days left for testing. So the programmers did their job. All the code is written. This is good, but it is not tested. This is what the test engineers would do, right? Maybe people would start blaming each other. The tester would say, “Why were we left with only three days on such a big PPI?” We need more time for testing. The programmers would say, “We couldn’t produce a done increment by the end of the sprint because the testers are not ready.” We did that. We did our job. It’s up to them. As you can see, this is not the spirit of Scrum. This is not working according to the five Scrum values. But this is what happens in the real world. So when you’re dealing with a problem, go deep. Ask the question “why.” By the way, this is the very reason why it’s chrome. There are no titles. All the people doing the work are called developers.
The very fact that I specialise in web design does not mean that this is all the work I’ll be doing when I work in a scrum team. Maybe I’ll have to write some documentation, maybe I’ll have to do some research, maybe something else. No problem. Whatever it takes to achieve the spring goal This is the spirit of high-performing screen teams. It is when individuals think about the team’s objective rather than their own. It is when the ego is not in the way. It occurs when the members of the team collaborate. Now, as a scrum master, you have enough perspectives to consider. when somebody comes up with the idea. Let’s extend the sprinters for a few more days. We should not act as supine police and tell that person. The scrum guide prohibits that. That concludes the story. Instead, share what you know. Share your perspectives. Scrum once again included programmers, testers, engineers, designers, and architects. We call them developers. I used some titles to illustrate the example better. The entire scrum team is accountable for the success of the product. This is one unit focused on one product goal at a time.
Next, you are a scrum master working with multiple scrum teams, and you have a challenge in front of you. It is called the scarcity of skills. There are three teams, but only one person with a specific skill is needed on all three teams. It’s a difficult situation to be in. What would you do? First, as you know, hiring developers is not a good option. Second, if the developers can self-organise and come up with a solution, that would be fantastic. Third, think of the first fundamental scrum principle: creating a dumb increment every sprint. You remember when you have multiple scrum teams and they combine their work into one integrated increment. So maybe one option would be if that person with the special skills consulted the three teams. This would help the teams produce the integrated increment. Another option would be if that person taught other people the scarce skill. Chances are, when the developers see that this skill is needed and someone volunteers to learn it, As you can see, once again, we are talking about collaboration. The action item for this video is to read the blog post.
Cross-functionality doesn’t mean everyone can do everything. Let’s do a quick recap. To become high-performing, scrum team members must collaborate. Scrum team members should not let ego get in the way. The scrum master encourages individuals to learn and develop continuously. If multiple scrum teams are faced with the impediment of a missing skill, consider the following: Hiring is not a good option. Facilitate the ability of developers to self-organize and solve problems. One person who has the missing skill can consult the teams so they can create an integrated increment. Or that person can teach the developers so that the skill is developed. In the next video, we will do a quick review of burnout and burndown charts. If you remember them perfectly, feel free to skip it. This is fine. Thank you for your patience, and please stay focused.
24. Burnup & Burndown Charts
The purpose of this video is to remind us what the two famous charts show. I’m talking about burndown and burnup charts. Now I will play a part of a lecture from my PSPO One course where I explain the details around those charts. I mentioned my course not to self-promote, but to draw your attention to the fact that you should do that as a product owner, you should do that.
As a product owner, you shouldn’t do that. I know that you prepare for PSM Two. Don’t get me wrong. I could create a brand new video about these charts, but I do not have anything else to add. This is why I will reuse my existing video. I want my efforts to go to the most important PSM-2 knowledge areas. Anyway, let’s watch. Let’s start with the burned-down charts. It’s quite simple, by the way. Here is how they look: Here is what the burned-out chart looks like. The horizontal axis shows the time. The vertical axis shows the amount of work. So the burned down chart shows how much work is left, or, in other words, the amount of remaining work across time.
The green dotted line is a trendline that shows our planned progress. But the blue line is our real progress. This is what actually happens. As you can see, the more PBIS we complete, the more the blue line moves down. You should know that the trend line is just an assumption about when the project would be completed. If there aren’t any significant changes—or, I should say, no changes at all—to the number of developers or the scope of the project, That’s important, because if you as a product owner constantly add new PBIS, you are basically changing the scope of the project. It would be impossible to end the project somewhere near the trend line. Even though Scrum is an agile framework, In Agile, we don’t do upfront planning. Let’s be realistic. Sometimes the Scrum teams would be working on a project with a deadline. Now forget about the trend line for a moment and think of it as a deadline instead.
As a product owner, you can set this deadline yourself. And what does it mean when the blue line is above the deadline? It means we are behind schedule. If we are under the red line, it means we are ahead of schedule. Now, the burn chart can be used to measure the progress of the sprint. The horizontal axis would show days, and we could call it a Sprint burndown chart. When the product owner uses such a chart, we can call it a project burndown chart. Then the horizontal axis would not show days, but instead it would show sprints. A burn-up chart, in addition to a burn-down chart, is available as a total track progress. It shows the complete and total work. As you can see, the completed work starts at zero and goes up. This chart shows any changes in the scope of the project. The scope is the total amount of work. Assume we have a product backlog of ten PBIS totaling 120 story points.
That’s our scope. But the customer wants to add two more features. More PBIS means more story points. As a result, the total amount of work increases. And let’s say that we’ve added two PBIS worth 20 story points, and the result is the blue line going up to 140 story points. As you can see on the chart, if we remove PBIS, the burn chart would reflect that as well. The blue line would go down. Now, some people would say it is better to use burn-up charts instead of burn-down charts because the burn-down chart doesn’t show changes in the scope. That is not completely true, because now, instead of drawing it by hand, we have tools like Jira, as they’ve already mentioned. You can also configure it so that the burned-down chart displays changes in the scope. But this is not important. As a product owner, it’s up to you to choose how you will present and show the progress of the project.
And by the way, these are just two charts, but there are many, many more charts you can use. For example, cumulative diagrams and many other things But what is important here is your focus. What do you focus on? You’re measuring progress. So that means everything should revolve around value, not velocity or story points. Yes, these charts are helpful, but the ultimate measure of success is the value your project delivers. Let’s do a quick recap. Progress measurement is mandatory and strong. The product owner measures the progress of the project once per sprint to ensure value is being delivered. The burndown chart shows the remaining work across time. The trend line is simply a forecast, an assumption of when the project will end if there are no changes in scope or number of developers. The burn up chart clearly shows the total amount of work or changes in the scope. All right, I hope that was a good refresher on the two charts. Thank you for watching. And never forget: stay purposeful. You.
25. Recap #5
I’m proud of you. The very fact that you are still here shows that you are determined and disciplined. Let’s do a general recap. Tools are important, but collaboration between individuals is more important. From the Agile Manifesto, individuals and interactions over processes and tools are described. Many of the tools and engineering practises in the charts complement the scrum framework quite well, but they are not mandatory.
The scrum master doesn’t enforce practises or tools but has the team discuss their needs and cooperatively choose the solutions. Next, one of the most difficult challenges we face when scaling scrum is what is known as dependencies. All members of the scrum team can work part-time as well as full-time. That means one member can work on two or more teams. The downside to this is called “context switching.” The more we switch contexts, the less productive we are, and our ability to innovate goes down to scale. The accountability of the product owner is why we do not add multiple product owners to one product.
We do not use product-owner proxies. Instead, the product owner delegated work to other members of the scrum teams. When scaling scrum, the core design and ideas of scrum do not change. When scaling scrum, all scrum teams must agree on a shared definition of it. Collaboration between teams lies within the responsibilities of the scrum teams. The scrum master does not act as a coordinator. Following that, all official scrum events adhere to the Agile concept of timeboxing. The scrum master ensures the events are kept within the time box. Timeboxing helps the members of the scrum team stay focused on the same objective. As a result, the members who work on a problem are encouraged to come up with the best solution in the time allotted. Timeboxing limits the work in progress. Extending a sprint for a few more days to achieve the sprint goal is not progress. ExtTo become high-performing, scrum team members must collaborate.
Scrum team members should not let ego get in the way. The scrum master encourages individuals to learn and develop continuously. If multiple scrum teams are faced with the impediment of a missing skill, consider that hiring is not a good option. Facilitate the ability of developers to self-organize and solve problems. One person who has the missing skill can consult the teams so they can create an integrated increment. Alternatively, that person can teach the developers so that the skill is developed. Progress measurement is mandatory in scrums. The product only measures the progress of the project once per sprint to ensure value is being delivered. The burndown chart shows the remaining work across time. The trend line is simply a forecast, an assumption of when the project will end. If there are no changes in scope or the number of developers, the burnup chart shows the complete and total work. Changes in the scope are clearly seen. For your exam, remember that charts or diagrams are not mandatory. Thank you for your patience, and please stay focused.
