16. Conflict Resolution: How Scrum Masters Deal With Conflicts
There is a scrum rule that every single sprint should produce business-facing functionality, no matter how small. Every single Sprint should produce business-facing functionality. To make it simple, let’s separate product requirements into two categories: functional and nonfunctional. A quick reminder Non-functional requirements are things like security, scalability, maintainability, speed, regulatory compliance, and so on. They have to do with how functional requirements work. These are the normal features. As a user, I would like to be able to create an invoice. As a user, I want to be able to log in with Google and Facebook. As a user, I want to be able to export all invoices. As a user, I want to be able to filter by date, by recipient, by status, and so on and so forth. As you can see, I used the famous story-point format story points.
You know, these are not mandatory Scrum items, but the idea is that these are functional requirements or business-facing functionality. Assume a stakeholder is dissatisfied with the rate at which your Scrum team has been developing the application. It is low. The Scrum team agrees with the stakeholders. Would it be acceptable to dedicate one sprint solely to addressing this issue? You want to reduce loading time from 3 seconds to 0.8 seconds in order to work solely on speed non-functional requirements. The answer is no. This is not okay because we are breaking the rule I started with. And this brings me to the agile concept of emergent architecture. In Agile Enscrum, when we say “architecture,” we mean those major parts of the product we’re building that have to do with satisfying functional and non-functional requirements. I know this is a very broad explanation. It’s not an official definition, but I’m explaining it from the point of view of Scrum and PSM too. Now, the whole idea is to avoid too much upfront flooding and implementation of the architecture. Instead, you let the architecture emerge over time.
This is not on autopilot. The architecture is purposefully built by the team. Of course, you adhere to technical excellence, but you do just enough architecture to satisfy the requirements. I’ve seen questions like, “When or how is architecture handled in Scrum?” The answer is continuously during the sprint. During Sprint Zero, a false answer would be given. And you know Scrum doesn’t approve of “Sprint Zero” as a concept. As you can see, this is related to empiricism. We won’t make architectural decisions based on facts, knowledge, or real data. We want to build architecture and design in response to the most valuable PDIs; I want to show this graph. As you can see at the beginning of the project, we work on architecture much more than on business functionality. something like 90% architecture, or we can also call it infrastructure, and 10% business functionality. Of course, we need architecture to build the features that can be released and add value. But the idea is to look even at Sprint One.
Take a look at where it says “S.” We have a dumb feature that can be released. And I’m not talking about 70% done or 80% or 99%. I’m referring to features that are completely finished, according to the definition of done. We do less architecture and more business functionality as we complete more sprints. A quick reminder here: what are some ways to handle non-functional Functional Requirements? First of all, we do not rely on external teams, for example, to improve speed or scalability. This is the first point. Second. Usually, non-functional requirements apply to the whole system. All PVIs. It is a good idea to add some of these non-functional requirements to the definition of “done.” If we receive the non-functional requirements now and we are at Sprint Six, for example, what can we do? Well, the product owner writes the PVIs in the product backlog and then prioritises them with the team. Your action item for this lecture is to read a quick article. How is emergent architecture handled in Scrum over here in Doshi?
If you want to learn more about emergent architecture, check out Charles Bradley’s article An Introduction to Agile Emergent ArchitectureAlways Intentional. This one is optional, but it will add value. A quick recap: a restraint in scrum produces business functionality, no matter how small. Emergent architecture is an agile concept. As the name suggests, agile teams let the architecture emerge or evolve over time. This supports the Agile belief that big upfront planning is not accurate. So a better approach is a little upfront planning with regards to the architecture and doing just enough to satisfy the product requirements. As a result, we end up changing the architecture of the product continuously. In the next video, we will talk about the city and its value. Thank you for your patience, and please stay focused.
17. Emergent Architecture
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 that 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 school master, do not assign people to teams.
Mike’s blog post serves as the video’s action item. the benefits of feature teams. Let’s go. Recap feature teams have all the skills they need to turn PDIs 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 You set the scrum and agile boundaries within which a group of people can self-organize into teams by norming your performance as a Scrum master. 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 and conflict resolution and how the Scrumbaster deals with that. Thank you for your patience, and please stay focused.
18. Velocity & Value
Let’s talk about velocity and value. What was “velocity”? The amount of work the scrum team gets done each sprint If the developers use story points to estimate, let’s say they complete ten PBIs, each estimated at five story points. That means their sprint velocity is 50 story points. Velocity changes. It needs a few sprints to stabilize.
Velocity is about speed, and it does not have a direct correlation with value. For that reason, velocity cannot, or better said, should not be used as a measure of success. However, there are managers who use it as a measure of success. This leads to some dysfunction. Let me give you a few examples. A project manager may compare the velocity of two teams. The velocity of Team One is 50 story points. Team 2 has a velocity of 80 so far. In the eyes of the managers, Team One can do better. Why aren’t they? But now, if you were asked which team delivered more value, how would you answer? Team one or team two? The correct answer here is “it depends.” We do not know. Now, let me tell you about the second problem. Story points are relative. They are a relative unit of measurement. The raw numbers do not matter. Usually, before starting to use story points, the team gets together and chooses one PBI as a reference. They say this item—this is our reference—is worth three story points, for example. However, if you ask another team, they may say it is five story points. I’m talking about the same PBI, the same item.
Both teams are correct. The wrong numbers do not matter. So velocity is unique to each team. The third problem is that if the team notices that managers use velocity as a measure of success, they can artificially inflate their velocity. The fact that AC has that velocity is not a bad metric in and of itself, but it has been abused. This leads to the dysfunctions I’ve just mentioned. So, on your example, if you see questions where management is asking about an increase in velocity, you have to keep in mind that velocity is team-specific. If multiple Scrum teams are working, it should not be normalized; it has no direct relationship to value. And depending on the question, maybe you can introduce better metrics like customer satisfaction, time to market, or something else that has to do with business value. You know why we’ve said it several times. Scrum is about value delivery. It is not about maximum resource utilization. If you add more resources to the project, this doesn’t mean the team will deliver more value.
You can find many articles and information that argue that stripping for 100% utilisation of the developer’s time is wrong. For example, a developer works 8 hours per day, and they have to write production code 8 hours per day. But it doesn’t work like that. What the developer does is called knowledge work. It requires a lot of thinking and collaboration with other team members. If you’re a manager, you want your developers to write code every single second to achieve 100% utilization. Guess what? This will backfire. The effect will be the opposite. Productivity and speed will go down. Innovation goes down. Creativity goes down. Anxiety goes up. It is not by chance. Many big companies have policies like Google’s 20% Rule. During that time, employees may pursue personal interests that could lead to new products. For Google. This enhances creativity. I’ve also heard about a company called Mind Valley. They give their employees time to read whatever books they want. And if we do research, we will find many, many examples and many companies doing similar things. Anyway, there isn’t an action item for this video, just a quick recap. Velocity is not a measure of success. It does not have a direct relationship with value.
Velocity is about speed, and it is team-specific. It should not be normalised when multiple teams are working on the same product. As a Scrum Master Coach, I teach managers how velocity works and what it means, and I introduce better metrics that have to do with value delivery. For example, customer satisfaction or release frequency; product cost ratio; and so on. More metrics are in the evidence-based management guide. Velocity can be unreliable and easily manipulated. For that reason, managers should not incentivize teams to increase it. Scrum is about value delivery. It is not about 100% utilisation of all available and future resources. In the next video, we will do a recap, and after that, we will talk about tools, practices, and charts. Thank you for your patience, and please stay focused.
19. Recap #4
It’s time for a general recap. Conflicts within a group of people working together are natural. The scrum master helps the team navigate conflict. The Scrum Master aims to deescalate conflicts and keep them at level one, based on the model by Lisa Atkins, where constructive disagreement happens. B
y using facilitation and coaching, the ScrumMaster initiates open and honest discussion. People should never be called impediments. However, the dynamics between team members can become an impediment. The Scrum team resolves team conflicts internally. The Scrum team never relies on the HR department to decide whether or not to remove a person from the Scrum team. The Scrum team never relies on managers to help them with team conflicts. When the team identifies a problem and is actively working on solving it, the scrum master should not intervene. When the team identifies a problem and does nothing about it, the screwmaster should initiate the discussion, ask questions, and do active listening. Remember, as a facilitator, the scrum master is unbiased. When a conflict has escalated to a higher level, the scrum master steps in.
He or she might go as far as removing a person without firing them whose behaviour is negatively affecting the team’s health and value delivery. Next, every sprint in Scrum produces business functionality, no matter how small. Emergent architecture is an agile concept. As the name suggests, agile teams let the architecture emerge or evolve over time. This supports the agile belief that big upfront planning is not accurate. So a better approach is a little upfront planning with regards to the architecture and doing just enough to satisfy the product requirements. As a result, we end up changing the architecture of the product continuously. Next, velocity is not a measure of success. It does not have a direct relationship with value. Velocity is about speed, and it is team-specific. It should not be normalised when multiple teams are working on the same product. As a Scrum Master, I educate managers on how velocity works and what it means, as well as introduce better metrics related to value delivery. For example, customer satisfaction or release frequency; product cost ratio; and so on. More metrics are in the evidence-based management guide. Velocity can be unreliable and easily manipulated. For that reason, managers should not incentivize teams to increase it. Scrum is about value delivery. It is not about 100% utilisation of all available and future resources. Thank you for your patience, and please stay focused.
20. Tools, Practices & Charts
Tools, practices, and charts It is going to be a quick video. First of all, we should remember that Scrum is a framework, and it does not give us the tools, practices, and charts. We can use whatever we want. Sometimes Scrum practitioners think that certain rules or practises are mandatory in Scrum, which is not the case. For example, using story points to estimate the size of the PBIS or using value points to estimate the value of the PBIS, or using a planning poker or writing the PBIS as user stories, or using burndown or burnup charts, or doing test-driven development (TDD) or pair programming, and so on. These are not mandatory.
With that being said, for your exam, remember that these tools are never the solution to a problem. And the first sentence from the Agile Manifesto says, “individuals in interactions with a process and tools.” This does not mean that tools are useless. Of course not. They help us do our job more efficiently. But if you see a question around interactions between members versus using some tools, always 100% go for interactions between people. Let me give you an example. Multiple Scrum teams are working on the same product, and usually the biggest challenge is how to manage technical dependencies. In this case, tools for managing such dependencies are completely useful. But what’s more important is the interaction and collaboration between people. And you’ve probably heard of Git as an example of such a tool. Git? Git. What is git? It’s software for tracking changes in any set of files, usually used for coordinating work among programmers and collaboratively developing source code during software development. Another cool thing is that Git is free and open source. Why am I sharing this with you? Well, when you see a question with a tool with a complex name or terminology like “master code” or “branch code,” just don’t panic. You’re not required to know specific tools or how they work. But you are required to know that tools are important. They help us, but they do not replace interaction and collaboration between individuals. Sometimes Chrome teams do not work in the same office. We call that distributed teams.
So communication tools are critically important. For example, many people use Zoom, Skype, Slack, and so on. But if your team faces an issue with communication tools, once again, you do not jump straight ahead and resolve the issue by introducing the best tool possible. We’re back to stances here, and the strategy is to have the Scrum Master refrain from solving. Instead, what you do is help the team discuss and choose the most suitable communication tools. OK, team, what do we need in such a tool? Well, the most basic things like supporting conference calls, sharing screens, blurring backgrounds, sending files, and so on, Okay, good. What options do we have? This is the approach of the Scrum Master and the team, and as I’ve said, this is a quick lecture with no action item. Let’s do a quick recap. Tools are important, but collaboration between individuals is more important. Individuals and the interactions of processes and tools are described in the Agile Manifesto. Many tools and 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 here, the team discusses its needs and collaborates. Select the appropriate solutions. In the next video, we will talk about scaling Scrum. Thank you for your patience, and please stay focused.
