AA134 - The Most Common Disagreements You'll Get Into as a Scrum Master (Part 1 of 2)

today on Arguing Agile the most common fights that you'll get into as a scrum master. We don't call them fights. No, we don't. What do we call it? No, that's, that's a polite conversation. We don't call it arguing. We call it spirited discussions. Spirited discussion. I've had plenty of those. Disagreement? After lots of spirits. Say disagreements? You could say disagreements. You could say defensive opinion or viewpoints. Yeah. Yeah. I'm sure every Scum Master has gone through this, by the way, to some degree or the other. So you can stay tuned and you'll see. There's a lot of value to be had from this one. So here's our framework. We'll talk about we'll talk about what the, what the fight is that you'll get into. We'll talk through an experience or two that either one of us has had with regard to this fight. And we'll talk about how best you might deal with this, which is not to say it's the only way. To deal with it. One of the ways you can deal with it. Yeah. And the pacifist amongst you. If you don't like the word fight you could just say challenges. Screaming matches. Ha ha ha. Let's start with disagreements over estimation. Ooh, that's a great one. So again, most scrum masters have encountered this to some degree or the other disagreement on estimation. A good scrum master doesn't obviously provide the estimate or anchor the team toward an estimate value. They facilitate the art of estimation, but you're still gonna get into some headwind here, right? You're gonna have people saying Why do we bother with these, these numbers? Why don't we just say they're hours? Right? So, that's the most common one I've seen, where people say, Is it 3 hours or 5 hours or is it 8 hours? What if it's 6. 4 hours? See, you took this, you took this in a different direction than I was thinking. I was thinking disagreements of like, we're sitting together and estimating a particular work item, and you say it takes eight hours and I say it takes four hours and we basically can't we're finding difficulty coming to a conclusion. Although I like what you're saying is we fundamentally disagree of like story points are garbage. Nobody should ever use them, which I've heard on some other podcasts before. And you say, well. Story points have their use depending on the team maturity, et cetera, et cetera, et cetera. And then we can get into a conversation about it where you're just like, I just don't like story points. It'd be better if you're slower to start with until you figure it out. I hadn't even considered that. So, so let's crowbar these two apart. Which one do you want to start with? We can do both. We can do both. I think we can do both. You know, I, I think the one where the scrum master encounters resistance on story points and people say, why don't we just use ours? Really, that one's not so difficult to deal with, right? And that's because you could ask, you could ask the question. Hours by whom? Hours by a proficient, experienced developer? Hours by somebody who perhaps doesn't have as much experience in the technology? Or just a newbie developer? These are gonna be different numbers. Which is why we abstract that away in the story point. So that could be a way that you could explain why we use what we use. Let's see. Okay, so let's, I think we've kind of used that one up now. So we can go to the other one. People disagree on the story points and that's fine. Don't feel bad. Fight it, right? That's the point of the exercises. So you can have different opinions from different people, actual estimations, estimate numbers, right? So someone says three and someone says, nah, I think it's more like an eight. You can chew up a lot of time of your refinement just saying, Hey this person says it's a five and this person says it's a 13 and those Hey, everyone, hold their cards up or whatever. You reveal your cards or whatever it is. And then somebody has a 13, someone has a three. Yeah, obviously the value is in the discussion there, but I can think of teams that I've been on. As the product owner to the team, where as the product owner, you're kind of like the, you're, you're in refinement, your session, your refinement, you're just trying to get work items broken down. You don't even really care about, Oh, this is a 13 is a five, whatever does it have, does everyone agree that this has the proper acceptance criteria to do the job? Yes. Like, whatever. Let's move on. Let's move on to the next thing. And then when we get into planning, we can break it down further. Or we can take it to subsequent refinements. But I want to get through the first, the first pass. Okay? I want to get through the first pass. Some people might hear that and be like, Well, this is part of getting through the first pass. This is agreeing on it. But, as a product manager, when I especially when I was a contract product manager, and even when I was a permanent employee, I tell people, listen, don't, especially team leads, development team leads. I tell them, don't worry that we only got through one. Story in an hour. Don't don't sweat it. Next next refinement. We might get through one story in 45 minutes and the next one we might get through a story in 30 minutes. But I was like what you need to pay attention to is the trend of that that we're getting through stories quicker and also the trend of how complex the things that we're talking about are compared to each other because if you can't if you can't Compare things, the complexity of things. If you can't compare complexity of things with each other, first of all, you're missing your critical piece of information. Second of all, I understand you want to get the backlog to a point where like, Oh, everything's equal size. So there's really, everything's equal complexity. I agree with you. Everything should be equal complexity. However, you're really living in the future at this point where the team can work together and break everything down to the same size. So again, my experience is I'm just trying to get through items, trying to get a swag estimate, a high level. stamp on them, and then get to the next item, and, you know what I mean? Because I know that over time, the team will push back, and the team will learn this skill. Yeah, I agree. So there are three things I want to say about this. So the first thing is when someone says the 3, someone says the 13. Right. Obviously dissenting opinions here. And what you want to do quickly, as a scrum master, you want to, you want to now have the conversation among the outliers. Why is it a 3? Why is it a 13? Maybe something that the 13 voter thought about that the others didn't. Could be. So don't just let it go on and on and on. Just say in a minute, tell us why it's a 13. And then in a minute, tell us why it's a three. That'd be really interesting. You know, I think that that'd be a really interesting exercise for a scrum, like a scrum master with a new team or maybe a yeah, well, maybe a new team, to, to actually have a timer to be like, Hey, okay you say it's a three all right, I'm gonna put. One minute on the clock. Yep. You go, you go, whatever. Like maybe that, maybe that's not a great system because I kind of prefer the back and forth. Of people interjecting, asking questions and stuff. You still have that. You can still have that. So the point of the timer is to not just have this thing just going on and on and on forever, right? So have a timer. Let's say whatever time you want. I've used a minute before. Believe it or not, minutes is actually quite a long time when you have to explain why you voted, how you voted. And then you say, okay, what does everybody else think? Right? There is value in the conversation for sure. But then the scrum master could say, knowing what we know now, let's re vote. Yeah. So go ahead and wipe out the votes and re vote on that item. Now you're going to get a little more convergence, right? And honestly, if you're, so we'll use these numbers as illustration 3 and 13. Let's say the convergence was mostly three, mostly fives and mostly maybe some eights and one person just stayed resolute on the three. Doesn't matter. Nobody dies on this hill. You pick a five or an eight and just move on, right? Nobody dies on that hill. So that was one of the first things I wanted to say. I have two more things I want to say. One is, if you're not, and you hit on this right away from the beginning, if you're not using a reference story to compare the others with, In terms of complexity and all of that, right? You've missed the point. You're not doing relative estimation. You're taking every item in isolation, right? That's not relative estimation. So, that is something that a Scrum Master needs to kind of come in and say, let's pick one of these that we know, everybody agrees we can comfortably get it done in a sprint. Relative to that now, let's estimate the others. So the third thing I was going to talk about is this. Look, if the team decides either really kind of willingly or hesitantly uh, it's a three, let's say they go with the three. Okay. Now it's in the backlog. It's got a three on it. That doesn't mean that three has to stay that way forever. So let's say a time comes when the team pulls that into a sprint and it might be the next spring. It might not be when they pull it into the sprint. You learn a little more now. Yeah, we said it was a three, but right, this other thing that we just learned since that estimation session, we think we should reestimate. There's nothing wrong with that, right? The team can reestimate that up into a five if that's what it takes to go the other direction. You don't have to die on that sword, right? So that is that that is the third thing. In that case my suggestion would be to to always be open To engage your product owner to the team to renegotiate stories So if you if you start working on something this happens all the time with teams that take over legacy code from other maybe they weren't at the company when that, when that code was built, employed for the first time. When you get into a, a piece of code, or when you get into a feature and start changing it be open to say hey, we found this, and it really would be better if we changed we said we originally were going to do A and B, and now that we see the middle of the code, A and B is not going to be enough. We need to do X, Y, Z as well. And the product owner could that's a perfect opportunity to step in to say, listen, just do A and B as best you can in this sprint, we're going to stay with our scope that we picked. We'll write a new story for X and Y and Z. And we'll do them in subsequent stories, if that's even a possibility, right? If it's possible. If it's not possible, maybe you pull all the work out and you kind of think about what you want to do again. But there are strategies for this. Absolutely. So, again, going back to the role that we're discussing today, the role of a scrum master, right? They need to be cognizant of this and say, Be open to this idea that we can definitely look at the scope all the time. New things that we just learned, engage the product owner and say, well, maybe we need to rewrite this story. Or put it back in the backlog and then come back to it, kind of have another pass at the refinement. Well, you know the other thing that Scrum Master can do that really would help product at this point that I'm thinking of. At, at the point where something's been pulled into a sprint and started. Like, let's say the work is in the sprint. Hasn't been started. You started the more important story first. The thing that Scrum Master can help with is, Hey, we started on the more important story. We realized that it was a lot bigger than we expected once we got into it. And this second story. Which is maybe for a different stakeholder. We're not going to be able to get to it if we end up like the first story turned from a three into an eight. If we do the whole thing in the sprint, which we do think we can We have to push all the rest of the work out of the sprint what the scrum master can do in that case to really help with is they can help the product manager or product owner with stakeholder management to say, Hey, your item slipped. You know, we were going to do it now. We communicated that we were pulling it in. You know, we, maybe they got them in a refinement or whatever and got their time. But we discovered this other thing. With this other higher priority item, and here's what we're doing. Just keep them informed. So it's another, it's another layer of stakeholder management that the Scrum Master can help with, to really relieve intense pressure, especially when people were promised things, and you your product manager has to make a call. Yeah, definitely. That's one of those situations where, like you said, the Scrum Master can really partner with the product owner or product manager for that matter. Everybody's in it together for the same cause at the end of the day. There is no us and them, us and the business. Anytime your team members say something like, Well, the business, , they changed their mind. That's a red flag right there. Well that's when you say, well, who's they, we're all in this together. Can we all just get along? No, no, my goodness. Let's see Hey, what's, what, what else? what other things cause a difference of opinion? I can give you one, a scope creep scope group. We went on the magical, the magical fairy tale story of the team discovering something they didn't know when the sprint began and the got with a product, my owner, and they decided to take the rest of the scope out of the sprint to address the big thing. And that is, I love that fairy tale. It's my favorite one in the world, but more realistically, the product. Owner or product manager says that's great. You found that, but we need it all fixed. And we need the other thing we committed to done. Yeah, very common, right? I mean, this happens all the time. So what do you do as a, an incoming scrum master? Yeah. You hold up a cup and you pour liquid into it, tea, coffee, whatever, and say, this was already full. And now you say you want more. Let's keep pouring and it's going to run over. You've seen that GIF somewhere. I'm sure. you have to talk about what can be reasonably achieved by the end of the sprint. It's fine to keep just throwing things in the sprint, but you're not going to make it, right? With everything, you know that. So, why set yourself up for failure? Why do that? When you can say to... to the product owner, this is not going to happen. You get to make a choice here, right? But this is not going to happen. So we learn something new, we're going to go with the highest priority item because it is the highest priority item. Consequently this other thing has to slip. Let me help you understand how we can get to that one, which is the next priority item maybe. In a subsequent sprint and to your point, yeah, assist product with stakeholder management and communications. It's just all about transparency. So be transparent, but engage with your product person as a partner, you know Sometimes the development team are the ones scope creeping things. Sometimes the development says, oh, we can, we can do this one extra thing. It's no problem and, and to be honest about my experience, I'm trying to think, I want to say it's been, I've, I've, I've been coupled with tons of product owners on the team that one little, one extra thing, one extra thing or, or, or development like development managers, but that maybe that, what I'm trying to say is. Not, not, not like development leads, like senior developers have more authority, but are on the team. I'm talking about like development leads who are not on the team. Who press the team members because they're like in their, their business reporting structure or whatever to say, Hey, you got to add this thing to your sprint and just get it done as you know, I mean so, so there is a almost, almost, almost that shadow backlog we were talking about last podcast, almost that, but maybe not quite that. Like there is that scope here as well. It was like, that is a real scenario, right? So these are tech leads or maybe architects that are not on the team that say, Hey, Hey, you're doing this great work. By the way, why don't you just enable Data Dog and Splunk Logging, too? Yeah, these sorts of things happen. And as a scrum master, what are you looking for? You're looking for signs where work is added. And again, you're not, you're not there wielding a hammer. All you're doing is you simply asking your team, can we deliver the original scope? Yes or no, right? If we can, great. Now, the next question, can we deliver the original scope with the Added scope, right? And have a discussion with that tech lead architect, whomever and say, we're full right now. If you want us to put something in, we will try our best to do one of those two. Maybe don't commit to everything. Just say, well, we could just make a few entries in a log file but that's it. Data doc. We can look at next. Well, this, this, this, like the architect coming in and saying like, Hey, everything you're doing is great. And these features work really well. But, I have this new data observability. You know, requirement on you, but it basically is like they're injecting, they're not injecting work into the sprint, meaning like work to be done in the sprint on the product, they're injecting more of like a, they're like changing the definition of done in the mid sprint to say like, well, the definition of done is everything has an automated test and everything has observability in the logs and everything has can be whatever. Feature flag and 80 percent code coverage. Yeah. Yeah. And they're coming in and like injecting to say like, Oh, now we have this integration with data dog or whatever, you know what I mean? Like, so that got injected mid sprint. We decided, and now it's, it's getting added. Like I, as this has happened to me many times, several times the, the. The tactic that I've always tried to employ is to, be like trying to jump onto a train car as, as a train car is moving as I'll try to agree, Hey it's mid sprint or like more likely it's like the first or second day of a sprint. Rather than derailing all of our sprint goals can we pick up your requirement next sprint and start from you usually people giving these requirements will say like. Oh, I don't, I don't pick it up next sprint. I don't really care as long as you start doing it and bake it into your definition of done, I'm happy. It doesn't really matter if it's like eight more days they, they won't really push back a lot on that. I'm trying to think of that's true in my experience. Some do. Some pushback. Some have. Cause they have a hidden agenda somewhere. You know, they promised a leadership or a manager that they'll have these things. In my example, I think this happened one real example I can offer here is not so much logging, but it was more on app monitoring. You know, somebody had promised management that they will have application monitoring in place by the end of a sprint. And it was never in the DoD. It was never even considered by the team. We acknowledge that that would be a good thing to have in the future. But in comes this architect that we want you to do this actively monitor the app and try doing X number of logins every minute. And if a login fails, then you know you're... Your app is, is vulnerable. So restart, do this, do that whatever, whatever it was. So these things happen, but a scrum master going back to the kind of the, the, the podcast, the scrum master should say, that's a great idea. Can we create a story for that in the backlog? Immediately what's happened here is two things. One is you've decoupled the work from existing work in the sprint because it's another story and it's gone in the backlog, not in the sprint. To be prioritized, considered with all the other stuff, normal stuff that a PO does going forward. So that I think helps you pave the path to say, yeah, we, that's great. That's great insight. We should do this work. It's in the backlog. Let's revisit that when we look at the backlog, i. e. not this sprint, right? Let's talk about the elephant in the room of role confusion. Oh god, that really is an elephant. Role confusion. Role confusion. Like, to me, it's, it's usually it's people outside of the development team. Usually it's, it's stakeholders who don't understand what Scrum Masters is supposed to do or development leads. Who don't understand truly what Scrum Master, or, or, or also people have never seen a successful Scrum Master interfacing with a team, so they don't really know what they, basically, it's anybody who doesn't really know what an effective Scrum Master looks like. That's a lot of people. It is a lot of people, which is, which is weird that it's a lot of people. I mean basically having to teach the market what the position does aside. I know, we're like, putting everything aside for a second. This is a tough one. Like, I can think of, every developer I've ever talked to, developers as well, that have said, well, what does a scrum master do all day except show up to the daily meeting for 15 minutes. This is so, so, so common, right? And it's more prevalent at organizations where they're kind of at the beginning of their Agile journey, so they haven't seen a whole lot of Scrum Masters that have been effective. And then they formulate their own opinions of what a Scrum Master does. Right? So they say, well, a Scrum Master does this. A Scrum Master is the person I turn to to get metrics. A Scrum Master is the person I turn to to figure out how to You know, how to rebuke or reward a team member, for example. Right? So, these things are very, very, very common out there. More so, not so much in the sort of IT world where a lot of Scrum Masters play, but outside in the other... Business domains, hr, finance, legal, they, they, they haven't heard the term scrum master. Yeah. Right. So they don't understand. They say, well, scrum master, what are they doing? Then somebody gives a one or two line explanation and they say, oh yeah, that's a project manager in their mind, so I can go to them for everything. All in sundry, go do this. Yeah, go do that. Right. So how does a new Scrum master deal with this role? Clarity. There's role confusion galore. But role clarity is important, right? There's somebody did a, I'm trying to remember who it was now and I probably should give due credit where, where it's due, but somebody came out with a couple of diagrams, kind of like the South Park characters and what is not a scrum master, what is a scrum master, right? Scrum master is not the team's coffee clerk, the team's note taker, the team's secretary and on and on. There's six of these and then there are six more. What a scrum master is, is a facilitator, is a team coach, is a this, that. So, yeah, I mean, you can have that, but how do you communicate that to everyone? Well, I mean, I would, if it were me, I would, well, first of all, I would not be in a job as a scrum master because that's why I work in product. But if it were me, I would I would start with the person that you directly work for. Whoever, whoever has hire slash fire authority. I don't know what they call that. reporting person, whatever, whatever. You know what I mean? Right. A hiring manager. I would start with them to get role clarity there to say, and every time someone asks you to do an additional task, I would start by cycling back through that person and say, Hey, I'm doing this, but I want to get clarity that I'm doing it as a favor, so when I push back in the future, when it becomes, when it becomes too much. That pushing back is not seen as being as, as, as, as picking a bone of contention. Yes, I love it. Oh, that was so, I don't even know if anyone will understand what that, I can barely understand what bone of contention means. No turkeys are harmed in the making of this podcast, by the way. Only a few. if the person that you directly work for is in complete agreement with your role and what it is and is not in your job description... You know what I mean? What is and is not expected from you. That's a better way to say it. I don't like saying job description. If the person that you're working for is directly aligned with you, 100 percent agree with you on what is and is not within your responsibility, your purview. When you do stuff above and beyond, they should write it in like the little yearly end of review. Like, oh, Brian went above and beyond. Yeah, exactly. So good. Like, oh, he got coffee for everyone. Above and beyond. Coffee's not my job description. It's not expected of me. Nor am I going to get penalized when I don't do it like that. But what I've directly observed in this category is Scrum Masters get into this mode of, of, oh, well, the project manager from the PMO wants somebody to write down at the end of the week in their spreadsheet all of the deliverables that you sent to production and what I mean that that kind of stuff is like, Oh, have the Scrum Master do it, because, because everyone knows it's a nonsense task. The Scrum Master, under the banner of Just knocking down blockers and, and, and keeping the team, keeping the impediments away from the team. Kind of volunteers just to do this garbage work. You know, hey, someone's gotta go, someone's gotta go, the toilets are all backed up, someone's gotta go plunge them. The scrum master volunteers, look, I'll just do it. Get it out of the way. You know what I mean? But if the person that the scrum master works for directly, even though they don't work for him on that team, every day, from day to day. knows as well. This is a nonsense task. Scrum Master is doing it. If the scrum master wasn't here, they'd ask a developer to do it. It would be a complete waste of the developer's time, right? Those kind of things, things like that. It would be good whenever you do something like that to go back to the person that you work for, the person who hired you the person you report through, right? Who does your yearly appraisals? Let's be honest. If you're doing tests like that, you have yearly appraisals, right? You do. And your bonuses are tied to that or your salary increases. Yes. Sorry. This year we got to move you to the basement and take away your red stapler. Yep, exactly. Don't burn down the place. So look, I agree with you first of all wholeheartedly that You need to make it visible that that's not your... Responsibility, you're doing a favor. I know Scrum Master is supposed to foster the whole concept of easing flow. But, come on. Plungers and toilets? That's a different type of flow. Anyhow. Nope. Same kind of flow. Yeah. Yeah. Okay. I'll stop. I won't say what I wanted to say. What I will say is this, though. If you're doing things for people that are outside of your Sphere of influence, let me use that term, right? Somebody came in and said, you know what do we put into production? Give me a, give me a spreadsheet. You give them a spreadsheet, they come right back and go, Can we get a chart with this stuff? Cause numbers, right? We want diagrams, pretty diagrams, give me a diagram. If a scrum master willingly goes along and does that, Yes, absolutely, make it clear. To those that you report to that this is something that you're doing as a favor, right? That that's a given. You've got to do that. Otherwise you'll be doing it as a career. The second thing is as a scrum master, you got to think about this whole thing as a problem. The problem here isn't that they're asking you for this. The problem is there's no way for them to get this information. Yeah. How do you solve that? Most ALM tools allow you to create all kinds of dashboards and widgets and blah, blah, blah, right? So do that and say. Oh, yeah, you want that. Here's a link. Oh, by the way, in the future, you can hit that link. You'll get the most latest information. Anytime you want. Anytime. Right? If there's anything else that you need, talk to my boss. No, let me know. And I'll talk to my boss. That that's usually a good way to go for a scrum master. Yeah, a bad way to go is to say yes. Yeah. Right. If you keep saying yes, you're gonna get more back. Things thrown at you. I mean I agree with you and want to move on to this category and I might clip this out of the podcast. However, like the people that just say yes and you know, bend over. Yes men. Yeah, they like, they advance in the organization. They do. The, the thing that you will deal with as a scrum master that I want to touch on, because I really like bringing it up because a lot of scrum masters, as soon as they hear what I'm about to say. Are going to cringe. And do that, oooh, they're going to do that, that face. You know what I mean? They're going to do that. Is the pressure to constantly deliver more velocity. More! We want more! More velocity. Shakespeare's Oliver, please sir, can I have some more? Why is there 10 percent less velocity? Velocity this sprint. Hey, don't show velocity to leadership cause it's not a good map, but also they went to CSM so they know velocity. That's what they want to see. Hey, listen, I think the agile community, the trainers, you know who you are. Don't train leadership in velocity for God's sake, train them in delivery of business value. They're leaders. They're not, they're not managers. Don't tell them about velocity, otherwise this happens, right? We want more, we want more, crack the whip harder. Oh my goodness, there are so many things you can say about this one. Yeah, anyway, but I mean, this is a very real thing is, is stakeholders or management or leadership or whatever you want to call them like they know velocity because that's the one metric that People can see easily on inspection because most tools make it apparent right there. And some frameworks slash tools slash processes build velocity across teams in as a benefit as, as if that's what you should be doing. Right, right. Yeah. I'm like, none of which shall be named on this podcast because they're all. Yeah. Yeah. There are times that I feel like a cursing bleep would be really good in our podcast. But this is very real. So velocity pressure leads teams to overcommit. Velocity pressure leads teams to say well, you know we're the one... Manager walks in the room or the one senior developer walks in the room and the team says we can do 20 points and then one person is like 20 come on guys. You can we can pull together and do this You can at least do 85 when your normal loss is 20. I mean, I sure like I'm facetious No, but you know also this happened this happens all the time This is this has happened on nearly every team I've ever been a part of is you have you have some Leadership stakeholder or senior member or somebody with something to prove that tries to be the hero to say we could do whatever, whatever our velocity is, plus whatever they think the appropriate amount is so I Yeah, absolutely. Listen, where I've seen this really prevalent is in Situations where there is a PMO, PMO's chart these things and they say what's the same team, they should be improving every sprint, right? I ordain because they have no other way of thinking. Like coming up with this, I ordain that there should be a 15 percent improvement sprint on sprint in the velocity delivered. If that's what they're measuring, an incoming Scrum Master can easily, very easily meet that goal. Yeah. Right? They got to talk to their team and say, look, we want to do 15 percent more. Can we do 20? Do I hear 25? All you have to do is estimate everything higher to the next level. So what's a three point story is now five. What was a five is an eight. Yeah. Instant velocity gain. Yeah. Yeah. The team's going to game it. Right. That's the bottom line. So I think I scrum master who gets wind of what's happening here, right? They need to move into the coaching mindset. They do to the organization. That's a much better way of saying what I was going to say. They need to develop a spine and say, look, don't, don't look at velocity. Look at what we're delivering instead. Well, let me, let me, let me do the arguing agile. Let me pull the arguing agile today of arguing agile. Like we need that would be better if I had somebody jumping off that chair. Yeah, the arguing point here is that most team, most scrum masters, we're talking about scrum masters is they do not provide any other metric back up to the business. That is a failing here of why the, if the business is anchoring on velocity and pressing you on velocity, you've not. Provided them with business value of new, not provided them with throughput. You've not provided them with a reduction, increase, whatever, a cycle, timely time, that kind of stuff. You've not provided them the, the, the indicators which, which point them to better problems to work on spot on. Absolutely correct. Right? So when the organization and other people within it are focused on velocity alone, stand up and say, Why? These are just numbers, right? What have we delivered that is of value to the organization? Have we added new business value or have we reduced our risk? Right, which is the whole work on technet reduction, all of that stuff. If you haven't done that, if you haven't had that conversation, rather, then you're just going to be suffering this, this, what's the word? I mean, this fate, I guess, ill fate of... Increased velocity. Sprint and sprint. Yeah. Yeah. You're gonna be caught in this trap. Yeah. If you can't use it. So, and it'll be seen as a failure on you, by the way. Well, you, well your, your leadership, your P m O, all the people we've been talking about in this tech leads, whoever it is, that, that doesn't know, they just don't know any better. They're not going to find a way outta this trap. Like, it's up to you to find a way outta this trap. So I, I would propose different metrics. I would, I would just start, honestly, as scrum master, I would just start gathering these other metrics and start presenting them along with because if you just hide Velocity, people are going to start asking for it. Right. That's fine. If you're at a company and they've never asked for Velocity and you have never shown Velocity, good job. Yeah. Ignore everything I'm about to say. If velocity is your only metric, start coming up with business value, start coming up with a cumulative flow, start coming up with cycle time, lead time. Come up with all those. See what the business takes to. And you'll be able to show ups and downs over time, just like velocity. Right? And downs. And then just slowly pull velocity down away from them. Until, eventually, they don't even look at it anymore. Okay. And maybe you don't even need to show the ups and downs of velocity. You can just show velocity to say it's within one standard deviation of our mean. I wouldn't even bother. Listen, when you get to the point where what he's talking about you're delivering business value and you show that up front. As a scrum master, you get to decide the order in which you're showing these metrics. Yeah. So delegate velocity to the end. Yeah. And two sprints later. Take it off your whatever you use in PowerPoint or whatever. You shouldn't be doing that, by the way. But, yeah. So just, just don't even talk about it. Just say business value delivered. And here's something that can help you. Right? So listen carefully. Just plot sprint on sprint business value delivered as a metric. Now, if you're an incoming scrum master, which is how we started the podcast. Just do that. Business value delivers. Sprint one, sprint two, sprint three. When you get to sprint five or six. You can be a little bolder and say business value committed to business value delivered, right? This is what I usually call X slash Y X was committed to Y was delivered Okay, when you get to that point how you get to that point successfully is by partnering with your stakeholders by your sponsors and say We're thinking about taking on these things in the next sprint. How would you rank these for business value? Pick a scale, but keep it consistent, don't change it. One to five, one to ten, doesn't matter what it is. One to three, yeah. Whatever it is, right, just keep it the same. And then say, you said this was a one, which is the highest priority, or whatever. Three, doesn't matter, right, just stay consistent. And say, we committed to a one. We delivered a one. We're good. Or we committed a three. We only did a two, right? But don't leave it like that. Don't say we committed to a three. We delivered two. That's only half the story, right? The other half the story is we committed to a three. We only delivered two because dot dot dot fill that in because right? Because we learned about this one issue facing these five customers that we jumped on right away. And we worked on that. So that's something that you, the stakeholders didn't even know about before the sprint. So you didn't get to rank business value on that piece of work, but it made our customers happy. So that's why we're a little low on this one, but we'll pick it up in the next sprint. So much better as a. You know, as a story, then 48 story points and we only delivered 39. Right. Those are meaningless numbers. moving on. The other thing that could happen is you could run into technical disagreements that you as a Scrum Master Find yourself facilitating to, I think of technical disagreements meaning like not meaning technologies, because usually things like that get resolved pretty quick. Yeah, they're pretty much dictated anyway. Usually it's, it's like how, how many bells and whistles we should put on a solution is usually. That's a school question. Yeah. Yeah. Yeah. That, that could end up being this, this the technical disagreement, for example like usually things that involve auditing have the biggest disagreements. In my, in my career where we have to do something, but we want there to be an audit log. Well, how much stuff needs to be in the audit log? In order for it to comply with the requests of we need mobile audit. Yeah, yeah. I've come across that specific one at least a couple of times. And both in regulated industries just so happens, right? So, the developers are, A, I have to say, they're thinking about this the right way. They're saying, well we need to make sure that our work is auditable, right? That's fine. But then there's degrees, you know. So, two things I want to say about this. One is. Decisions like that, you really want to lean on your architecture, right? Lean on enterprise architect, solutions architect, if you have one. Or if not, just, just the technologist who says, I kind of have a good view of how this should work, right? Senior developer or founder, if you have a founder that's a technical, that helped build the system, them as well, because a lot of times when I've been in this situation where I've been caught in a technical disagreement, also, you're, you're disagreeing on a technological solution because the people in the room are probably trying to future proof a solution and that's why they're trying to like they're not trying to gold plate this the the the issue but they are trying to say i want to make sure i take care of these edge cases that's that's the word that i was in my they're trying to take care of edge cases Before they crop up as problems. Product is usually the first person to, to help put guardrails on these conversations, but in case you're stuck with a product manager, I say manager right there with intent, who doesn't know anything, who doesn't know, who doesn't know anything about technology and just gets lunch and hands off to the dev lead, everything they need done. This I could easily see how this could be a problem, but nice thing is if you're a scrum master and you're on a team like this. And they are caught where they've talked about a thing over and over again for they burned 45 minutes on it it may be up to you to kind of cut the conversation off to say, Hey, I see we're not making a lot of progress. Why don't I get this other technical person or this other team or this founder or this architect or the senior developer, get them in the room, get the product manager who's asking you for a feature in the room I mean, give the appropriate people together and why don't we have just another session on this? And see if we can knock it out in that session. And, and I wouldn't go into that other session cold. I would prep the other people that are outside of the team with kind of the notes. Right. Your understanding as best as possible. So when they come in, they already have an idea. So you know, prep them, invite them, facilitate the session when it starts. And then I think they probably could take it away after that. I agree. I think that session you talk about facilitate that. But when you set it up, not only put in the agenda, what are the choices that are being considered? Also put in what decisions you want out of it and then say, here are the expected outcomes, right? We'll make the decision, then we'll procure this tool, whatever the tool that of choice is that's been decided upon, etc. So yes, you can have some structure around this whole thing as well. But here's what I wanted to talk about just really briefly here. An architect who says we should do something, right? Understand their point of view. Why are they saying that? So it's that whiffum, right? What's in it for me? So why are they saying what they're saying? That's one thing that a good Scrum Master needs to be savvy at. And say, oh yeah, they're talking about this because... And I'll just finish my thought about... all this by saying it's not just the architects. Sometimes it's other people like compliance, right? Compliance will come in and go. All that is fine. It's auditable. That's all good. But We have this regulatory requirement that we have to meet, otherwise no go to production, right? So understand what that is, have the architects consider it, kind of go top down because bottom up doesn't always work in this scenario, right? I, I came across this just really quickly not too long ago. Wow, four years ago. GDPR regulations in Germany. The, the client I was working with, all their data was stored in Germany at a data center. And when push came to shove and somebody came up with this idea that, Hey, look. We have this regulation coming up, everybody panicked, right? We had meetings upon meetings and in the end what happened is a decision was made to spin up a whole brand new data center hosted outside of Germany So all this had to be done in the same scope of the original project. When I say scope, I mean the timeline, obviously, right? There was more money involved here, but that was made available. Magically more money just came about when it comes to regulatory compliance. So, but, but a scrum master needs to kind of look ahead a bit and put it on their radar and say. They may not know about GDPR. What they can talk about is this data. Where does it live? Do we have the data secured, right? Is it, you know what is it, what are the two different security requirements and that people always talk about security, the data in flight and data at rest, all of those things, if you're not aware of those things, it's fine, you could be a great scrum master, not be aware of it. That's fine. Partner with your architect. Yeah. Right. And then just talk about it in business. Speak with your product folks and say, what if the data is not secure? Where, wherever it lives, where does it live, by the way? Right. Just so, so get ahead of it and then have the conversations and be bold enough to ask leadership for, decisions and direction. Yeah. Yeah., this is the end of the episode. Uh, I know we, we had a lot more points, we're going to cut the rest over to part two. So tuned. Yes. Lots more to come. Part two has lots more goodness. We'll see you there. That's right.