AA80 - What does a Scrum Master Do All Day (Part 1: the Team)

Tell me if you've heard this one before. Yeah. As a scrum master. Hey, what do you do all day after the first 15, 20, 30 minutes of your day? Stand up when you you're done running stand up and if there's not a sprint planning that day. Yeah. You don't do anything for the rest of the day. Right? What do you. All day. There misunderstandings out there, right? So people don't know what a scrum master does. That's a relatively new role for a lot of people. Mm-hmm especially older organizations, quote unquote traditional, they don't know what a scrum master does. What's visible to them. Right. Is a scrum master. Well, they do the daily standup. Sure. Once in a while they do the, you know, some of the sprint events, so other than that, what do they do? And so from their point of view, maybe it's a fair question to ask, right. Because they don't know. I figured the structure of this episode since, since Ayo, since you're here and we actually have a scrum master, like actual practicing, what do you do? What did your scrum master? We don't, we that's a different episode. We're like 80 episodes in. We still don't know what Om does. eighty episodes in.. I know you products, product guy. Yeah. that's my professional title, product guy. We should have a, we should have a guy. Cause I dunno if it's, if it's a product owner or product manager doesn't matter or just a director products, I'll just keep cashing the checks. Check casher. Yeah, so, what I figured we'd do for the broadest audience possible is we'll dial back the scrum master to the facts, like what is published in the scrum guide. And we'll start from there because I figure we can use the scrum guide as a guide for this conversation, walk through it. Yeah. And, we can try to connect it to experience. We'll try to talk about organizations without scrum masters mm-hmm so the 2020 scrum guide. Defines the scrum master as serving three different audiences. They serve the scrum team. Yep. They serve the product owner, which I'm gonna interpret as they serve product. Cuz the product owner is very, very specific. They serve product and they also serve the organization. So when you're like, what do you do all day? Well, you have three different stakeholders that you serve. I don't know if I dunno if stakeholders is the right person, actually that is, that is the right word interest groups. That is the right actually stakeholders is the right word because remember they're serving the product owner. I know you want to call the product, but they're working with a particular person member. Mm-hmm you can only have one product owner in, in, in a team. I think generally scrums are working with a product owner on a day to day. Sometimes they're working with a product manager, you know, going into these meetings where they're defining product, we're talking about product things. so loosely maybe, but we can just call it product owner product. That's fine. So, do you wanna start with product or you wanna start with the scrum team start with this team because I think people start with the beginning, just like you said, this, that, all right. So, so the scrum master serves the scrum team in several ways, including: bullet point 1, coaching the team members in self management and cross functionality. Mm-hmm now in the terms of, what do you do all day? Like, can you gimme an example of what this looks like in terms of, I need to make time to coach the team members in self management and cross functionality. So everybody needs to be able to work together where we're saying, okay, I always use this example and it's kind of funny, but it's real. Like if you win a lottery today and decide like, screw it, I'm I'm out. Mm-hmm then everybody else needs to know what you are doing. And someone needs to be able to, take over that. that responsibility you me to take you take me to your boat and that's where you need me to be taken to. Especially if you in the lottery. Yeah. Because someone can win the lottery to actually I've had a team member that decided, Hey, I'm gonna school in, in Canada. He was he's in India and decide, I don't know if he got, if he won probably the VISA Lotto or something. And he was like, I. nice. So now nice. The other members of the team have to know exactly what he was doing and be able to take it because he had, we had a bunch of spike stories that he was working on. So someone needs to be able to say, okay, you've done the spike story. I need to be able to know exactly what you're doing. Mm-hmm . So we have that cross functionality where I know what exactly is happening in the product. I can jump on and test. I can jump on and develop. I can jump on and do whatever it is. So the ScrumMaster needs to be able to make sure that everybody's working together as one unit so they shouldn't, they shouldn't be, oh, this guy falls sick today. And oh, we, we gotta wait for five days where he gets better be before we can finish this story. This sprint is at the end of sprint. We, I need to be able to say, oh, you, this guy's sick. Can you go ahead and finish that story? And yeah, that's one of the things that the scrum master helps out with with the team. One of the obvious things that I can cite here, for that first bullet, is this how many times a team member would say to the scrum master? Hey, I have this impediment and the, and I've seen this all too often, scrum masters is gonna go, oh, okay, let me go solve that for you. Right. And, and off they go, that's not an example of the team becoming, cross-functional or, or more importantly, self-managing, they're not managing themselves. They're simply saying help. Right. And then you run with it as a scrum master, as opposed to. feel empowered to solve something that you come across and if you really can't solve it, then escalate mm-hmm . So my first thing , to a team would be what have you done to try and solve that? Yeah. If you tried something, then tell me, because I don't wanna keep trying the same thing you've tried. Yeah. Mm-hmm right. It's not a slight on you that it hasn't been solved. It's simply just to collaborate with you and say, you've tried a, B and C. Great. They didn't work. Cool. Yeah. I'm not gonna try B and C cuz you've already tried them. That's why, so you're encouraging them to take steps to solve their own issues. Right. Become more self-managing So when talk about self management, right? You're talking about being that as a team where we, we get to pick what, what we do, what we work on. So we have all this backlog, that's got maybe a hundred stuff in it. We get to pick based on priority. We can say, okay, the product owner says, okay, we have out of that a hundred, we have 25, or we have this 10 that needs to be delivered. Then we can see as a team. Okay. I've got a guy who knows .NET. I've got a guy who knows Java and all this kind of stuff. We can decide which ones we can give to you in two or three days, you come and say, okay, there's this five items that we need delivered. But we know that based on capacity, some guy is leaving, going on vacation. And she needs to leave mm-hmm in about two days. Okay. Because of that, she knows the Java stuff and we don't have anybody else on the team that that is Java. So yeah, we can only deliver in the sprint, these four things, because that's the capacity that we have. So being able to decide the amount of work that we do and who does the work is where we, when we talk about self management, Where the team can say, okay, based on what the capacity that we have, the, the knowledge we have, this is what we can deliver, because remember, the whole point is to deliver a work in product, right? Mm-hmm . So if we say, Hey, based on the capacity and, and the knowledge base, this is the people that can deliver this work. And this is what we can deliver. You can tell us all day that, Hey, I want you guys to deliver this 50 things, but if we don't have the capacity or the people to do it, then we, it's not gonna work. This scrum master has to be able to know that this guy knows this, this guy knows this. This is the capacity. This is the velocity, all of that information together. He could pull all that stuff together and say, okay, based on this, I'm going to management and telling them, this is what we're gonna deliver. Like it or not. You can force us all you want after two weeks. Yeah. I that's all, we're gonna get, give you the devil's advocate here that, that I would like to talk about per bullet point is if your organization decides you're not going to have a scrum master, like we don't see value in, we think they only are there to run the center for 15 minutes and then they don't really do anything. If your leadership in your organization somehow is convinced and they don't want to fund that position, , who, who does this when you're not funding that position? who coaches the team members in self management and cross functionality? I think, , that falls to like a development lead or somebody who's real close to the team who interacts with the team every day, who is somewhat on the team's level. A development lead or a development manager or a tech lead, or a architect or somebody like that, who it falls on them to say, Hey, you guys figure out how to break the work up between you. Nobody should tell you the other thing we didn't touch on here about self management that I think is under self management is, , kind of what Om alluded to is when you have a problem, your team needs to talk amongst themselves and then go reach out into the organization to solve the problem you have a problem. You don't get to throw your problem over the fence and be like, well, we can't do anything until X, Y, Z department solves it for us. You're not self-managing at that point. No, you're not that's right. Sometimes the way that manifests itself is the team member would come to us, scrum us and go, Hey, listen, I just discovered dependency. I need this from this other team before I can continue with what I was supposed to be doing. What that looks like on the other side, when the team is self managing, is that team member doesn't come to the scrum master. They would've reached out to that other team, just try and solve that, that dependency and then only if that dependency wasn't solved, they would come back to the scrum master and say, we have this issue. Here's what I did. I didn't get anywhere. Can you help me? Right, right. That's one example. The other practical example I have is this. And I recommend people try this out. So we always like things that people can actually try out. Maybe sometimes at least, for your daily scrum, the scrum master usually facilitates the scrum. Try not showing up or showing up late one day. See what happens with your team? Are they sitting around waiting for you or are they thinking, okay, is scrum masters is late. You know, maybe they have some internet issues or whatever. Let's, let's just, self-organize let's get on with it. Well, somebody picks up the rain. Let's get to that one in, , well, I see it's for the team. You're talking about self management. I see for the team, why I'm I was gonna say, we're gonna touch everything you're talking about. We're gonna touch in bullet point number four, ensuring that all scrum events take place is positive. So, so here's another thing that people tend to tend to forget about the scrum master. You talked about the fact that, okay, someone can just go ahead and reach out, but here's one skill that people tend to forget. A scrum master is a people person. Right? I would hope so. well, he's somebody. There's not one, one of the big skills, at least for me, that's one of the things why I became a scrum master is that skill of working with people. A lot of developers don't have that. I, a lot of developers want to just tell me what to do. I'll go build my stuff and give it to you. And that's it. I will, I don't want to, I don't wanna go talk to somebody. I don't hang on. I don't wanna care about nobody else. Before random people on the internet disagree, I, I will disagree cuz there are some developers who there are, who are people who are a people, person, people, people, I was gonna say people, people terrible people person, but, but the point of me saying that is, but, until you get into become like a senior developer or a team lead or a manager developer, those are not the skills that are emphasized, in your role, but even, , a scrum master entry level, whatever, if there is such a thing entry level, you know? Even the most junior scrum master, like it is assumed that some level of, , soft skill, some excellence at dealing with people is involved and that's why you were hired. Exactly. That that's a number one. To me, that's a number one skill as a scrum master you have to be able to be able to relate with people. Yeah. If you don't have that skill, your career is gonna be short, lived. You have to have that skill. So that's one of the things where scrum master helps the team to do. Yes. There are gonna be some developers that know how to relate with people, but a lot, let's be honest. A lot of developers wanna give me whatever you want to develop and I'll build it. I don't care about all these other people. I don't care about the stakeholders. I don't care about management. I need someone to actually go talk to management for me. I don't need to talk to anybody. I just need to code. I'll give you beautiful code. When you ask me to go talk to people, that's where you're gonna screw up. That's your job. yeah. So that's, that's why Scrumer is needed. Somebody who can take those impediments, which is another point we are gonna get to. But yeah, well, let's deal with that one now, since we're talking about it and I know we can skip around it's it's our podcast. We do whatever we want. That was number three, then causing, causing the, the word, the terminology here is very strange to me. I don't know why causing the removal of impediments to the scrum team's progress. Yep. Causing the removal. Well, I just, okay, fine. Remove the word causing, just say removal of impediments. Well, they, they deliberately put the word causing in there because what they're trying to say, at least my view of. The scrum master. Isn't the sole person who's responsible for removing impediments. Yep. They're saying empower the team to do that, right? That too. Yeah. So one day, if you're not there, what happens? So you're on PTO, right? What happens if they have impediments, they're gonna sit around and go, oh, I a scrum master, not you, no scrum master here. Right? So that's why I think they've done this. This is a change. And this scrum guide, this wasn't there previously. Wasn't phrased this way. No. tactically day to day, what does that mean causing like, again, again, you're talking to a person who doesn't understand why they have to pay the value of a scrum master. Yeah. The value of a scrum master. But it, your role is driving the removal, impediments causing the removal of impediments. Just, just having you there is causing impediments to be parted out of the way of your team. Yeah. Like what is that? What's that magical effect. How does that happen? Okay. Number one, because I'm a people person, right? So now the team is like, okay, you have a team. Not really comfortable talking to the network guy. So I have network problem mm-hmm or I can't have, have access to some database, but I don't wanna go talk to the DBA or somebody. So I come to this scrum meeting and I said, Hey, I can't finish this stuff because I need this query. And I don't wanna talk to that DBA guy. Yeah, yeah, yeah. I can't get access, but I need someone to gimme access. So now describe myself says fine. I'll be the guy to go set up a meeting with, with that DBA guy and, or, or create a ticket for you to have that access that you need. Oh boy. That's bet. That's part of it. Om my bet. You, I see you sitting there with like a hundred stories of, cause I, cause I know, cause I, cause I, I can tell you stories of , sometimes your team requires an individual to go write a ticket and then as soon as the ticket goes through the queue to show up at someone's desk and sit there next to 'em and be like, Hey, I just wrote you a ticket that is true. did you seriously write me a ticket and then come over and sit at my desk and talk about the ticket you just wrote. Yes, I did. Yeah. We need it resolved now. Like not, not working in an office in a nice way. Not working in an office has like, it made me forget a lot about doing that, but I remember oh yeah. Doing that a lot. It's real. Let me just say that. Oh yeah. Actually it's real. That happens. Have actually done that a lot where, oh man, like where you, like, I, at a previous company, I formed those relationships to say where I get the team can say, oh yeah, we have this stuff everybody's like, I don't know what to do. I'm like, don't worry. I got my guy. I got, I, I know the guy network and I know the guy in this thing, I call him up like, Hey, do you wanna go for lunch? We go for lunch. And while lunch, Hey, I just put in a ticket for your team. Can you go ahead and knock it out? Like yeah, food always works. I agree. I think that's a great way to do it. I think you just like, well, thanks for coming to this podcast and say, that was like, listen. If you are a scrum team, a cross-functional team, and you have a go-to person on your team who, when you need something from another department, oh, they know a person in that department. Stop right there. They just paid for their own paycheck, right there. Just be like, oh, don't, you know, someone in marketing, don't, you know, someone in sales that we could talk to to see how they're selling this feature. Don't, you know, someone in whatever. This podcast is quickly gonna devolve into either, Deming or it's gonna devolve into Taylor. I don't know which way is going. It's going more Taylor because it's like, if I can't put, , pennies and dollars to every second of your work, your utilization, then I don't see a need for you in the organization. Yeah. But what you, what you just said is basically the job of executives all day long, the job of executives all day long is to make one-on-one connection with people and use this one-on-one connections with people to, to influence it's called influence to move the needle in the organization. But now suddenly when you introduce that leader to work for a team of developers, now, we don't know what they do right now. Everyone loses their minds, insert meme here. The latency effect is real. So if that person didn't have that, I'll just call it that inside contact, right? What would happen? You could open a ticket and wait and wait, and then it gets closed and you reopen a new one. And that's typically what happens, sadly, because people that are working, those tickets are incented on closing tickets as fast as possible. So all of this is, is just, all of these are vector forces against basically against the team. And as scrum master's job is to reduce those, to minimize those and so people that are smart, you say, you make contact and you call in you cash in favors all the time, right? This is real life. This is what, this is what people do. That's how you make progress right now in lieu of that, this is, this is a response to the person who says, what does scrum master do all day? So we didn't have one mm-hmm, try that by the way. Try for sprint, not having a scrum master. See what happens. So, the latency effect is the team's wait for this, in this example for the impairment to be resolved. And it's a, not only is it a knock on effect, they wait, so nothing gets delivered. Mm-hmm and then people that are consuming that work wait. Right. That's a lot of money. So the scrum master's salary, I mean, whatever it is, that's a scrum master's costing you. Yeah. They pay for themselves in no time. If you don't understand that, okay. Then you really need to go sit in a scrum team and observe a scrum master, like shadow them every day. The other thing I would point out is if you don't understand that you should talk to your finance people about the cost of delay in the organization. Yeah. And talk about if, if I had a person I could deploy to make sure that the cost of delay for every ticket that I write for another department to work on, when I'm throwing my tickets over the fence or whatever. If that number came way down to, I don't know, pick a number outta the air, 50% of what it is now, how much money would my organization save? I feel that the thing left out of the I've said this many times before, so it shouldn't be shocking. The things left out of the scrum guide and why not is connecting this to the rest of the business, rest of the business, being HR and finance and executive,. So I guess the, what I'm saying is my causing the removal of impediments. Okay. Who does that when there's no scrum master? Well, obviously it would get distributed to the rest of the developers. So whoever ran into the problem will have to go track down the problem and figure out, you know, is that individual developer gonna spend time to learn the different hierarchies in the organization and learn their team structures to figure out who the people are, what their schedules are, where they like to go to lunch, you know, who they talk to when they're available, what days they're in. Well, now that we're all remote, what days in the office they're oh, this person's in the office on Wednesday is usually cuz whatever. I mean they have meetings or whatever. are you gonna pay for that? And how much is that worth? Well, how much is a reduction in the time of the tickets worth to you? Does anybody ever categorize that? I would not expect if the scrum master is deployed and brings finance into the equation and brings other departments into the equation and puts numbers behind them, then it will start paying a very clear picture if it's just the individual developers doing it. I think of the developers that have been scrum masters on, on my team. They, they go to, they go to resolve an impediment and they'll work on it on the side or whatever, but they'll pick work up and, they would rather be developing than trying to, you know, crawl into other departments and figure out who's who, and take people to lunch and stuff like that's a, that's not that it's just, that's not their job. So basically at, at, at the, my end of year review, when I get incentivized and I'm looking for bonuses, I spent all this time tracking down these bugs and track, figuring out who was talking for this system and who approved whatever for this system and all that time, I'm not developing. So all my metrics are going down, down down every minute I step away from my desk. I'm not saying that is the correct incentive plan, but I am saying if you don't have a scrum master, this is what your developers are doing. They're wasting their time driving out in the organization. So now you have a development lead doing it. now you have a manager development doing it, who I would argue are even higher paid than your individual developers and shouldn't be doing it. I agree. Absolutely. Yeah, definitely. That, that definitely helped out. Trust me at that company I worked on that was like one thing where everybody can say, Hey, Ayo's got this guy. It was mostly like a lab guy, right. And everything we did had to go through the lab. So if QA said, Hey, they want to test the stuff. And the process is actually you submit a ticket. It takes this long and this and this and this, I can just cut all that red tape. I can go to my guy, call him up here in the office today. You wanna go to lunch? We'll go to lunch on the way. Walking back from lunch. I say, Hey, I put in this ticket, he's like, send me the ticket, a number. I send him on teams. He looks at it. He says this guy's working on it. He calls that guy. Boom. Yeah, all that red tape of two, three days of setting up and other stuff is done. But a lot of times, most people don't see that value. Just like you said, people don't see that value management. Yeah. They see the work being done. They don't know what you did, right. To get to that point. I don't think it's transparent enough just because of the way that the organizations are run yeah. I agree. It's not transparent enough. And it's because we are still organized the traditional way. Not exposing these kinds of things. People that the value that's, the thing is all about value. And that's why I, at the beginning of my career, I worked for a credit union company that they decided to say, Hey, we are gonna work on process. Mm-hmm , we're gonna see what all this different process cost. Yeah. Like what are the fact that one, one of the big projects that we did that helped the company, I was fraud, a credit union, get a fraud. They call, they call in some guy picks up the phone, he creates a ticket. He goes through this. He goes through that. We cut that process by, was it like 5,000 hours where we create a, a ticket system? The credit union goes on online. Yeah. Puts a ticket, puts all the information they need. They ask them all the questions. Yeah. And once that ticket is created, it gets assigned to this team. And then based on the capacity of everybody. So we have five people on the team. This guy has five tickets. This guy has 10 tickets. This guy has two. Obviously he gonna assign it to the guy that has two. Yeah. He looks at it. Even before that, it cuts back the, the, the process of saying, okay, if it's below a certain amount of money, just pay it and be done with it. So if it's below 50 bucks, why even bother, just pay it and be done with it. So that right there is, is the first step. Once you put in the ticket and it sees that it's below a certain amount, it just pays it off and we are done. So that right there is a couple of hours of somebody getting that email, creating a ticket, looking at it and paid off right there. So all that process right there of that one little ticket system that we created 5,000 hours a month, that was cut off from this fraud analyst. Yeah. 5,000 hours of, people's time not being wasted. Even if the organization makes zero money off of it, it's like, Hey, you want to not have to waste 5,000 hours this year. and I dunno, take some vacation that day, kick outta work early that day, whatever here's 5,000 free hours Anyway, you went on to, to bull point number two, helping the scrum team focus on creating high value increments that meet the definition of done. Ooh. So like there's two things in there. Number one, you have to have a definition of done. So I guess , where's that, I guess that's part of your job, what that is now. I guess that's part of your job now, but the other thing is you're helping the scrum team focus on creating high value increments. Yeah. High value increments. Yeah. Which, which I would argue includes vertical slicing and a whole bunch of other. This includes everything about writing. Good stories. And that's one of the big things that people don't know about scrum masters. Yes. You might have a BSA on the team. You have a product on, on the team that are writing the stories, but you have to, as a scrum master look and see, is this whatever the story written? Is it valuable? Yeah. That whole having value to the team, it's like, it's one of the, the points that people don't don't look at the fact that, and that's. You have your 15 minute scrum, which probably includes the, the parking lot of another. Sure. Yeah. 10, 15 minutes there. Yeah. Could, and then yes, you have your, your other , events, the, the planning mm-hmm refinement. Refinement is one thing people don't look at refinement is a continuous activity. I'm looking at the, the, the backlog most of the time. Okay. Do we need this? Don't we need this. Do I need to, because yes, we have that one meeting where we talk about it, but before we get there, what do I do to make sure that we're not spending time and time and time just looking at this stuff. I've already spent hours refining that story, looking at it, chasing people down, making sure this guy is in that meeting, making sure that guy's in that meeting those are part of the things that scrum master does that is not looked at. Yeah. Yes. I can have a DEV lead do that or a Tech Lead do that, but does he wanna do that? The question is, does he want to do that? If I'm gonna pull on my experience here, I don't think the dev lead typically does do that. I, I think, , he can, when this bullet point isn't happening, there's no one kind of helping pushing the team. Hey, should we really be doing this low value stuff? Hey, should we really be pulling on the sprint, knowing that we got blockers or knowing that this is not the end goal of what we're trying to do, or this has nothing to do with the sprint goal. Why, why are we just taking it in cuz someone's crying about it or whatever. Let me go talk to that person. This is, is weird for a scrum master to be talking about this., because under this category I shuffle a lot of the product discovery efforts under this category. If product discovery is happening, you're never gonna pull things into the sprint that have not been properly vetted. You have an experiment proving, proving you have metrics proving that this item is high value to the business. Proving not suspect or, you know, the VP said, we need to do this. We have evidence that we need to do this. That evidence based approach is absolutely critical because you, you have more than one person, you know, giving their opinions that the VP or whatever, you're gonna get different orders from different people. Right. And you don't want that necessarily. But coming back to this bullet though, high value increments and DOD, those are the two things in that statement, right? No bullet. So as far as the high value increment DOD to the team, it's here, all the things we picked up in our sprint backlog mm-hmm right. It's the scrum master keeps them focused and says. Tackle these to the extent possible dependencies and all of that, you know, considered in the order of value. Right? So they get that after a while, they'll get good at it. D O D is same way. They may say, well, I'm done with this, right. And it's typical where developers finish developing the over the wall. It goes to QA and it's a scrum master responsibility to say, listen, this is one team we don't want to be dev completed and not done through testing. Yeah. So that I think is what this bullet is talking about is you're, you're essentially shepherding the team in the right direction to deliver something that is truly done. Yeah. By anchoring to what that means. What's the definition. Sure. They can come up with it jointly. You can help that. Right. You help facilitate that. If you ask them without facilitation, what's our definition of done. You're gonna get different answers. Right. And so then you ask, well, how, how is that adding value at the end of the sprint? If it's just dev complete mm-hmm . Yeah. Right. Yeah. and that's one of the, the big things that I I'm working on because setting up that meeting is like another team I just picked up recently. We need to that that's an artifact. The definition of done. Yeah. So we need to sit down with an agile coach and the entire team and say, okay, we need to write this up because obviously he's not written. Then it doesn't count. That's right. It has to be written up where everybody can see it. That's right. So somebody can call out and say, Hey, we said this in the definition of done this doesn't match that it doesn't count. Right. Right. Or we did not talk about this in definition done. So that's not what I'm gonna do. Yeah. So if you have it written down and put somewhere where everybody can see, that's one of the things that scrum master does. I facilitate that meeting. Mm-hmm , it's not, it's not even part of the scrum event, but it's something that has to be done. Yeah. So I say that meeting where I say, okay, there are three things that are important. You working agreements. This is how we treat each other on the team. And definition of done and definition done is something that the business care about the business doesn't care about. All the other stuff. Yeah. They care about. What, what do you say is where do you say my stuff that I told you to do is, is done. And it's a workable product for me to be able to take in. Maybe go do it, maybe. I mean, the devil's advocate on this point is, , if, if you don't have a scrum master focused on creating high value increments, , that meet the definition of done well, I'll rip it in half. If you don't have a scrum master defining your definition of done. I mean, the, the developers most certainly can define the definition of done, right? Yeah. now when you talk. When you talk about definition of done being a cross team thing, where all your teams have to come online with the definition of done. Now, we're talking about negotiating between teams is get, and we're a little more complicated. I expect like the development leads I've been at with, on teams like this, they just step in and say, well, this is what is the definition done's gonna be. that, that's how they'll deal with it. The, the other side of this of helping the scrum teams focus on creating high value increments, they'll say, well, can't, can't the can't product. Do that. That's what product's for. product is one defining if it's valuable, so that's not wrong. The product is the one defining if it's valuable, but who's delivering, what's valuable. It's the team it's and who's making sure that's happening. You're almost like the, the flag line at that point. Right? Just making sure you swing that stop, go based on what's going on. Yeah. To make sure that there's even traffic flow and there's no accidents. That's basically what the scrum master is doing at that point. But your point about the program level DOD and things like that, if it's not properly done, you could get into some real chaos. Sure. Yeah. There's headstrong people. Tech leads typically, or architects that say, Hey, listen, my team's done. When I say it's done. This is what we're gonna do. Yeah. And, and I've seen that. Right. And so he said, well, you, you're not alone here. Right. Right. So it's no good saying, well, we sink, you know, it's no good saying, well, the whole, your end, no boat's going down. I mean, the other thing out of this is you have a development leader, whatever who's across eight teams, somebody who obviously is overburdened saying like, oh, you have to document your entire architecture before you can do whatever. Or you have to give me full, you know, post mortem documentation and updated on confluence and write it in a spreadsheet. That's a CYA point. Yeah. But, but I mean, but, but they're overburdened. So they're, they're, they're injecting into your definition of done sure. Things to make their job easier. when the actual problem in the organization is they should get another tech lead and, and divide their responsibilities. So, but without a scrum master in the mix, it becomes much harder. It does to deal. It does with this, it's a scrum master who would stand up in that example that you cited and say, Hey, listen, it's the team. That's gonna decide the DOD. Right. We'll listen to you. And then we'll take what you say and park it over there. stormy. Hey let's would you like me to narrate? That's so weird. That's so weird that you're here. Thanks for coming to our . I've just it's poof, appeared. The final category for how the scrum master serves the team is value is ensuring all scrum events take place and are positive, productive, and kept within the time box. Let's start with the particulars in here. Positive, productive. Your, your role. Let's start with the one before that. Oh, okay. That they take place. Oh. That they take place. It's one of the things I've seen very, very often is scrum. Masters will simply boooooo that. And they'll say, eh, today we can cancel cuz we don't have enough attendance. I've seen that. I've seen that they do this well, we don't have the right people from, the stakeholder organization. So we won't do the review. Wow. To me, that's a big red flag. Yes. And I asked them to escalate that because if you don't do the review and you just continue working on the next thing, whatever that is is you're talking about sprint review or spring review doing the data, anything you don't have, it could be anything Mepo to show them finished product and get their implicit or explicit approval that they accept that mm-hmm Or if they don't find right, where have we missed it, get that feedback and build it in. If you don't get that, you've missed a huge opportunity. So I've seen scrum masters say, well, you know, they're too busy, like, well, okay. But that doesn't mean you cancel it. You escalate, you escalate above them and say, listen, people are too busy. The interesting thing about stakeholders is being too busy. And again, this is coming from the, the product side of the table. That's right. This is the product side of the table now. Yes. no, no, we're not talking about product here. We're talking about scrum masters. We've we've drawn, we've drawn boundaries. If that is a continuing regular problem in your organization. Okay. If you're a scrum master, listen to this. and you made it this far, like both of you made this far this way, like a, a thing that you could do is, not wait until the end of the sprint to demo your progress. Like ask the stakeholders when they have availability, look for it on their schedule. Talk to them, ask them them when, when the best time is, and then demo that tiny piece of functionality for them when it's best available when it's best for them, basically. Yeah. So, , if, if you have to go, like you start the sprint, you go three, four days, and then in whatever state the work is in, you demo to them cuz they already know they're not gonna be available at the end of the sprint. Mm-hmm like, I, I, I will lobby to do that with, with teams that find it difficult to implement cuz they have, their organization is really large. I will suggest this is like, Hey, don't start your sprint with like, you know, 15 work items or whatever. Start with one item that is for one person. And then at the end of a couple days, Set up your demo with that one person for that one work item. So like one work item, one user, one demo, work on that, and then that's out of the way and you can continue to sprint for your other, whoever else is in, you know, I fully agree with that. the other thing I would say, I tend to extend that chain a little bit and say, once you've got that demo done, typically it's the second week of the sprint, just because of the nature of things. But doesn't matter once you've got that in and you've had that stakeholder look at it and give you the thumbs up, mm-hmm ship it out to production. Don't wait on it till the end of the sprint, make it release out of it. No, that's just a stage gate again, right? Yeah. Sorry. I didn't realize people didn't release as soon as they were done with work items. They don't, I don't live in that people don't I don't live in that world. What do your developers do all day? If they don't release, as soon as they're done with things, that's a different podcast. Something else, What we're talking about falls under the fourth bullet point of scrum master serves as scrum team category in ensuring the scrum events take place in our positive, positive. Okay. This is where I'm gonna bring us back to our topic, positive, meaning, Hey, we're at our daily standup., the development team probably talked about, , we have this, , SQL migration thing because, , the marketing, team's cutting over to whatever where this team's cutting over to, customer's cutting over whatever. We have to do some operational stuff with our development team. Cuz maybe we're under the ability you own it type of, you know what I mean, company kind of thing. I've been in a bunch of teams like that you, your development team builds it. Your development team owns it. You gotta do the daily operation stuff. Scrum master. Yep. Keep things positive for us. Okay. We all know we have to do some kind of script. It's gonna take the majority of what we plan in our sprint out and replace it with this new thing being asked for by the business. We're gonna assume in this example that the product owner has done their discovery work. The pertinent discovery work to say, yes, this is what we need to do. Right? Like if, if we I've been through a bunch of SQL migrations, so excuse me for truncating this, , if we migrate the traffic out of this old database, we migrate all the records outta this old database punch 'em into the new database, sync the keys properly or whatever. And , we can take this old database offline. Then we don't need this other team to maintain this database. We don't need to pay this service. We don't need to pay for the bandwidth for shipping records back and forth or whatever. This is all the money we can save. If, if we do this now as a top priority and honestly you, the product owner probably are the one lobbying. To get this done, right. And your lobbying efforts. Again, the, the, the team moves forward on a certain cadence, but the product where all the product managers and the director of product, of VP products, whatever your product structure looks like. Sure. May not move forward on the same cadence as your team. And that's our requirement that they do, right? Yeah. Right. No, it's not a requirement. It's like Ayo saying, like, if we are moving forward with the mentality of we're agile, the scrum master can help here by highlighting in a positive manner that we finally got the green light. We finally got the thumbs up. We finally got the go head to take the system offline and save the business money to make a real financial impact. Now it's a scrum master's job to, , paint that in the most positive light mm-hmm possible to get everyone behind it. I used to be a pain at things that, that organizationally they would bring down and say, okay, we're gonna do this now. And I'd be like, why, why what's the reason behind we're doing this? They're like, oh, why are you asking that? You're just being difficult. Why does there gotta be a reason? Just do what I say mm-hmm and I'm like, no, that's not good enough. Yeah. You need to tell me why. I need to understand that you have taken into consideration that the customers, the employees, the future of the product, all these things. There's someone to say, like there's someone to paint it in a positive manner to, to help us paint in a, in a positive manner, connects us to the goal and move along in a productive manner. Yep. I love the way you, the way you said that. And I think from a scrum master, like, oh, good. Seriously. No, from a scrum master perspective, I think, I can't imagine the difficult role that you play because there's real conflict in you kind of walking that line and being able to, it almost seems contradictory and I imagine that it's a very difficult, a very difficult role to be able in particular, to paint a positive picture when you're potentially, you know, at this point you have to do this because the business says, said, you have to do this, but let me tell you why, why it's a positive thing. And, you know, so try, try to sell that. Yeah. Usually separating those people out, makes it a lot more palatable. and what I would say to that point specifically is that, you know what transparency is, is one of our pillars. So being completely and utterly transparent in why we are doing things is absolutely necessary. Developers are not dumb, and they do want to do the right thing and to move this product and this company forward. And they want to be able to realize the positive impact that their work is doing it jives them. I mean, I see them go like, Dang, we did that. Right. And so spinning things to your, to your point in a positive way to get them on board. So they're like, this makes sense to me. I get it. I can get on board with that. Yeah. So we're talking about make, ensuring that all the, events take place events, take place, which, and are positive and productive. Yeah. Positive, productive. So let, I guess, let me just summarize then. I guess you guys can decide if we're moving on or we staying there. So, oh, like I was gonna say, you should summarize because if we're gonna nitpick at anything in here, I'm gonna nitpick at the time box thing. Cause as, as a product owner, I could care less about time. Like if I'm, if my meeting is productive and we're getting feedback and we're, and like the juices are flowing, I do not care about time boxing. And that's exactly, that's one of the, one of the places where a scrum master has been looked at as a bad guy, because it's like, okay, you're right about that. Yeah. We scheduled this meeting for one hour. And we get to a point where we know, okay, it's 1155 and people are still talking. That's exactly the same thing with me. Let's go back to the, um, the, the, the standup. Yeah. Technically we don't have standups anymore because everybody's in their home, but where the standup it's supposed to be 15 minutes. and people are talking and I'm seeing the value there, this exchange of information. But the thing is, it's supposed to be 15 minutes. Right. And I'm like, okay, I see where you going? Yeah. It's supposed to be 15 minutes, but we talking some good stuff. Yeah. Like people are saying, okay, I have this problem. This guy, he has all the solutions. But it's like 13 minutes in. And I know we have two minutes left five. No, we have five more stories to talk about. We have two people in the team that haven't spoken. Do we keep going? I've been in the sessions before, you make your breakthrough and especially when you were working on legacy systems with developers, didn't create the systems. Oh, yesterday I figured out this is how this actually. Let's readjust the stories we're working on based on my new knowledge. That's the point of the standout man. Exactly. No, no, actually stuff like that, but hang on, stop where you can move to the parking lot. Yes. Not like you moved to the parking lot, but the one that I'm talking about is where, okay. We're talking about access to stuff, right? Yeah. Okay. I can't get access to this stuff. And there's this one guy that has that information. He's like, oh yeah, you gotta do this, this and this and this and this and this he's providing valuable information. Mm-hmm which is good for the team, but it's 11 it's 11, 14. So on the daily stand up as an event. Mm-hmm should it be 15 minutes religiously, just 15? Heck no. Okay. Maybe not the odd times when there's value, let it go. Right. Let it go for. I'm a fan of the 16th minute concept. Do we have a walk the board? I don't know if we have anymore. We don't board podcast. We we've never done one of those. We should probably, this would be a good, good time to cut to, like, if we ever did a, I I'm, I guess I'll have to research if we ever did a walk, the board podcast. So we haven't done specifically if, if you're walking the board and when you're walking through the work and say, Hey, let's look at the work that's closest to being done. Right. And say, what does it take to move this work forward to, to, to be done, done, done, done, done right. Done definition, done, done. Again, I think we've talked about this in a previous previous podcast, and if we did I'll link it, like, I'll go, I hate dealing with YouTube's linking but like, I'll link it. Woo. If we didn't, I'm cutting all this out. Move on to the next.. Next one. The product stop.. Since we have the product folks in the room, listen, let's talk about woo. How we help you. Don't need to tell me to move on. Cuz I've already moved on.