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

All right, welcome back to the arguing agile podcast. And we're going to continue the second part of our series today, talking about the most frequently encountered disagreements. Slash fights that scrum masters will get into. Yep. And if you haven't seen our first or heard our first, uh, part, please do so. That's right. To remind everyone of the framework for this discussion, we, we want to bring up the source of the fight. Uh, the source of the spirited disagreement. we're going to talk about an experience or two that we've had. and then we're maybe we'll touch on ways to deal with. I hope we will for each one. We will. We're going to go straight into our first topic. The scrum masters are impediment removers. So work items that get blocked because of external dependencies, something that a team cannot control, that starts fights. It does. It starts fights with other teams. Which is the, probably the worst thing that can happen is your relationship with other teams. Degrade as you fight over, well, you weren't ready on this date and this spring finger pointing, right. To try to absolve your team of problems. Which never is good. You know, the last thing management wants is a team blaming another team for whatever because management kind of looks at it and says, look, all, all of y'all should have figured this out long before a blocker started. So this, this is one of those categories that like everybody loses. when people are arguing over who is blocking whom and that kind of stuff, you know? Yeah, yeah, absolutely. Look, I'll give you a concrete example of this. So one of the examples that I actually lived through this is, the team, teams in this case they delivered everything they were supposed to deliver. You know, and it went to stage. Looks great. We had a UAT in stage with... Real customers, by the way. And yeah, I mean we went through the whole thing. There were some issues, they were fixed, they retested, everything was good. And everyone got together and decided, Yeah, this is all looking good now. Green light, green light. We're gonna go live on a certain date. Except, we couldn't. And the reason why we couldn't is because we were reliant upon the global security team. To do all of the things that are necessary, penetration testing, making sure that the OS upgrades are at a certain level, making sure all the applications are at a certain level, and believe it or not, honest God's truth, nobody thought about engaging them until it came to deploying in production, and they said, here's a package we want to deploy in production of all these things, and they went back and said, , no way. We don't even know about this stuff. So that whole deployment was delayed by eight weeks. Mm-hmm. because, and, and this was ex expedited too, because we didn't talk about it, right? Yeah. So if you are, if you are a budding scrum master or a Scrum master coming into an organization, think about every step that it takes to get your team's output outcomes product. To production right down on a sticky and talk about it with your teammates You might not have to come up with all the nuances and the details You might not know that this needs an NIS review and all of that stuff, right? But your team knows. Yeah I'm trying to think of what would be helpful in that in the situation. You outlined. I think a brainstorming a solid definition of done probably Would have helped at least discover this let's, let's say, for example, in an environment where a lot of the team members are offshore, so they're just like hired guns and they don't know they don't know about promoting stuff, they, they, they kick it over to another team and the other team promotes it over the fence they don't really know they're nor are they responsible for they're, they're now they're they're, they're responsible for the work, but they're not accountable. Right. Right. You know, which is not a great situation in my opinion, but again, only my opinion. But in that, in that case, if you had a definition of done, the team would say, Oh, well, we're our definition, our definition of done ends at the stage environment. And then the product owner or scrum master or somebody on that team, would, would have to say like, well, how do we get it over the finish line? If, if you, if you guys are going to bring, if you guys are going to bring the ball to the 10 yard line and stop playing the game, like what, what, like it's, I gotta know what to do at that point and then we got to be very, very crystal clear because like, we all know that handoffs are bad. Right, right, right. We all know that. Right. It's terrible. Yes. Like, if there's going to be handoffs in, in your, in your process, like this, which could be considered blockers, or, or work getting handed off to you, Right. That could be considered blockers, right? They're blocking your work. You have to know about those ahead of time. That's the difficult part of this. It is difficult. Listen, first of all, this isn't something that you learn in college, right? This is difficult, for sure. Most people don't learn this in their career. They don't. Unfortunately. Oh, man. So sad, but true. Most people don't learn it in their career. So aren't you glad you're listening to this podcast? Because you learn it here. Amongst other things. Yeah, amongst other things. So one of the things you need to be aware of is... Just do a field force mapping. I love the concept of field force mapping. If you're a scrum master, take a blank sheet of paper and and just get your team together around it and say we are in sprint 89. We're gonna deliver this thing at the end of the sprint. What does that mean? Where is it going? Right? Yeah, it's Oh, well, it's it's you know, it's it's just sitting there. It's waiting for deployment. So what does the deployment team need? Yeah, who is the deployment team? Who are the players? Do we know who they are? The DevOps team members? Do they know that this is coming? Right? Do they even know it's coming? Right? And do they have everything it takes? Are they ready? Do they have bandwidth? Well what's their lead time? Talk about all of those things. What else are they deploying in this time period that we expect them to? Yeah, because they may, they may be doing stuff that you're not even aware of. That's right. So that's the force field piece, right? So there's pluses and minuses in the force field protons and electric, whatever, how we think about it, how you will. But if they're deploying stuff that is helping you, that goes above the line. I just draw a horizontal line. These are things that they're doing and we're kind of on the line. So that's gonna drift us up or Down because they're doing security patches and they will not deploy our stuff while they're doing security. Sure. Right. So be aware of that. But the bottom line on all this is communicate to them. Right. Right. And say you, the DevOps people, when you mature as a scrum master over a few sprints, you're going to think about this ahead of time and go. We're going to deliver XYZ. Let's get ops. If you have ops DevOps, all these people coming in ahead of time into your team to understand the scope of what's being delivered. They don't have to understand the technology. Yeah, they already have. Skills to do that. They're technical folks. But they have to understand the totality of that increment and how it fits into the bigger jigsaw puzzle. If this is a regular problem in your organization, lining up things between different teams, because maybe have many, many teams in your organization and they don't have the maturity to talk to each other. They're very different maturity levels. Would you do that communication on a regular cadence and a regular process? You know what? Or would you set up a specifically like a, like an on demand type of thing? Like how might you recommend I get started to try to solve this problem? Yeah, that's an awesome question. So again, this is not a one size fits all because I don't know how often your own team and even the products of the teams in totality are going to production. Right. So it's, it's contextual. Probably all different cadences. Yeah, yeah. It's all different cadences. If you're a scrum master coming in, you got to figure out what your remit is. Is your remit to take things all the way to production? Is that your definition of that? Is that what's expected by your business owners from you, right? Business sponsors, your senior stakeholders that are actually paying for you and the team to be there. Or is it that you do the work? You get it to a staging environment, and then other people take over, whatever it is. Where's your boundary? Figure that out and do that ASAP, if not sooner, because that's going to help you. If you can figure that out, you can now engage with the right people ahead of time. So let's say, let's take a hypothetical example. Let's say you're a Scrum Master coming in. Five sprints from now, you have a product increment that's going to production, right? Until then, everything's just interim. It's stage, et cetera, et cetera. It's very easy for you to think, I've achieved success. Sprint one, sprint two, sprint three, sprint four, because my team is delivering to stage. And we're good. We can move on to the next stuff that we push onto stage. Stage becomes this holding ground. That keeps accumulating stuff that is not going to production. And then you look up from your table and you look at, from your desk and you look at what's going on really and some coach somewhere saying, What are you doing? All this stuff that's sitting in stage is waste. You go, why is it waste? We deliver every sprint, didn't we? I'm good, right? You're not because every single moment, something just just sitting there waiting to be deployed, especially if it's all like past past you 80 past all the regression automation past everything just waiting to go to production. That time is waste, right? That time is waste because if it's ready to go, you're waiting on get it out there. You're waiting customers. So Acknowledge the concept of time element of value, right? And embrace it and talk to people, right? If you have other teams that you're partnering with, several other teams could be deployment teams, could be DevOps, whatever it is. You'll eventually deal with them. That will not be a great experience, I would say. At that point, because it's pressure driven at that time. People are going to ask you questions. You are done, but you're not in production. Why? Oh, well, we're not on them. So you know what happens then, right? This is what happens. That's exactly right. Right? Blame culture. So don't forget about all that. Just say, Hey, listen, we're all, we're all in this together. So DevOps, what, what, what's on your agenda during this timeframe of July 1st to July 31st, whatever the timeframe is, because we're going to throw things at you that you need to put into production, right? What do you need to know? Here are the top level stories. Bring your people into our refinement sessions, whatever it is to understand the scope of it, right? And have your product person present to evangelize at a high level. What we're delivering and why right if they just say what that's not enough They have to say why because you're satisfying customer need if you do all of that and right people that believe me Good things will happen. But a scrum master has to be the person that is Cranking away the engine to make this thing happen, right? It's going to sputter away. It's not going to like smoothly, just idle away. It's going to sputter. That's okay. Expect that. But when that happens, know that you're getting the right behavior. Sputtering is the right behavior when you're starting off. What do you do when that happens? Don't look at it and go, geez, sputtering. No. Put both hands on the crank and keep doing it because it will get easier. If it doesn't, let us know, because it should. Yeah, that's that flywheel. Yeah, exactly. Another one that may cause a, difference of opinion is meeting fatigue. People commenting that oh boy, Scrum's got a lot of meetings. I gotta go to these daily stand ups. I gotta go to these sprint reviews. And do we really need retrospective ohm? Like, come on, it's, do we really need an hour and a half for a retrospective in a two week sprint? Can we get it done in 15 minutes? How about a 15 minute retrospective? I've seen this so often. Honestly, so often. Especially, hey listen, you guys that are Scrum Masters out there watching this or listening to this podcast, and you have a PMO, I'm sure you've heard from your PMO. Can we just cut our retrospectives down? Because we want developers to, well, develop. I'd be shocked if everybody listening to this has not, has not personally dealt with this item. Oh yeah. I don't even know if it's the team members. Like, more than half, I was gonna say three quarters of the time, but definitely more than half. I'll commit. I'll, I'll, I'll push all my chips onto definitely more than half the time. But definitely more than half the time. This is somebody who doesn't work on the team saying. Oh, I see you guys in a meeting. I remember a particular executive at a place I worked once. He would walk by the meeting room, the meeting room with like glass walls, right? He'd walk by the meeting room and say, Oh, the development team seems to have been in that meeting room for gosh, they've been in there for a long time. It seems like I've walked by three times on my way to get coffee and seen the development team in there arguing about something. They can't figure out what they're doing. 30 minutes. What we're trying to plan, you know six weeks worth of work or whatever, and random executives are. Complaining about seeing us talking or something but I like i've seen this way more than once way more than once across my career of of People trying to cut time boxes in half and people trying to you know What penny wise pound foolish? Trying to save a couple pennies. Yeah You know, while they throw 20s up in the air trying to cut, cut meetings short. All I have is gripes for this one. I don't have any good ways to push back on this one. Other than, other than when you hear someone saying like, Oh, really? An hour for retrospective. Can't you guys get that another 15 minutes? Other than, other than telling those people like, don't you have somewhere to be? Don't you? Isn't there an adult that can come claim you right now? Like that? That's like a c l M. But yeah, you could say, say that. Have you been drinking? Like how? No. No. You, if not, can I drink? Yeah, no, you can, you can definitely do that. But that's a c l m. So two things I wanna say about this. First of all, when you have, it's typically, again, sorry. It's, it's typically the PMOs that say, why is a team in hour and a half retrospectives that that's too much and then they have the basis or the rationale to justify their. It's their statement. They'll say seven people in the team, an hour and a half. It's this many hours they could be developing, right? Yeah. Right. So sure. As a scrum master, what do you do Now, first thing you have to recognize as scrum master is all of the other sprint events , including the daily standup, by the way. Okay. The retrospective is, well, one event you should not compromise on. Why is that? Well, think about. Go back to your training. Think about what Agile is all about. Inspect and adapt. If you're not inspecting, you can't adapt. Because you can't see what there is to change. But then when you see what there is to change, which is typically at the end of your sprint, you know what you did or you didn't do, then you have to change it. How do you change it? Through retrospectives. Retrospectives are the one thing that... Management, especially PMOs, do not understand because think about it this way. Do we have retrospectives in the waterfall world? I say this as a reformed, fully recovered project manager. No, we didn't, right? What we did instead is, we do a three year long project. And then we get together and we say, Hey guys, great job! Where are you going on vacation? I'm going here. Okay. And now, let's talk about lessons learned. Crickets, silence, because let's face it, who can remember three years ago, they do after action and they do they do lessons learned and they do stuff like that. You know, where you get everyone in a room and you do all that, but how are lessons learned actually implemented? They're not, no, it's, it's a, no, it's a, it's a, it's a lesson in documenting them and saying that you did them and getting signed off and then you eat it. Sausage or something. Oh, I don't know. It's a checkbox. It's at the end of the day. That's where it is. Right. If you're working in an agile way, right. Well, one of the things that, that works well in a short timeframe, two weeks. People can remember and as they go back to the podcast. You're a scrum master. What do you do? Are you gonna wait till the end of the two weeks and then say hey team? Let's get together and talk about what happened. Here's a board. We'll put things on, you know stickies on the board Yeah, you could do that again. What are you doing now? Checking the box. Don't do that, right? Here's why I say don't do that. You know, you're gonna have that event You already know that it's only 10 days away, 10 business days. So day one of your sprint, create the board, leave it there and tell people, communicate and say, anything you think about improving our process over the next few days of this sprint few, it's only 10, right? Put it on the board because you don't want to get into a situation where at the end of the 10th day, the teams really worked hard 10 days in a row. You had a demo. Let's say it went reasonably well. You had a review. Same often same thing. And then you meet for retros. The team's tired. They just want to go home. They just want to okay, we're done with this sprint. And now you're asking them to say, well, think back. What worked? What didn't? What could we do better? No. No! Right? Have them, give them the canvas, the whole time to put something on the wall. And... Second thing is, don't wait till the retrospective. You don't have to wait till the retrospective to say, Here are nine things that my team members put on the wall, and we're gonna talk about those in the next hour and a half. Don't do that. Guess where you do that? The Daily Scrum, which is a synchronization event. For the team. By the team. Yeah. not to really get radical over here. It's get radical, but like we had, we did have a podcast one in time where we, we did, where we kind of riffed on all of the scrum events. Yes. And one of the things that we said was, would it be possible to change your retrospective rather than to be a a big bang at the end of the sprint to do it in small increments? Maybe even as you finish work items, to do a retrospective on that work item. You know, maybe that often, or maybe it's a on demand, like a... A true kanban type of like, once three stickies are in the column of, we need to have a retrospective, it triggers the retrospective, and then maybe there's a time box for that, based on three items, or something maybe, but you, you could Try some different techniques. Yes. If, if you really get a lot of pushback on like, oh, you can't be offsite for an hour and a half, no one's gonna no one can take that amount of outta their workday and do something productive. I don't, I don't know what the pushback would be, but that, you know. Yeah. No hands on, hands on keyboards. Yeah. Yeah. The meetings have a purpose. I would say if, if you have meetings and you're using scrum and those meetings no longer have a purpose and your entire team agrees they don't have a purpose, you have a solid retrospective item to talk about right there. You probably should address that. Whatever that issue is, it's causing those meetings. And if you're, and if you're in those meetings, And you get done with them like, I think of like the daily stand up, I think of every team I've ever been on with a daily stand up is a half an hour, okay? There's a reason that those daily stand ups are a half an hour because I've been on a lot of teams that get done in seven minutes. Sure. The teams talk, they say this is my, this is our plan, we have not encountered anything in our work. Today or yesterday, that's going to cause us to have to refactor our plans that we did in sprint planning. When we spent the whole day planning, how are you going to do this work? You haven't discovered anything new. We're going to continue on as planned seven minutes done. Completed. That's when I go on to our day as you were. Yeah, but I've been on a lot of teams that want that think that they think that they can shortcut their sprint. Well, we don't need to spend four hours sprint playing. It's four hours ridiculous for two weeks, four whole hours, a whole a half day to decide how we're going to code and carry out every single task in this. Oh yeah, I guess four hours actually is worth it. Teams to try to shortcut that. Yeah. They pay for it because then in the daily scrum, they truly are using that time to re sync on, oh, we didn't plan this one deep enough. Can you and I get together today and sort of do some after action planning and decide now we need to make a new plan because now we're, now that we're in the middle of it, we realize that everything kind of stinks and we need new plans. So true. That was a song. Make a new plan, Stan. Deal with it. That's my suggestion. Get to the causes of why people are saying, Oh, I got meaning fatigue. Get to the causes of that. If their causes are... I don't like it. You should have hands on keyboards. I think you should be more productive efficiency. You can tell that person that to get outta your office.'cause you've got real work to do. You can tell 'em to please leave politely. That's right. Please leave politely And other things which might have gotten cut outta this podcast. That's right. That's right. But, but, but if it's real, like if it's your development team members that are bringing things up oh, we spend so much time on the daily Scrum and it's taking so long. There are reasons you can dig into and you can help you can help the team inspect The real problems, get to the root of those problems, do some five wise, right? And get to the root of those problems and fix those problems. If your, if your team members are falling foul of this, and you're a scrum master, pay now or pay later. But when you pay later, you don't pay the same amount that you're paying now. So, that's really the bottom line on this, right? As a Scrum Master, what are you doing? You're not enforcing scope. What you're enforcing is what is known right now. That changes, because the right now moment is different every day of your sprint. It's different in the morning versus in the afternoon. So, keep your ear close to the ground, listen to your teams. And be aware of all the noise that's happening outside of your team, right? This is where that impairment remover cap comes into play. The the noise comes in and that's when you need to basically be bold and say, Yeah, but here's what we agreed to. Yeah, so go with that. Be bold and and, and stay with it. Go forth and conquer. Let's, let's move on to a interesting one that I don't know where it really fits in the podcast. We're saving the best for last point that out. Which is. Cultural resistance, a scrum master, a scrum master, running into and overcoming cultural resistance. I immediately think of all the Indian teams I work with. Those, this is the number one, this is the number one time in my career that I've encountered true cultural resistance to Scrum. Because we just had a whole section on this podcast where we talked about, Om, you gotta do more planning to come up with plans. But maybe in your planning, You have a team lead who just tells everyone what to do. And again in my offshore Indian teams that I have been partnered with, if you have an anchor like that on the team, nobody is willing to say anything. Nobody's willing. So you can say like, Oh, we're a scrum and we got these transparency and respect and we've got these pillars. But the reality is those pillars are gated off by the culture of the developer. So, yes, I want them all, I want to hear each one's opinion, and I could call each one in a meeting or whatever, yeah, exactly are they really going to give me their opinion, or are they just going to say just enough to throw it back to their technical lead? Who's gonna give his input and then they'll figure out what their opinion is based on so because they don't want to step on toes, The thing about this that recognizes when we talk about culture here, we're not talking about organizational culture. Okay, we're talking about culture that is local to the geography where your teams are based. So if I pick that up, you mentioned Indian teams. Yeah, I mean, they're very prevalent. Definitely other teams also fit the mold. Malaysia comes to mind, so let's, let's go with India. You've got teams out there, offshored, all right? And you're gonna ask them questions. And you've got all your team members together. And you ask questions. Whatever question you ask, there's silence usually. But then the silence is broken by somebody. But that's not a team member. To your point, it's a team lead or somebody like that. Or an account manager. Because there are account managers coming to these meetings. They sure do, yeah. Listen, if you're a scrum master and you've got an account manager, From your contractor organization coming into your daily standup. You know what that means, right? Toss them out. They're not part of the team. You can escalate to them, but I'm not saying be rude. I'm saying. Connect with them first and say, look, this is for the team by the team. And if there's any issues, I'll let you know. And they'll be fine with that. Usually you have an account manager, , a true account manager, meaning like a salesperson slash business development type of person. And usually the contract. They're responsible for the contract. So usually you go back to that person when you have to have like health checks of the contract and stuff like that. You go back to that person. If you set expectations with that person appropriately to say, Listen, I don't want at certain meetings, Yes, have your architect, have your account manager, whatever, on those meetings. But the day to day, I want this team to develop as part of my culture. And you have to make it clear and explicit to that person. That this is what you're trying to do. You don't just want butts in seats. You want the people to start learning the culture of your organization, learning your culture, culture the culture of your geographical area. And you want them to start integrating with both. I really don't know. I can see the trade off. I can see both sides. I can see like, well, maybe your organization should bend to fit the, you know what I mean, the culture offshoring them. So, I think what you're getting at is geographic culture versus corporate culture. Absolutely, yeah. So, geographic culture is... pretty black and white. I mean, look, you understand what the culture is in China. You understand what the culture is in the Philippines or India. But your org culture is unique. It's unique. But you have to weave that into the fabric of your orc culture. So I, I, whilst I agree, you need to talk to those people that you're talking about, right? But, at the end of the day... What are you there for? You're, again, going back to the podcast. You're a scrum master. You're coming in, and you have offshore teams. What do you do? Two things I want to say. First of all, recognize people as people. Oh, for God's sake, don't treat them as resources. Because they're people. They have families. Oh, resources. Gotta squeeze. I know. Gotta squeeze that. Yeah, yeah, yeah. Gotta wring out that rack. So when it's like I don't know, 1 o'clock? 12? 11? Here? They should be in bed because guess what? Your equivalent time here, you will be in bed, right? Bring out them resources, I don't got a ring. So, okay, you can do that and say, well, you're just a hired hand, but you're going to get what you, what you get. That's right. I've had only very sporadic and very, very exceptional people that say. I work the U. S. Hours. Yeah, but you're in India. India. Fortunately, it's such a vast continent only has one time. So what they say? Yeah, because that's what my client is. And I look at that and I pause and I go, Yeah, but that's where my team is. Shouldn't I reciprocate? Right? So it's now 1 30 a. m. Your time. You're up on this call, right? No, it's not right. So first of all, you're a human being. I recognize that you have to You have to drive your kid, not drive, but even walk your kids to school, whatever. So go now, go right now. And then tomorrow, please, I don't want to see you online until it's 11 a. m. Or beyond that even, your time, right? As a scrum master, you need to ensure the people have that, right? Otherwise, you're gonna get what you're gonna get. So, the boldness comes in two parts. One is, talk to that team member and say, please. Nobody owns you, right? And the second part of it, the flip side of it, comes with you talking to your stakeholders and say, Look, is there a reason why we went with offshore teams? Oh yeah, that's right, cost savings. Guess what? Are you willing to give up all this productivity? You're not, right? And I'm helping you maximize the productivity. So, don't focus on the wrong metrics. Don't focus on people not being online when you're looking for them. Crap like that. That's just ridiculous, by the way. And the last thing is, when your team delivers, recognize that it is not individual work. Sometimes it is, but not always. Individual contributions. Your team took on the job of the sprint, right, and they delivered. So, recognize that, applaud it, celebrate it. And reward it. Alright, you ready for the best category? Oh, I'm always ready for the best one, man. Personal Conflicts. Oh, I knew this would come. Personal Conflicts. So, so, Personal Conflicts. Conflicts of personality clashes. I feel this category is so broad it should be split between like, On and off. Intra team. Yes. Inter team. And intra and inter. Yeah, yeah, right, yeah. Yeah, yeah, yeah. And people that aren't even on your team at all. Yeah. The scrum master, you could argue like, should the scrum master really have to do that? The scrum master doesn't manage anybody. The scrum master doesn't hire or fire anyone. They connect with team leads or whatever resource managers, whatever they're called in organizations. You know, hiring managers, whoever, whoever they're called. So shouldn't the scrum master just kind of. Walk around to the appropriate people to kind of see what know what they were observing, kind of stuff like, and at that point, don't they kind of turn into HR? Like I have a million questions with this topic is, let's start with the most direct. That usually I see a team member on a team has some kind of problem that develops over time with a team member on that same team. Sure. Okay. Sure. The team members can be anybody. They could be developers, testers, whatever. It doesn't matter really. Developers and testers. Yeah. Started with a good one. Yeah. Yeah, there definitely. Right. So two developers don't really see eye to eye, whatever. And all this stuff is festering.. What should a scrum master do? For front end and back end developers. Listen, a scrum master could say... I could do this all day. I know, I understand. Listen, DBA, not here now. That's right. Architect and literally anyone else in the world. Exactly, exactly. So a savvy scrum master worth their salt. They should really recognize the fact that Every team member is unique and they bring value to the team. Now, think about that sort of statement, whatever I just said, for a second. Every team member is valuable and they bring value to the team. I'll pause for effect. That's enough. Okay, so, if a team member doesn't bring value to the team, are they on your team? Think about that for a minute or two. Oh boy. uh, I've talked to quite a few developers that believe Scrum Masters do not add value to teams. Categorically, every Scrum Master ever. Yeah, however, the amount, just the sheer amount of people I've heard that opinion from. Makes it, makes it so it, it demands an answer. Yes. Absolutely. I agree. Listen, you're not the only one, first of all, right? So, I've heard this from, pretty much from most teams that I've worked with. People say, oh yeah, Fred, Mary, whoever, is our scrum master. We really only see him during like the daily stand up. We're not sure what they do for us after that. Okay, so if that is prevalent in your world, think about what happens next. It's not great that that's happening now because people don't understand what a scrum master is even doing but That is bubbling up well do the org well . I realize we kind of started slipping into do we need a Scrum Master or not? So, a scrum master coming into a team that's not really used to having a scrum master there you know, what are they used to? Oh, well, the developers create their own stories. It's not really product people around because developers know what to do. In that scenario think about it this way. Ask your team. Are they a team? Right? Simple question, but a valid question. Are they a team? What does that even mean? It means do they have all the team skills that are necessary to deliver something, whatever it is at the end of a two week period, a sprint. Three weeks, whatever your sprint is, right? If they do, then they're a team. And then the next question is, if they're a team, do they need a scrum master? What is a scrum master at the end of the day? They don't know. It's a, it's a term that comes from rugby. People don't understand rugby. It's a shame, really, because it's a great sport. But they don't understand what it is. So, ask the question. This question should be asked of every development team member. Dev, QA, whatever. Think about your most favorite sports team. Any sport you want. Ice hockey, basketball, Sure. Baseball, whatever. Do they have a coach?. Ask them the question. That's a binary answer, by the way, right? Yes or no. Not kind of sorta. Yeah, you're part time. No, they have a coach or they don't have a coach. Guess what? Most have a coach. So then the next question is, why? Your team is so terrible. They didn't make the playoffs the last 20 years. And they need a coach. Okay. Acknowledge that. Move on. Oh, your team made the playoffs the last five years. And they won. Whatever it is, the last two years, right? Let's say they won the Super Bowl the last two years or the Stanley Cup. Why do they still have a coach? They don't need a coach. Surely they know what they're doing. Sure. Yeah. Why do they have a coach? Right. So that's a question to ask. Have them ponder on this. Because a coach is not somebody who gets on the field, the ice or whatever during game time. Their work is done ahead of that. Their work is done to prep the team to go into a duel with another team as best prepared as they can. That's the worth of a coach. So if you're a team coach, why should a team need a coach? What teams do you know of that don't have a coach? None is my assertion, right? So you're there for a legit reason. You're there because you enhance the ability of your team to succeed. That's the bottom line. Now, how you do that, right? Hey, guess what? That's on you. Many coaches get fired every year because they don't succeed. And why do they not succeed? Because their approach was wrong, their process was wrong, whatever it is. So reflect on that and say, how can my approach lend the team to succeed? Don't say to yourself, how can my approach lend me to be successful? When you talk about me, yeah, you've already failed. Yeah, personal conflicts, is a tough, tough topic because it requires a skill that in corporate America people try to hide from, which is conflict resolution. People normally try to just hide from conflicts and hope that they'll go away. That's right, that, that hope that they don't even get involved in them. Yeah. The thing I want to talk about personal conflicts, this is really the last thing. It's a failing strategy, I think, yeah. It's a very failing strategy. So the thing about this is when you talk about personal conflicts, you merely look at you and them, right? And you say, well, why are they doing what they're doing? Yeah, right. Stop! Don't do that! Look at it and say, we have a conflict. Me and Fred, or Mary, or whatever, Joseph, Josephine. And say, why am I? Doing what I'm doing, right? If you think about it from that standpoint, you'll immediately come to the realization that you're overtly bringing into the equation something that is forcing the issue. If you're forcing the issue and they're not willing to go along with it, now turn it around. If they're forcing the issue, will you go along with it? Likely not, right? So, think about it from that standpoint. Personal conflicts are just that. They're personal. They don't have to be conflicts. They can be disagreements, right? But ... It's all about how you approach it at the end of the day. What are you in the long run? What are you in there for? Are you in there for personal glory? Are you in there for the organizational success? The team success? Decide that for yourself. Please let us know. That's right. I think we're done here. Right? I think we are. But what is great is subscribing to the podcast. Subscribe and like below, and let us know what else you'd like us to talk about. That's true. Because we are game. That's true. And we'll charge a whole lot of money. Nope. Stay safe and. Stay thirsty, my friend.