AA68 - Dealing with Conflict, with Special Mystery Guest

Oh, welcome back. Special mystery guest Jessica. You're our special mystery guest. We wanted to have an episode to talk specifically about conflict resolution. And the reason we wanted to talk about conflict resolution is because there's so many people that lack this skill in in general. Yeah. I was gonna say in corporate America, but yeah, you're right in general. Mm-hmm like when it comes to coming into an uncomfortable discussion where conflict is at the core of the discussion a lot of people just don't have this skill to work through it yeah, absolutely. So you've got people that some people will just say, it's not worth it. I'm I'm just not gonna engage. And they, they yield and other people. it's a matter of principal. I'm not gonna let go. And they dig in, right. Mm-hmm mm-hmm mm-hmm so you've got a whole spectrum of that going on in the workplace. Right. So we've seen that we've, I'm sure we've been on teams where we've seen this happen. Sure. So it's a very topical thing to discuss, I think, conflict resolution I can remember a situation specifically where we had a scaled retrospective and we had leadership involved and they were getting very aggressive and using one of our scrum masters as a scapegoat, which that's what it seemed like in the meeting. And I was acting as the scrum master and I had a very difficult time. Was that person in the meeting, how to mediate that conversation? Yeah. You were too. You were, you were there was it? Yeah, . . Oh, I remember. Remember I would look at the audience carefully for retrospectives, right? They, they should be for the team by the team. Well, no, so this was a scaled one, right? So we have one for the team and then they wanted to do one, like our CEO. He's like, that would be beneficial. Let's let's do like a reflection and he really liked retrospectives. So we did it at that level as well. I don't remember this at all. I are you I'm so sorry. Like I don't, you didn't gimme feedback afterwards. Did I? Yes. My memory is so terrible. Honestly, no, I can't remember. Yeah. Well, so you, you want me to tell you what you told me? yeah, yeah. Yeah. Cause during the situation, I have no idea so comfortable. You could feel it. You know, the scrum master was getting defensive. So I interjected as far as like, we gotta go within our time box like we, we gotta stay on track here. Right. What I could have done was communicate why we're here communicate a working agreement. There was other things I could have done to mediate that conversation. Remind everyone that we're on the same team. We have the same goal in mind things. That's true. Yeah, that's good. But you know, when I was on the spot like that, those things didn't come to me. Right. So I tried to redirect the conversation as best as I could, but the feedback I got afterwards was that if I had more experience as like an agile coach, cause I'm, I was a scrum master. I still am. If I had more experience as an agile coach, I would know how to better navigate that conflict. But you know, in that moment, my fight or flight kicked in too, I wasn't the yeah. Right. That wasn't directed at me. Yeah. Yeah. But I, it kicked in. And so when that happens and your frontal cortex shuts down. You don't think clearly. Yeah. Liz, Braden takes over. Yeah. Yeah. Right. Yeah. I probably put it the way that you, you just put it, which wasn't the great greatest way to put it, but the, the better way to put it was if you are the facilitator of that session, then yes, everyone is looking to you to be like, Hey, disarm this tense moment, turn it into whatever it needs to be turned into to make it more beneficial to everyone. And and then move us along in the agenda. that like, that's a, Ooh, if you're talking about the magic of a scrum master that's the magic is like, Hey, I'm under disarm. This super tense moment of like, Hey, you guys failed. We talked about before failing a sprinkle. Oh yeah, you look don't, you tell the development team. They failed in something super dirty word failed. Right. Cause just the attack in that word of like you failed. Yeah. You're a failure. That is a major insult, right. You're failure own, you failed like the small now you know, as a developer, there's a better way to convey that other than the product person be like, this sprint was a failure. You're you're shaming the team. Yeah, yeah. Right. Yeah. Yeah. But the product person might not be trying to say you guys messed up and I'm real disappointed in you. It might be Hey, the message coming across might be, we didn't do what we set out to do. Now let's stop for a second and introspective and figure out what went wrong. So the next sprint. We can commit to the goal and do what we're gonna let's really stop and think about what we did cuz nobody's holding us accountable. This is us holding ourselves accountable to figure out how we learn from this misstep. I don't even wanna say misstep cuz even like, even that could be construed in the wrong way, but it's all that kind of stuff, but like rolled into somebody, monitoring the conversation to say like, how do we learn from this? All that rolls back into conflict relationship. It certainly does. One of the things you could do in that specific situation. And I'll come back to yours after that, right. Is obviously don't use the F word you failed or certainly don't use the you either, right? Yeah. I might say as a product owner might say this sprint was pretty good, however we could have done better. Right. So let's talk about some of the reasons why we didn't do as well as we expected. Mm-hmm , there's always we in there and not you first of all and ask the questions, don't say, well, if only our C I C D work, we, we might have met the goal. Yeah, no, right. Don't do that because don't immediately go to a cause. Let them come up with these things, right? Yeah, yeah. Coming back to yours. Okay. So in a situation where you find yourself in the moment having to like come up with something, you can always turn to a. always turn to a break. Just say, this is a good point to take a break, just to stay five minutes and we'll come back. How's that, and actually remove yourself from the room physically, just walk out. Right? Because that'll give you the clarity of mind. If you're standing there, you're looking at the person who is the aggressor in this case, mm-hmm or you're looking at everybody else looking at you saying help defend us, right? Yeah. That doesn't help because your brain is still now in that fight or flight mode. Yeah. So if you get yourself out of the room, it gives you a breathing like a little bit of space where you can now think through and say, how can I deal with this? Right. Mm-hmm , that's always the option that you take a break. Yeah. I mean, that's not a bad idea. I think in our CA in this case, it was the end of the meeting. Okay. Right. It was like the last five minutes of the meeting. It would be weird to take a break at that time. Sure. Right. Sure. I understand. Yeah. But I hear what you're saying. Absolutely. I think another thing I could have done in retrospect was schedule a one on one with a person who was pointing fingers. Yeah. Right. You know, create a safe space for him and me. Just the two of us. Right. To kind of dig into that a little bit more. Yeah, absolutely. Mm-hmm and that's uncomfortable to do too. It is. But you know, at the same time you really don't wanna fuel the fire. What I'm saying is when they're being that way, questioning and so forth, almost in an accusatory tone, you don't wanna necessarily start. Defending yourself, right? You say, oh no, but cuz now what's going on is now they're gonna keep to their guns. And now you've gone into this firefight. You don't wanna do that. Yeah. But like it's graciously pull out of there. Yeah. But to echo what, what Jessica just said for a second, it's like, oh, when you're in that mode where like it's Ooh, full finger pistols, like beep taking it offline to say, Hey, let's talk about this offline. Let's put off the side, let's continue with on the main line or whatever. And to, to get to whatever resolution and to take a note and to take that offline and have one on one. Woo boy. What a powerful tool. Because I have to think of it like from, from the perspective of, again, we're, we're in the perspective of a small company here where you like have access to the sea level executives and stuff. Mm-hmm if you have the ability to take an issue offline and talk to the, technology, people talk to the business, people, talk to whatever one-on-one to get each of their perspectives. Now you understand each of their perspectives individually at a deep level. And when you meet back with them, one-on-one you can take everyone's different perspective into account so if I. Recommend anything to people trying to break in, like people, I think of people trying to break in the field, people that scrum mess for the first time and stuff like that. And I'm like, yeah, one on one is basically where you make all your money is having one-on-ones with people. That's your opportu tour opportunity to influence and to spread your organizational influence is one on ones. You, you, you spread influence one on one and then when everyone's together combined, you have already planted the seeds throughout. Yeah, absolutely. It's a force PRI when everybody's together. So yeah, I agree. One-on-ones are very, very powerful for sure. Mm-hmm we got on this topic because we were talking about conflict resolution and we were talking about places that was uncomfortable because everyone in the organization it's basically uncomfortable for it. I remember when I was a team lead for just to pick one outta the air, this is probably not even the best example when I was a team lead on the QA team. I remember my boss. Not, this is not a ding on him. Cause my boss was excellent at the time. My, my boss not wanting to go to war with the development manager over certain things. Mm. So it was like he, he was avoiding conflict right. Of like, well, well we just got well, he just wants this and we just gotta do it cuz you know, cause otherwise this and that and this and that. And you know, he just, wasn't looking to get into a deeper fight. Yes. About certain things. And then I, as a team leader, I was like, oh, I'll certainly get into a deeper fight cuz I, I think it's very important. But he was sort of leveraging both the, like the work and the QA team's contributions to the larger organization. But at the same time he knew we had to live in the world of working with development every day. Mm. So there were certain fights that he will, that he was willing to lose and that he was willing to stick it out and win in. And he kind of made that decision on my behalf as a team leader, which as a team leader kind of annoys you at the time cuz you're like, ah, well I wanna fight every fight on my own. But that's, I mean, that's, that's just the world you live in. so it's like there are certain fights that he would avoid and there are certain fights that he would get in. But that doesn't mean that, that doesn't that just battles that does not mean that he was just conflict avoidant, which certain people in the organization certainly are. Oh yeah. Yeah. They just, they just will avoid conflict. And sometimes you see those people continuing to get elevated in their career because of that, they didn't ruffle anyone's feathers. Oh, take it away. you really want me to do that? I can't, I can't get into this one. yeah, you, you are right. Some people get up in advance in that way, but unfortunately that doesn't serve your teams. Well, because they're not gonna pick the fight that needs to be fought if you're, if they're always just gonna back down, but they're well liked, you know? Yeah. They're well liked. And they personally doing well, right. Personally, they're doing okay. Cuz they're getting raised or advanced or whatever. I would argue just from my, my own career perspective the people who say yes I was gonna say yes, and just to be pedantic, but I'm not gonna do that. The people who just say yes and don't follow it up with anything. A lot of them do get ahead over and above the people who are like, Ooh, let's talk about this and let's talk about that. And let's weigh both sides or whatever the people who just say, oh yeah, we can do that. And kind of pass that pain along to the team or whatever. This is what I was saying. It sure they don't , yeah, they do well by the team. Yeah, because that's what they're doing. Yeah. I, but, from being a team member, I know that the team, everybody on the team knows that that's happen. Everyone on the team knows that like you have a team lead or a lead developer or some, a senior developer or whatever, they're just a yes man or a woman, I guess. Although I, I don't think I've ever been on a team with a yes woman. Usually it's been a yes, man. That's not what this podcast is about. So , I'm gonna abandon this topic. yeah. So those people are well liked only by people on the periphery, not the team to his point. Right. The team knows that this person's always making commitments. Mm-hmm and simply shifting the blame on us when those commitments can't be met. Yeah. So they're not well liked by the team necessarily, but they're well liked by those on the periphery and maybe above cuz they're hearing the answers they want to hear. Right. So how do you stay true to yourself? Look out for the team and respectfully say no, well no's a shorter word than yes. So it should come more naturally to say no, I'd say just always have the interest of the team at heart, but don't say no in all situations you can say no without using the word. No. Right. Always use the opportunity cost argument too. Just say if we were to do that, what are we not doing? Yeah. Right. That gets people to think about the alternate. That's good. Right. So yeah. Yeah. I could see that. What pain would it cause us. mm-hmm yeah, mm-hmm, I can do this from a product perspective. Mm-hmm because I, I will say no to the people. I have the ability inside the organization to say no to, cause I'll just tell them no no, we're not, that's not a high priority. We got those other things. They're a higher priority and no, you know what I mean? other people, I might be more graceful with to be like, that's in the backlog. It's it's not come up to be something that we've refined yet, but we, but it is in our, on our roadmap to deal with other people might need more grace to deal with. Mm. where I tell them this potential feature there's different personas that we could implement it for. I have to think about who we're gonna implement it for before we do it in production. Mm. And, and, and that's how I'll tell them. No, but basically , no, as in, not yet, because we haven't thought deep enough about it, that kind of, no, you know what I mean? But people I can tell no no, like a hard, no, no. To, I will tell them no, as a product person, I'll be like, no, we're not doing that. There's no money in that. It would take the team too much to deal with that let me flip to the other side I'm gonna tag you in on, well, like flip to the other side of the house, the scrum master side of the house, I'm, I'm totally cutting to the end of this. Oh. Flipping to the scrum master side of the house. What is the product equivalent of that? Cause because I am willing to go all the way up to the executive level with my like hard, no on certain things because I have users behind it. I have other roadmap features behind it. I have, I, because I'm me, it's not just anecdotal I have actual experiments that we've done and data to back it up. Yeah. I'll give you a real example from the scrum master side of the house then. Yeah. So let's say let's say somebody doesn't matter who really oh. Says that Let's go to three week sprints. How about four? How our developers aren't able to deliver things to testers soon enough. So the testers can get everything done in two weeks. Two weeks is just not working for us. You're right. Yeah. Right. So that's an example where the scrum needs take a stand, right? The yes. Person would probably say, okay, well what if the, yes. Is that for me to do? Yes. Person is the superior to the scrum master. It doesn't matter. Doesn't matter. No, because the scrum master is the person who is the expert on process. And it's their role to coach up in the organization. What if they're superiors the agile coach? It's zero old coach. Are we on a conflict resolution right now that I have to step into like, well, there's a trifecta happening in this discussion. Unless we include the leadership, then there's a, what's a for AFE, what's quad quad. That's not even real thing. I'm editing all this out. There there's the dev team members. There's a scrum master who's representative of the process. And then there's a product person that's included in this. So like, there are multiple voices in this mm-hmm so like anybody, like laying down a, a dictate to be like, no, no, no. To answer your retort, which was, which is what is happening now. I would first include all the rest of the voices in that discussion to be like, wait a minute I, I understand you are saying this needs to happen, but like mm-hmm, , let's figure out if like, does, is this optimal for product? Is this optimal for the dev team members? And like maybe everyone backs down cause they don't wanna deal with a, with one person who's the highest paid person in the room or the most loudest screaming person like that kind of thing kind of situation. I almost want to stop right now and let you continue where you, cause you were coming to a point that was very important. And I, I kind of like cut in front of it. I think you've actually tried to reinforce it. So yeah, bring everybody into the conversation, first of all, and then. Pivot the issue away from just what is being presented as the problem. We can't do development and testing in two weeks. Right. therefore the answer is add an extra week to the sprint. How do you stretch from that, to this? So what are the alternatives? What else can we do? Yeah. So have that conversation and then to Brian's point, is this optimal for the product? I might ask the question. Would it be okay for the business to not see anything for three weeks? Absolutely not. And give us feedback. Absolutely not. Absolutely not. And also get outta the room and also like take some vacation and come back when you're ready to talk about same topics. Exactly. I can't go more than two weeks without talking to a customer. Get outta my office, back it up with something like this. Right. Just say, so if we went to three week sprints, it takes three weeks before we show the business something and get feedback and let's say we have to pivot. Right. Mm-hmm so it takes us a little bit of time to pivot and then another three weeks go by. Right. So let's say six weeks, let's say it takes us only a minute or two to pivot. Right. So, so three weeks get feedback another three weeks, cuz we now went down the pivot that was suggested. Yep. So that's six weeks. That's a month and a half that's way too long to go without feedback, you need frequent feedback. And for that reason alone, three week sprint is not a good idea. Gotta hear now at the same time. And I would probably phrase it differently, but I would ask those team members that are pushing for the three weeks. What makes you confident that you can deliver in three weeks? That, which you cannot in two weeks, right? Yeah. Can we slice our stories vertically a little bit so we can get things done faster and get 'em to death? That's the answer, not three, cuz our stories are big and they remain big. So in, in a few spirits, they'll come back to you and say, three's not working for us. Can we go to four? Right? Yeah. All I was thinking was how uh, this is a totally different topic. So if you wanna cut this out, feel free. We can discuss this at a different time. Nope. We let signals how the, the certification to become a scrum master does not prepare you for the real role. This is like the events you learn about the events as a scrum master mm-hmm and that's I think 10% of the role is the events because realistically you're navigating conversations, like you just said mm-hmm and you can't learn that from the scrum guide. No, you cannot. You have to be in the room to learn that. Right? Mm-hmm I mean, how else do you run that? You can listen to podcasts like us arguing. You also need some experience. You do need the experience you need. Yeah, I agree with you there. until now we were talking about why what, and kind of why at the same time and like you just segued us into the who, like there are people in the organization, corporate America specifically, when I talk about who there are people who have natural talent in the organization for what we're talking about now, a natural talent for mediation, natural talent for reiterating people's points and, and bringing them up in a different way. That's not so incendiary but that skill, that ability I, I don't really know where it lives in the, in the traditional corporate structure. Like I would, I would hope that it lives in HR. Some. Mm-hmm you know, that, that's why when people have brought up in the past oh, where should scrum masters sit organizationally and blah. I'm like, well, let's just sit under HR. And people are like, Brian, you're crazy. I'm like, well, I mean, am I crazy? Because the people in the organization that have these skills, they're more aligned under HR than anybody else. They're more aligned in saying like, let me align opinions between people, let me build consensus, let me deescalate conflict and then escalate it back up to what is beneficial to your organization. Like who trains in these skills. It is not in the technical wing of the organization. Not at all. Absolutely not. No, they don't learn this stuff anywhere. It's not that you go to school, they learn this stuff. Right. Right. Unfortunately, scrum masters, Azure coaches. I mean, we all report into the technical side of the house. Right. Whereas to your point, HR, they learn these soft skills as part of their job, maybe. Right? They do. They do. Maybe. No, they do. Some are better at it than others. Mm-hmm maybe, but they take size. So here's the other thing that happens today? Well, I have a knife fight. Are we gonna get in a knife fight very poorly by HR. Exactly. That listen, that like I agree with you, but I, I, I'm not cutting any of this out. I agree with you, but only in so far. Oh, That's such a great phrase. So far as only in so far as you like the HR people in the HR, or if we're in the UK, HR, HR, people, people are not like specifically the hatchet, men of the C-suite like they, they're not the like armed combatants of the C-suite. They actually are meant to serve the organization. But if they're that traditional role of their they're only there to execute on, on literally execute, literally execute. But like when we need to fire people, yeah. I'm not talking about those people. Okay.. I, it is what it is, folks people that are actually coming through sh RM or whatever it is, right? These people are certified and they're educated in the art of HR. They, they're not there just to take a spreadsheet and go, ah, these ones are red fire, these people, I'm talking about people that have the soft skills to have negotiation skills, to have discussions with people. And it doesn't have to be technical people either. It can be anybody. So there's some element of that now to your point, I've seen it done very poorly. Mm-hmm and what's worse is I've seen. Middle managers that are not in HR, go to HR with an edict basically, and say, we need to fire this person. They're not a, they're not a team player. Mm-hmm right. And now the HR person doesn't really have they, they should do the due diligence, but they don't sure they take the directive of, yeah, we need to get rid of this person. They call 'em in and they do the exit interview. Right. But that's an, I'm talking, I'm talking about real facilitation skills where they can be brought in, listened to their side of the story and see if their skill set could be leveraged somewhere else. Maybe they're not in the right place, in the right role in the organization, but they have skills. Maybe they can be deployed somewhere else in the organization. Right. Look at alternatives like that. No, that doesn't happen very often. Unfortunately, cuz you know, we, we work in large companies that are largely like matrixed and that's where you get the middle manager going straight to HR saying, get rid of this person. Mm. So that's where it all falls apart for me. Yeah. Yeah. That makes sense. Well, I wanna give you guys another hypothetical. Sure. What if you're in a meeting with all of your peers and you are say blatantly disrespected, undermine talked over whatever, fill in the blank. Right? How do you respond in the. How do you respond outside of the meeting? So somebody is deliberate, some somebody, or somebody's are they deliberately undermining you in this meeting? Sure. A peer, a, a member of a team, a somebody in a supervisory level, like what, what, what do we, so they would, they would change how so say in this instance, it's another peer, we'll start with that. And then we'll go to superior. Cuz I wanna hear the difference too. Mm. Yeah. I mean, if they're undermining you, you know your opinions, right? Are they still giving you air time? Are, are they letting you speak? Because if they're not letting you speak, you would behave a different way. Mm-hmm . Then if you are able to speak, then it's up to you to make your point basically, right? Because you've got the air time you need in the room. But if they're not letting you speak, I would simply just do this. Raise your hand and, and say nothing. Just raise your hand, let them speak. Let, let them just talk it out. Whatever they have to say, they have to stop at some point, take a breath. Somebody else in the room might clue on that and say, Jessica, you have something to say, right? That's the clue that now you go in and you say yes, if I can finish my thought for a couple of minutes now, I don't agree with this because, and now you can get your point across. And, and that is not disrespecting the person who. You know? Yeah. Who's doing this to you. That is simply using the room. Yeah. To get your time slice to talk. Mm mm-hmm yeah. All right. You could always use the shaman stick thing as well, right? Well, yeah, you could. And then after the meeting you would go to this individual one-on one. Yeah. After the meeting, you would, you would go to this individual one on one, and again, you shouldn't go in there with the intention of locking horns with them attempting as it might be. Right. Sure. You would go in there and say, I, I firmly believe in what I said now. Now think about what I just said. I didn't say I believe you're wrong. Mm-hmm don't use the U word, right. I believe I'm right. Because right. And then let them make their position. Yeah. Mm-hmm yeah. So how would you start the conversation by like discussing what the goal? Maybe having some like casual, verbal working agreement, right? well you mean one on one or? Well, yeah, in a one on one. No one on one. Well, yeah, absolutely. I mean, you would say the reason why we're in these roles is what we're trying to do is, and we're on the same side. Yeah. We're on the same side. We're trying to do things you are, we're seeing two sides of a coin. Right. And this is why I believe we should do things this way and let them make their point. Sure what if they get defensive. that's fine. That's their prerogative, right? Mm-hmm they can get defensive. They can, they might even get really like aggressive too. Mm-hmm mm-hmm right. But if they get defensive they're are they defending their position? If they're defending their position, at some point you have to decide, how far are you willing to take this, right. Yeah. And you can just say the classic thing is we'll have to agree to disagree this time. Yeah. I was trying to say out this one but also it is different from a scrum master as a coach like team level perspective than from a product perspective. because I, I think of this topic from a product perspective, this happens all the time to me which is should we put money into building this product or that product, or this feature or that feature and product manager a for team a will say, oh, we should build this because I think this and , product manager B for team B will say, well, I think we should build this for team. Then they could dis you know, they could agree to disagree basically in that meeting. But from a product perspective, if we are conflicted about, oh, a path to take well, then we need to do an experiment to figure out which path to take, to figure out where we get signal from to, to figure out which path to take. Right. Cause if we don't have any signal, we can, we can go to path, a path B path, whatever Z or Z. Hmm. A customer driven. That's easy to do. If we're a UK customer driven path, Z, Z , then, there's a million paths we can take., but like why don't we try something and see if we get some signal from it. And then based on the signal, we'll make an informed decision, right? Like the, the, those of the, we can have those discussions between myself and her herself. I don't know if that's a, is that proper myself and herself or myself and her it's is it myself and her? Yeah. English language. There's gonna be a lot of editing in this podcast. Well, her or nice you wanna be proper her and I there's a lot of back and forth discussion between her and I we'll decide based on the evidence that we discover, which path to take. And then there are no bruised egos in there because we, because we both agree Hey, let's try something and whatever yields a result, then we'll do that. And we're both on the same page of like, oh, well, well we tried and then we figured it out based on based on what we got back I will tell you, honestly, usually it's a, it's, it's sort of a, a mix or it's usually something that neither of us thought about in the first place. It's, it's that evidence based approach though, right. It's hard to argue against that. It's it's logic. Yeah. But you were talking about team based stuff. I pivoted to product based stuff, because to try to emphasize for anyone who's listening to this podcast to try to emphasize like the team based stuff is just evidence based with different evidence. Yeah. Yeah. And, and, and it, it might seem more difficult to get that evidence of the, of the team based approach of like, well, we, should we do this with the teams? Or should, should we do that with the teams? But I mean is it really that difficult or you, or have you just not tried to measure different things organizationally? Yeah. It's the latter usually, right? Usually it's the latter. Yeah. You haven't really dug deep enough. Right? I would say though, if you're looking at Picking up some tips, I guess in how to react in situations where the other person is badly. Not, not, not necessarily well verbally attacking you sure. Let's say right. Verbally attacking you. Yeah. Just watch, just watch a little bit of the parliament time in the British parliament. Oh, precise. Watch these people. These politicians go at each other, they attack each other all the time. Never do they call anybody a bad name or anything? You know, it's the right honorable gentleman doesn't know which side of his head he's talking about. That might be extreme, but you know what I mean? It's like, so I've, I've not insulted him. I've called him the right honorable. Right. But at the same time, it's an art form. It really is. But they're, they're not letting anything fly. Like, like the, this is why I brought up the product thing. If someone tells me oh, oh, oh Brian, the majority of customers don't want to click this button first, before they see their report. What proof do you have. Of the majority of customers want to see that? Show me, show me the evidence of that. You, you know what I mean? Like that would be the, the, the parliamentary equivalent. Of like show me what evidence you have that backs up your claim of X, Y, Z, I feel only because I'm in the product space can I say you should lead with that? You should lead with your evidence. Yeah. Should do that in even on the scrum yeah. Scrum master should. Yeah. With it. It's it's I, I think it's harder to do on the scrum master side. It's harder, but not than it is on the product side, harder, but not impulsive that's funny. Yeah. I, I wrote down something can scrum masters be assertive. that's all. Yeah. That's here. Can scrum masters? Just say no, like this, this goes back to our super early podcast about meet them where they are, like meet them. Oh, well you gotta just meet them where they are, because maybe they don't know anything about scrum and maybe they're kind of doing things all messed up and you guys, you kind of gotta meet them where they are like, I mean, or do you, do you gotta meet them where they are? No, you don't. You don't like where they are. I mean, I don't like where they are. You, we only, we only have, we only have 25 minutes to do a retrospective. Do you really need to meet them where they are is 25 minutes enough to like, I, I, I constantly tell people I was like 25 minutes is not even enough to generate ideas and put them on the board and group them. I know teams that just take a box and say, we'll just stack on 15 minutes and do a retro. At the end of our standup Moster whoa. Oh yeah. 15 minutes is all we, we need. I know. That's right. Wow. And there's usually how fruitful is that? Conversation's not, not very it's expeditious because KA says, okay, we'll start the red now. What went well? I like the fact that Johnny helped me out. Oh, great. Well done Johnny. Kudos. What? Didn't work so well silence. Right. No feedback, no feedback. Yeah. What can we do better. 90 points carried over guys. Are you sure? Nothing when didn't go well, huh. Then they get into the blame game. As soon as that happens. Right. The environment was down. I mean, someone, someone like someone has to take ownership for it. What does the scrum master draw a line in the sand about and say, no, no, no, no, no, no, no. You, you can't have hour long, daily scrum meeting like where's the line in the sand. Like I like some people be like, oh Brian, you're like, what are you talking about? Like if, if the team needs to have hourlong. Daily stand ups. Who are you just say? yeah, those people are the same people that say we're gonna have to do things by the scrum guide it's whatever works for the team. So, so of course, the minute you do that, you're not following scrum. And then when it doesn't work, you go, well, scrum doesn't work for us, but you're not doing scrum. That's the problem. Like the, the, the, the trade off to that is people who will say, well my daily scrum is 10 minutes of daily scrum, actual da Hey, I'm gonna work on this today. Oh, you're working on that. Okay. Whatever. And then the follow up discussion is all of the stuff that, that, that has slipped between the cracks of like things that we didn't do in refinement, things we didn't do in sprint planning, all like we shortcut our sprint. This is, this is a big thing with me. If you shortcut your sprint planning and you like, oh my sprint, planning's only 45 minutes. Okay, cool. 45 minutes sprint playing. This is what we're gonna work on, whatever. And then you and your sprint planning and the first day of your sprint begins and you're like, I don't know how I'm gonna implement any of these things well, that time that you should have spent sprint planning now every day, you're gonna have to spend a fraction of it along when the sprint is happening. to plan each item as it comes up. So every Monday, what, whatever day you're spring against every Monday, you can spend four hours, six hours, whatever it is, and plan every task in depth or every other day, your dev team can be meeting an hour in the morning, doing a little micro sprint planning, but you don't really realize that's what they're doing as part of their daily scrum. This what we're talking about, falls in that category. Mm. You know of the scrum master saying, no, no, no, we're not done with sprint planning. You guys haven't, we have all your tasks. You haven't done all your subtasks. You haven't talked about what, what is touched in each story. You haven't specked out how you're gonna build it. You don't have an architecture laid out. You don't have, you know what I mean? All, all that kind of stuff. You haven't finished this stuff sprint. Flying's not over. Sure. So the scrum master in that example is reinforcing how to do things properly in scrum. Mm-hmm basically right. And if you're not doing that, they say you're not doing scrum. So should the scrum master say no? Absolutely. Yeah. I remember hearing one of our managers say this. He was an agile coach. Yeah. So he would say maybe he would be very assertive. His personality was to be assertive and then he would stop thinking he's like maybe he would follow it up with a maybe because he didn't wanna come across too assertive in his role, as, I guess he was playing a, a scrum master more so in that instance. And I can understand it, right. If you come off too assertive, you can come across like a project manager and you'll lose the respect of your team, cuz that's not what you're there. I think it depends on the maturity of your team though. Right. If, if they're not doing the basics right, then it's entirely okay to say this is how we should be doing things. I mean, that's you basically coaching the team sure. When it comes to process, right? Yeah. Yeah. So anything outside of the process, maybe out a, maybe sure if you're really not sure. maybe, maybe, I don't know, like this, this this walks a real weird line with me because again. This goes back to like the early podcast about meet them where they are. what if they're in a place where they're doing 15 minute retrospectives and a 20 minute sprint plannings? You know that they're not doing inappropriate amount of planning. Yeah. You know, at the end of the planning event, they're not getting out of the planning event. Well, what they should and when the conversation is organizationally, when the conversation is turn, turn towards, oh, I don't really think scrum works for us. Mmm. Like now you're in the now you're targeted. You've made yourself a target. I've now taken the subject of conflict resolution and turned it around for this conversation. Because now I'm gonna create conflict to say, listen, like these are the things that I own. Like, again, going back to my old time thing of like, you're not a scrum master, you're the process owner. And if you are the process owner, you have to say we didn't figure out these things that we were supposed to figure out in this event, the sprint playing event, backhoe, refinement, whatever, mm-hmm, retrospective, we didn't figure these things out. Cuz we didn't spend enough time. Right. I I'm taking offline that, the idea of the moderation, right? Like you've moderated the topic appropriately and stuff like that. If, if you don't have enough time forget moderation. Yeah. If you don't have enough time, the bare bones framework of time, there's not a lot you can do as a facilitator inside of that time box. Right here on arguing agile. I'm gonna argue this. All right. So say you're plopped into a team. They're doing this process. You're against meeting them where they are. So would you say like, Hey, I'm changing these meetings, would you even tell them, or would you just change it? Just change all the meetings to the way that you know, would be most effective and they'll just deal with it. Is that your approach? Isn't that disruptive? I might make some enemies. You're new here. I, I don't like being yelled at Jessica but I do this currently because my sprint review is slightly truncated to lessen what I would like. I know you, you liked the word truncated. I, you do. I T that one in there for you. Did I say that last time I, you did it in a previous podcast. You were like, I love the word truncated. I do. Oh, such a, such a good word. It's such a developer word. I know yeah. I wanna go back to this one. Right? Uh, that we just touched on, right. Mm-hmm would you just change the meetings or would you tell your teams, right? That was your question. Mm-hmm mm-hmm so my approach would be to say to the team for this particular meeting, the recommendation is this many hours or whatever it is, right. So let's say, let's say spring planning. So for a two week sprint, you should be spending of the order four hours. You could get done early, but you have to come out of it with these things. Yeah. And therefore we're gonna meet for four hours. Yeah. And, and change it, but I've told them why. Right. So when they come in, they know why's why. Yeah. Yeah. And I put it in the agenda too. It's important for people to understand the why is I was just having this conversation with my my current boss. And he's like, I know you, Jessica. I know you always challenge me. He's like, and I appreciate it cuz you know, you need to understand the why behind what we're doing for you to be on board with it. Awesome. Like I think teams are the same way they are. Yeah. I think you're gonna get their buy in so much more effectively or easily even mm-hmm right. If they understood the way mm-hmm and you tell 'em, these are the outcomes that we are looking for from this meeting. if we can do those in less than four hours, we don't have to stay on the call. Yeah. But we have to meet them. if you can do it less then. Great. but the team should be booked off for that amount of time. Exactly. Cause kinda like a mechanic it takes four hours to do the servicing. I'm gonna book four hours for it. If you can get done earlier than that and then move on to other things. Great. But we should reserve that time on their calendar. Yep. Mm-hmm yeah. Mm-hmm agree. Yeah. You wanna go back into conflict? We were talking about, can the scrum master say no scrum master agile coach?, basically the person in charge of the process., can they say no? I mean, you always consider the project manager, a project manager to be more authoritative, right? So the scrum master takes a different approach. They're more influential, right? Maybe it's to your point that they have to explain the why behind something. Yeah. I, I agree with that. I think they do have to explain the why mm-hmm but I still think that there are situations when they need to be assertive, say no, when no is warranted mm-hmm cause they are the process expert, right? The teams are not necessarily, so they may be opinionated of course. And that's okay. This is where the scrum master skills come in, where you listen to somebody, you offer a contrarian view, you listen to somebody else, hopefully someone sides with your views in the team. And you kinda listen and juxtapose one against the. But steer the conversation towards the decision you've already made. And you've explained that by explaining the why, and last but not least I like this part you could say, well, how about we do this? Let's just try this for a sprint mm-hmm so experiment. Right. And see how it goes. Mm-hmm yeah. There's always that Brian, you're making a face. What are your thoughts? I am making a face. I tend to think if a team is lucky enough have some kind of shared agile coach, yeah. If you're lucky enough to have a scrum master, like they should know the rules. I know when, like it's not a super popular way to say, like they should know the rules, like there's, these are the rules, thems the rules, thems the bricks, like follow 'em or not. they should have the expertise to say this is the way the scrum events should be performed. These are the proper time boxes like for example at the sprint review you should be getting customer feedback. Like if there's no customers at your sprint review, that's a problem. That's a big problem. All is a scrum master need to point out that's a problem. Okay. If you're pointing out these things and you're getting pushback, nobody cares. I can think of a bunch of bad ways to present it. I'm not trying to present it in a bad way. I'm just trying to say if the organization is, is inclined to not take what you're saying into consideration, on the last podcast before you got here, Jessica, we were like what if, you bring up like a, a good question is we wanna, we want to invest in feature a and someone's like, well, who is the user. Hmm for feature a, because we want to get feedback. If we build this and then somebody who's sponsoring their features, like I don't care what feedback we get. Yeah. We need to ask the customer. We don't need to ask customer I don't care about their opinion oh, wow. Yeah. Who's the person to be like, wait a minute. yeah, you would hope the product person would be like, wait a minute. But I mean, yeah, I've been a lot of organizations with the product person is not one to rock the boat. They're putting you the scrum master as a coach, whatever, in a very weird position at that point to be like, wait a minute, if you don't care about the customer experience, like who does care about the customer experience? Yeah. It's it, that's a, that's a strange position to be put into. And like, I only bring it up because it's sort of in the banner of conflict resolution, because somebody in the organization is pushing, they're pushing real hard are they aligned with the best interests of the customer , they're probably aligned in the best interests of themselves. Yeah. I would like to think you figured that out by asking a bunch of questions. Yeah. You know, Hey, what makes you think that your idea is the best way to go? what are we going to do to, to prove once we implement your idea that that was the best solution. Right. Okay. And, the reason I have this weird expression on my face, Jessica. Okay. The reason I have this weird expression is because there are organizations where that is just seen as I don't know stir up trouble I'm just looking to cause fights at that point, I'm going back to the topic of conflict resolution. I'm the product person. And you're a random VP, random VP. Every VP is a product person. that's right. So that's my, that's my throwing the gauntlet down challenge in this podcast, every VP in the organization thinks they're a product person. They think that all their ideas are the greatest customer challenges and solutions. But not until you start implementing them and testing them, do you find out, what's true and what's not right. So it, it, it serves your organization to come up with some kind of methodology where you can test ideas before you fully implement them. Whatever that means. It could be real heavyweight depending on the way your organization's set up. We're gonna do another podcast on that subject. We've already planned one now. Good testing ideas. Nice. But you can get in some real vicious knife fights about like, Hey, I think we should do this for these customers Uhhuh. And then as a product person, you can say, what leads you to believe? You know, mm-hmm why are you questioning me? Mm. Just do what I say. Well, they pull rank at that point. Sure. They do. You know? But that happens like, yeah. Like the only reason I bring that up is like, if there's anyone out there, that's thinking I as a Scrumer am caught in the middle of like the product people and the people that are bringing the ideas and the team, or maybe the product in the team, maybe you're stuck in the middle of the product in the team. Right. Do I have to always be the bigger person to be like, Hey, why don't we think about how do we prove this idea? Or, Hey, why don't I try to disarm this combo? Like the, this development manager is like, oh, just implement this cuz I say so like, oh, do I have to be the one all the time to say, why do you think that's important? What evidence leads you to believe that we need to implement this as a top priority, as opposed to, or this stuff? Especially if you're in an organization where a product person doesn't want to put themselves in front of the team to deflect that kind of stuff. And the scrum master is putting themselves in a position where they're like let me be the neutral party kind of disarming both sides and bringing us to some kind of resolution. Because again, going back to super early where we were talking about this subject is like, they're the best person with those skills on the team, right? Do they always have to be in that role? I think if your team is not mature where people are raising their. To be that person who comes out and his arms and whatnot. Yeah. For whatever reason, maybe they have the skills. Maybe just don't feel like it's their place or they're nervous or whatever it is. Right. Yeah. Then the scrum master should be leading by example. But then after this is over, the scrum master could say any one of you can do this. Feel free. Be, feel empowered to say something when you see something not being done. Right. Yeah. You know, so, but yeah, the scrum master cannot just take a backseat in those situations cuz you get steam. Olded sure. Of course. I don't know how deep to, to, to drill into this topic. Let's say you're in a backlog refinement, for example, and you have a, some, some kind of person that's in like a, a lead level or supervisory level to the team is like a, like a, what we talking about for like a solution architect or somebody like that. Right. They say, oh no, you have to do this. And they they're really drilling down. It would be the Scrumer to, to again, assuming your team members and, or your product person is not interceding saying, Hey, how can we, how can we break this down?, and come to some kind of consensus. Like putting this all in the scrum I don't know, like I'm kind of changing my opinion as we're going on with this podcast of like, it's kind of unfair to ask the scrum master to intercede on the team's behalf and, and say, Hey, you're, you're pushing real hard on this topic. Why don't we hear some other opinions yeah. But if a scrum master doesn't do it and no one else has said anything, then you know, the aggressor is gonna get their way. Yeah. Yeah. So then in that case, a scrum master should speak up and lead by example, I think, yeah. That's a tough spot to put someone in, especially like we keep going back to all the times like, oh, the scrum master, should they be technical or not like if you're talking about a super deep technical issue being discussed between like the architect and the team oh, you guys should be able to do this in one sprint. I don't understand. What's so hard about it or whatever the scrum master' gonna insert themselves in that conversation. That's a, that's a, that's a tough conversation to crowbar yourself into the middle of, but it's an important conversation to do that in because otherwise the team feels pressured now to deliver that in one sprint or two sprints. Yeah. Right. So the scrum master could, at that point, ask the question, right. Is this something that you've done before? Mm-hmm, in a. Right. Like what make again, to use your words, what makes you believe this can be done in a sprint? Yeah. Like I wouldn't phrase it that way. You know, I would just simply ask, right. Has this been done before? You're not taking my words in cuz I totally would phrase it. Yeah, you would but yeah. So I think this car master does need to inject themselves in the middle of this and they don't have to be technical. They can be diplomatic. They can ask the team. They can say they ask here from the solution architect is to do this work wherever it is in a sprint. Right. Just gimme a confidence level, fist to five. Yeah. Right. Go around the room, ask people mm-hmm work out a quick average in your mind and say, we don't know if it can be done in a sprint. Yeah. Yeah. Why don't we aim for two and if it can be done in one. Great. Yeah. I wanna bring up another conflict situation. I think this one is probably pretty common. What do you guys do when product owners, in instances, might point fingers at the scrum masters saying maybe we're not as productive because of you guys, maybe we're not delivering because of you. It's not our lack of requirements or their understanding of our requirements, or even the late requirements we're bringing. No, no, no, no. This is you. Well, how, how would they, what would be an example of paying a scrum master? Like, I can't, I can't like, well, they would be the scapegoat in this situation. Right? So this wouldn't be blaming product for not delivering, not doing their job. Well, it's that scrum master. Who's not a part of our group thoughts. Yeah. I mean, this little thing starts when you use words like us and them, right? Yeah. So the product organization, the product owner is part of the team. Yeah. And I sometimes come across teams that speak like this within the team. They'll just say, well, they don't know what they're talking about. Who's they? Or the, the business, the product owners. Yeah. Well, they're part of the team, right? They're it's us there's no, they, yeah. I would have a conversation with the product owner who believes the scrum master is the reason why things aren't being delivered. Right. Just ask for examples, just say gimme some examples I'm looking to improve how can I do better? Gimme examples of where I've impeded the team. From delivering. So what if that conversation has had, and, and it's clear, it's not anything that you were a part of, but the problem is how do you get other people to realize that, because at this point, isn't the scrum master's reputation, slightly tainted in the eyes and ears of these other people who heard this no, I don't think so. I think the scrum master needs to have some pretty thick skin. Right. Uh, I wouldn't worry about that. I would look at the history of the team, the delivery of the, what, what they've done, right. And say, given the capacity that the team has and given the information we have available, this is the what's the word? The, the prime directive, right? That, that's what this is given everything that we had at our disposal, we did the best job we could. And this is where we are right now. If you all have suggestions for making us more efficient right. Or effective I'm all ears. Are you having this conversation with a product owner or the product team at this point? The product team, everybody. Okay. Okay. Yeah, sure, sure. That makes sense. Cause like I said, if you had it with one person, say the product owner on your team, you got them to understand the situation. Right. Who's to say that goes back to the product team and the business. Right. That's what I meant. Isn't your name as the scrum master slandered by that point in your reputation maybe, but I wouldn't dwell on that. I, I. Really address the product team mm-hmm and help them understand how things work in scrum mm-hmm mm-hmm yeah. I wouldn't worry too much about the reputation. It will fix itself once the team becomes a smooth well on machine, right. That that's really your job as a scrum master. Yeah. Yeah. I, I don't think it's worth spending too much time thinking about the reputation of a scrum master necessarily. Now having said that if somebody's directly pointing that out to you from the product organization, then yeah. You need to have that conversation with them. Definitely. Hmm. What are your thoughts, Brian? You're awfully quiet. I don't, I don't take kindly to people. Slen my reputations. I would I challenge them to a dual and meet it high. No dead bases. Meet it. High noon. That's right. It's a very strange position to be in like, like basically someone saying you're not doing your job. I don't know I, I it's difficult for me because I, I don't live in that space anymore. So as like, what evidence do you have that says, well, I'll give you a hypothetical example. Right? So for instance, I think I mentioned this earlier, if the product owner has continuously maybe changed requirements mid sprint, or it wasn't clear enough later on as things were revised. Right. And there was a conversation around that. So it didn't make the deployment mm-hmm that it was scheduled for originally because of the changes. So for them to come back and say, who was the scrum master? It was, it was you. Yeah, in this situation, if they've really changed requirements or they were late or they weren't clear enough I would basically conduct a retrospective with the team and put that on a board and display that to the product owners, specifically, the people that are changing the requirements. Yeah. And say, we did a retrospective on the root causes of why we didn't deliver as much as you are looking for. And these are the reasons the team came up with. Mm. So you're removing yourself from the situation as scrum master at that point. Sure. Yeah. Yeah. I would try that. Yeah. I mean, I would also think that if requirements are changed very late in the process that you would be able to show that you'd be able to show the metrics of that. The, Hey, the team took on five stories and of those five stories that we took on the beginning of the sprint out of those 5, 3 were changed mid sprint. I mean, you can't expect that, like when you start the sprint, you can't expect a change 60% of the scope of the sprint. Right. And, and get what the team committed to in the beginning, you know yeah. A three out of five would be 60%, like when armed with real metrics and your organization is committed to talking about real metrics. Mm-hmm then they have to address the situation. But I say that like also ready to say, I've been in a bunch of organizations where like, you can bring metrics, but like, they don't really matter, like opinions matter more than metrics in some organizations that I've been at where like certain people's opinions are more important and more defensible. Like this goes back to the, the, the John co leading changes if you want something outta your organization, but you know, some people are gonna resist. You have to lay out the vision of your organization and communicate to everyone. And the people that still resist, even though you've laid out the change in the organization and they willingly are like, they're obviously resisting. You have to, you have to either have a one-on-one with them and get them to change your behavior, or just cut them outta the organization. Okay. I think of this in the same vein as like if you have people that are changing requirements, even when they're in the sprint in mid sprint, changing AC modifying behavior, changing basically the root of the story as this, I want this or whatever, well, I don't want this anymore. I want this or whatever. Again, assuming it's not a team issue where like if they're starting to work on a story and it has no acceptance criteria, well, we'll just figure it out. We'll figure out the like, mm-hmm that is on the team. Sure. Like not having an acceptance criteria, meter definition of ready. We wouldn't take it out. But if you start the story and the product owner adds exceptance criteria, as the story moves along, either the team didn't spend enough time in planning to figure out all the exception criteria and then split the story appropriately, or the product person has added stuff. Mm-hmm to the story. Mm-hmm yeah. Assuming they've added stuff to the story though. It's an opportunity though. I would see that as an opportunity to coach them. I think so, too. Yeah. Yeah, yeah. Maybe they don't understand that things shouldn't change once space started. Well, they, well, again, what if they say this I understand, but business said, this is imperative. This needs to, but then it's not a failure. Right there. There's a, we've actually met the requirements of the business. Exactly. Yeah. So I would just turn it on turn it to a positive mm-hmm having been on the development side of this issue, I see both sides. side number one is until we started working on it, we didn't know how deep the issue went. Right. Yeah, sure. That, that that's part of our learnings and our capabilities as we learn. Sure. Yeah. As we work on things, the, the other side of this is you shouldn't have committed to something. If you didn't do the investigatory work to figure out how deep it went. Right. Tho those are the two sides for this. I agree on both of those, maybe on the first one, you should have considered the risk. Right. Cause you didn't know enough. Right. And sized appropriately. Maybe just create a spike instead these things can be changed. Right. But assuming that it wasn't that from the team, the product order actually changed the requirement. Yeah. Then that's a coaching moment right there. That's going, feels to change a tire. And the car's being driven at 60 miles an hour. That's what the team feels. They have to scrap all the tests that they've written. They have to start again basically. Right. And that's why it's, it's disruptive in a bad way. Let's go back to in conflict. I like it. Cool. So let's go back to the other hypothetical scenario. You were talking about peer to peer, right? What about superior? Right. So like say you were. Disrespected in a meeting, something wasn't appropriately said, whatever something was was wrong. Whoa, whoa, whoa. I like, I wanna cut in because there's different scenarios here, which is number one, you're being openly disrespected, Uhhuh number two is a, like a superior in your organization than somebody who's your supervisor or whatever is disagreeing with what you're saying. Those are different scenarios. So you, as my boss are in a meeting and saying, oh, Brian I think you're wrong. I like the problem is not that we have 25 minute retrospectives. That's not the problem. Mm. That is different than openly disrespecting you inside of a meeting. This came up , for me recently, I don't know if I even wanna leave this in the podcast, but I told somebody recently when I was a manager. There was a point in time when I was a QA manager, when every employee in my group was a woman. I was the only dude in this that's, that's the only application, right? Dude, woman. Yeah. Um like I was the only uh, man in the organization and every one of my employees was a woman and I would go to meetings like sprint playings, that kind of stuff. And if somebody would disagree or segue on something that one of my employees were trying to question just because I was in the meeting and it was my employee, I wouldn't let it go on first pass. Mm-hmm I would, I would reinforce their question, so that it was discussed by the whole group and it, it wasn't just so like shut down by one person. I make it seem like a male female thing, but it, it really was. Cuz I, I did that even when there were men on the team and women on the team, but it was a very male-centric organization at that point. I don't even know why I'm going on this path. There's a book written on this about uh women that worked in the Obama white house where they came up with a tactic where if a woman in the Obama white house would come up with an idea or a suggestion when they brought up the suggestion, I'm reading somebody else. Yeah. Yeah. Another woman would echo it. Somebody else just, just on principle, somebody else would echo it to make sure that it was heard and, and considered rather than immediately dismissed by the hierarchy that was male dominated staff at the time that, dismissed, not on merit, but because it came from a woman. This goes back to the, it's a good conflict. This goes back to the podcasts we put aside for a second of talking about reinforcing ideas, like our ideas being heard. Why I brought this up was if you raised a point and if that idea is basically dismissed outta hand mm-hmm, mm-hmm , there should be someone that says, Hey, like let's stop and let's explore that idea Uhhuh rather than dismiss it outta hand, you know? So an ally in the room you're saying or should this be you ally in the room? Mm-hmm I, I actually, well, should this be you, if you're in the scrum master role, I kind of think it should if you're in the scrum master role and literally anyone else in the organization is saying, Hey maybe we're not spending enough time planning our tasks so that when we get outta sprint planning, we still do planning along the way while we're trying to figure out how to implement the tasks as the sprint goes along. Mm-hmm mm-hmm maybe instead of spending one hour in sprint planning per week, we should spend four hours, like the book says mm-hmm right. And you shut down and yeah. That's you said here's why that's, that's a ridiculous amount of time. Four hours. That's a rule half a day. Say that. How could I, yeah. Right. Well, the scrum master, well, the scrum master in that perspective could be like, well, well, actually, let's, let's stop for a second. I understand what you're saying. We don't wanna spend too much time having our developers outside doing non-development activities. But, but let's think about this for a second. Maybe instead of one hour, maybe we can do two hours doing sprint planning and see if that makes a big difference and not having to go back into planning, like to be the, and they're interrupting and they're saying no, and that's dumb and you're making too many changes. Why are you doing this guys? Right, right. Yeah. Yeah. Why is she doing this? Yeah, yeah, yeah. To be like that's ex good example of conflict. This is a good example of coming. Hang on, hang on. Why, why are you so opposed to trying doubling the time box why are you so opposed to that? And you're shut, shut, and then he got a crowd. This is all hypothetical. I'm just having fun with it. Hypothetical. I like it. I like it. And so what do you do after that's what I wanna get to that's where I was trying to get. How do you handle it after that interaction? Right. So I think people have handled it wrong, right? Sometimes people will maybe like vent about it in the form of like gossiping, maybe like bad mouthing the person because their ego was hurt. Yeah. That's not productive. That will probably not cause other issues. Right? Yeah. So in this instance, from what I understood, you wanna have that conversation directly with the individual as soon as possible, right. You don't want too much time to ELAP where it's forgotten maybe a day to simmer down, but you wanna be direct with that person. But yeah. I wanna ask you guys, what would you do? I think you're right. But I also think that when you have that conversation with that person tackle the problem, not the person. Right. Tackle the problem, not the person. Yeah. Tackle the problem, cuz it it's not you versus him or her. It is the idea. Right. It's the idea. So going back to your point about the team, just saying why would you say that, blah, blah, blah, right. Again, can we just try it one time? Mm-hmm as an experiment, see how it works. We don't have to continue this. If we don't like it, let's just try it. And then that way, at least they get to try it one time. Mm-hmm that? So, yeah. I'd just say that tackle the, probably not the person mm-hmm I mean, there's always an. Probably someone feels very closely aligned with the problem. Right? Like identifying with the problem. So like, oh, you're saying the problem is me but like you were mentioning you avoid you statements, right? You say, we statements, you make sure they know we're in this together. Right. Why we're doing this? You, you mentioned the why behind it. I also wanna say that in almost every situation, you'd be able to look at the, especially if you're focusing on the problem, not the person. Right. You'd be able to look at the problem and arrive at something you agree with them on. Right. So if they say, well, we shouldn't be doing these events that are two hours long. Sure. Well, okay. So you agree that one hour is not enough, right? Mm-hmm so you're agreeing with them that one hour is not enough, but you're also saying, okay, well I'm not gonna force this two hour thing, but we're gonna try it as an experiment. We'll just try it one time. And if we get done in an hour and a half, great. Let's just try two though. Right? Just we'll book the meeting for two hours. Let the team go. Mm-hmm and see how long it takes them. How about that? If it takes them, if it takes an hour and a half, then in the future, we'll do another hour and a half. And if we find that's not enough, we can always go to two. Yeah. Mm-hmm so find something you agree with them. And then turn that around and say, so we are, we are not on opposite sides here. Right? Mm-hmm , mm-hmm , we're just trying to improve the process here in some way. That's a good way to diffuse the situation. Yeah. What do you think, Brian? It'd be nice to get the product person on your side before continuing for the rest of these discussions, cuz like that, that goes a super long way. Yeah. Yeah. They should be in the team. They should be treated like a team member, right? I can come up with more hypotheticals if we wanna keep going. Yeah. I I'm happy to talk through hypotheticals all night. Okay. One question. I just thought of how do you mentally prepare yourself to deal with this conflict? So in the situation we were just discussing, you wanted to have that one on one early, so maybe the next day you schedule a one on one, you make sure you're not discussing this with other people. You wanna have this conversation with them directly first mm-hmm and then conflict for humans is usually uncomfortable. You know, they, they might get nervous in the conversation. So how would you think someone should mentally prepare to walk into this? I think that's an excellent question. First of all you know what I've done in the past? I don't even know if this is the right thing to do, but it kind of sort of works mm-hmm when we were in person, I would basically find a small room, get a flip chart and I would write in big letters what the problem is. Literally put the word problem. Right? Mm-hmm and then alternate solutions from that problem, just put them down, including the one you want them to pursue. Yeah. Plus the one that they're pushing for, put them there, but also don't limit it to those two. It shouldn't be binary putting a couple of others, even if you have none, just put something in there so that it can be an up down. Right. And then you bring them into the. and so you can still do this virtually. I just haven't had to, but you can do it virtually, right. Just put a mural, Miro, whatever it is that you use. Right. Uh, notepad, it doesn't matter. So when they come into the room say, so let's just look at the problem we're trying to solve here. Right? So the focus is not that person anymore. It's the problem they're coming in like this. What if the problem is them? What if it is how they communicate? So then put that down as the problem is the way in which communication is taking place currently. And if it's between you and that person, I would say that I would say the problem, the way the communication is taking place between us, right? Remember there's no, you still it's us. Now. The problem might be him. Her, you, you just, the you big arrow. They just that's you one of the, one of the alternates there in the extreme case. Because either you leave or they leave or encouraged to leave. Right? Sure. I would put that on the wall. I would just say scrum master leaves, developer or whatever role they're. Yeah. You know, leaves the team mm-hmm right. I wouldn't use the word fired. I would just put that on there and say these are possible outcomes. Yeah. Yeah. Let's talk about these. Yeah. Mm-hmm mm-hmm yeah. At what point would you involve HR? Would you though I've often seen if HR gets involved, it usually leads to the demise of one of the people being employed. It depends. if HR is structured in a way where they are beneficiary to the teams I personally would only go to HR regardless of what kind of HR I had if I really had to, as a last resort, assuming that the relationship has turned toxic, like the person is just called you names or for sure. Insulted you. I mean, any, anything like that? Like there's no, there's no call for that. Yeah. Yeah. But, in the situation you've just described it's he said, she said you would only go to HR. If you expected HR is in the, mindset where they're, they are serving the organizations rather than they're serving the executive team. Yeah. Because if the HR role is serving the executive team and you come to them with a complaint of like this person isn't working, this person is very combative. This person is very sexist, racist, literally, whatever but you are the person complaining you are now the problem that's right. So they think, yeah, you're right. That happens all the time. Sure. That happens all the time. That's why people have this saying keep your head down. Right. Keep your head down. Stay low don't. Cause any problems sense? Yeah. Well, again, going back to the topics of the last podcast. I don't know if we said this in the last podcast, but I know we talk about it in the prep. When the HR rep of your company only works for the exec team, basically the only tool they have in their toolbox is a hammer. And , everything looks like a nail., I don't know how we're hammering on this again to, Hey. Yeah. It's topical, I guess. I guess conversation is it's really not conflict. I mean, conflict in the workplace often involves HR. Yeah. But as like, as a Scrumer, if you like, if you're like, well, I'm dealing with these people and organizationally, they're not being fair and they're, and I see where they're I see where they are. I don't even wanna say mistreating. Like I I've been in development long enough to see a lot of mess up situations where HR probably should have gotten involved like a male development leads talking over female team members, where they would never talk that way to a male coworker. And it's like, how that's the disrespect I was referring to in the hypothe earlier? Yeah. I've seen that quite a bit. Of course. Even being an outsider in that conversation? You were not even in the argument, you just happened to be at the table while the argument was happening. Should you serve as an outside perspective being like, Hey, I saw this happen now we're back to what, what I said is like, now you are seen as a problem. Correct. So now, yeah. So how much of a risk taker are you? Are you risk averse? If you're risk averse, you're probably gonna say, well, let them figure it out. Yeah. It doesn't involve me. Yeah. If, if you are not, you might say, well, that's not right. Yeah. You know, and, and you would take it to HR and yes, you're taking the risk at that point. Yeah. But you depends on what, what your moral fiber tells you. Yeah. But I think if you've, if you've allowed it to go to that level where you're bringing somebody outside in whoa, boy, this is gonna be controversial. You've given up your ability to influence the situation, your ability to influence that situation is in the moment you should be backing up the, the, the argument that you are hearing to say, Hey, wait a minute, you didn't seriously consider this person's opinion. Like, let's talk about that for a. and that is where you can make that is where you can have influence in the conversation. It's not after the fact with the HR part. Cause again, that's a complaint more than HR. Even if we say that the HR person is beneficial to the teams, they are actively trying to help reduce conflict and, and empower the teams to solve their own problems. Even if they are doing that, you're still dealing with a problem after the fact where someone has to come in and they don't know which side to believe in like somewhere between what M says and what Jessica says is the truth. That's not always the case. It's yeah. To your point, the, the, the coaching moment is fleeting, right? Yeah. Right. It's right there. And you've gotta hit it right every time. But, but I would say a majority of team would remember, again, I know we brought this up to say like, does this scrum master have to always be the, the bigger person in the room to be like, Hey, right. Let's all try to like yeah. Uh, spoiler. Yes. BEC because everyone in the room will always remember the person who stopped the meeting to say, Hey, like I understand you're saying we don't need to think about this, but. Do we really not need to think about it. Do you want to consider this person's opinion? Like, and actually talk about it again? Cause everyone will remember like, oh, Hey, Jessica said when om brought up, Hey, maybe we shouldn't be doing this, and Brian, who's a development manager or whatever shot down ah, I don't wanna talk about it. Well, I've made this decision. We don't wanna, whatever. Well, let's move on. It's not important. I don't care about this. And, and Jessica's like, mm, are you really sure you've considered all the options here? Let's just five minutes. I'm I'm, I'll put five minutes on my watch. We'll just talk about it for five minutes just to make sure we've talked about it. I mean, you're already, you're already interceding in a contentious discussion. Yeah, for certain. Sure. But again, it goes back to the, the reason you're using scrum is like, there's courage as one of the, you know what I mean? The courage to speak up as one of the fundamentals, what they got principles, fundamentals. I don't know. It is to say, Hey look are you sure that this doesn't need to be discussed further? Are you really sure? So SCSO should lead by example because the whole team is watching. You still might get shot down. You might. That's great. You're talking to the right guy when it comes to losing arguments. But you've brought them up and reiterated and everybody on the teams. It's gonna be in the front of their brain that you brought it back up to make sure that we talked about it. the funny thing about this is jessica and I have worked with someone in the past where he would be the one to challenge the status quo to be like, Hey, have you really thought about this? Whatever. And the development manager or whatever the time would be like, oh yeah, I did. And I don't care and I don't wanna do whatever. And then he shut him down. Yeah, it would shut him down. And then he would bring up later, like you made this decision and then we had to deal with this afterwards. And then the development manager, whoever made the decision would say I never said that. And like, I remember, like there were many, many situations where the, person that we worked with before would, he'd be like, what are you talking about? You totally made, like we wrote in the story that we weren't gonna go down this road, because you were assuming the risk. And we wrote in, because you we wrote in the comments your ticket or whatever, like we wrote in the comments we're not going to explore the risks of not doing something because in the meeting you said, don't don't go down this path. And I can think of lots of discussions where I've been on the losing side of this and called it back into question. And the, the, the narcissist on the other side of the table has still been I never said that. Right. Must be you. Yeah. Must be you. You're all crazy. And since, so that's legitimate conflict there. That's a certainly is. Yeah, yeah. Yeah. Well, I mean like there's conflict resolution and then there's dealing with narcissists, AKA sociopaths should be a podcast on its own. That should be, gosh, you were talking about that earlier, before we went on air dealing with sociopaths. Yeah, yeah. Yeah. Because realistically, you don't wanna go into conflict with those people. It's never going to turn out. Well, no, you don't. Well, a narcissist, well, the other thing about you never see it's your fault or their fault either. Separate dealing with sociopaths from dealing with narcissists, because the sociopaths that I've worked with that's right. I said that the sociopaths that I've worked with have organized the organization around them. They've kind of firewalled themselves in the organization where they can say things without evidence and they can be insulated where it doesn't hurt them in the organization. So like for example, like E evidence based management doesn't hurt them because they've elevated themselves above like the product manager cycle to where the executives or wherever they interact with, they don't interact on a peer level with the product managers. They only interact with the executive level. So they can say like, oh, well, I mean, yes, we had some production outages, but, it's not my fault. It's those QA people, they didn't test enough or whatever. And if you go to talk to the product, people the product people have a completely different perspective. They'll be like, well, we were doing a bunch of risky stuff cuz the executives were pushing us and said that we had to get stuff done by a certain date. And they wouldn't bend on the date. And uh, we did things and they were risky and they crashed product. because they just told us this is what we were doing. And there was no pushback. And they just told us we had to do things. And regardless of us missing our tests or us failing certain tests to go to production or whatever, like if you're doing TDD or something like that, I'm like, oh, well, 75% of our tests passed, but 25% failed. And the 25% that failed is like critical stuff or whatever, but the VPs or whatever that promised dates said to push it out anyway like that'll get left out of the conversation of course at the level you're right, right. So narcissist sociopaths or whatever. They have a way of insulating the conversations to different levels of the organization where they are protected and they can, cast blame something. So that's terrify platform. Yeah, yeah, yeah. And if you identify that, what do you do leave? Oh, if you can identify it and show evidence to different. Pieces of the organization you've already figured out a way to work around it. You, you usually sociopaths are really good at organizing a whole system around themselves. So whatever evidence you show they'll have a counter to it. They'll this goes back to what we talked about this, oh, I don't like on one of the first podcasts you were on where I was talking about, if I'm an executive and I make a decision based on logical, empirical evidence, that's one thing. But if you have me make a decision based on my gut, feel my emotional feel. So now I have to make a decision based on emotional feel versus empirical evidence, provable evidence which one wins out like logical evidence, data driven evidence, or the way I feel about something. So again, like going back to just the way I came up in development teams the, the sociopaths on development teams are very good at exploiting your emotion based decisions. Mm. And negating any, literally any. logical evidence based management techniques. They're very good at that. Yep. Some take it to an art form as they say, you know? Yeah. I mean, you gotta admire them for that. Yeah. Mm mm-hmm mm-hmm and to come full circle with our conflict conversation, I like it. When in conversation of conflict, it's probably a good idea to remove feelings from the conversation. I feel statements. So maybe just stick to the facts of the situation. Absolutely agree. You can't argue facts. Yeah. Yeah. Stick to the problem. Yeah, yeah, yeah. Keep emotions out. Absolutely. Well. Right. Well, in, in, in my particular case in that organization, the technology people were very good at getting in front of the product, people to the organization, the product people really never set a chance cuz , it was a technology organization that was trying to be a product led organization. So the technology people were all always in front of the product, people mm-hmm, the product people were trying to break in and become at the forefront of the technology. But it wasn't that way when I was with that organization, sometimes it it's just not possible depending on the personalities involved in the organization. I think that's valid. Yeah. And that's something that you have to learn over time. I mean, oh, valid wisdom and also terrible, like valid, but terrible. It's you like running a successful business under that model. How are you gonna do that? Mm. You don't care about evidence. You don't care about how many you're basically saying I don't care about how much I spend to produce a product versus how much revenue, the product gains for me. You that's basically what you're saying. I think you don't care. Describe some major car manufacturers. You're not wrong, but I mean like, like how long can you run the business with that? Like, oh, I feel like we're doing great. I feel we're gonna be awesome next year. Mm-hmm until like, there's literally no money left. Yeah, no, that's not a long-term strategy for sure. Yeah. Hope is not a long-term strategy. No, that's true. Oh yeah. Yeah. All right. Well, to wrap conflict up, I'm trying to think about what I heard today. So one, if you're in the conversation, encourage a break. Right. I liked that. I thought that was, that was good. So maybe walk outside, everyone take a break, right? Uh, you can say something like, mm let's. Take this offline and continue the conversation another time. So those were good points. We also mentioned that after the conversation, we can schedule a one on one mm-hmm yeah. In that conversation, we avoid use statements. We stick to facts, avoid emotion. Mm-hmm focus on the problem at hand. Yeah. And then probably, and we didn't mention this, but probably focus on some action steps afterward. Yeah, absolutely. And I think that the other thing is we said just make sure the problem's visible. Cause if you don't have anything to focus your eyes and the other person's eyes on, then they're focused on one another. Yeah. And you then forget about the problem. You start to get into personalities at that point. Mm-hmm yeah. And one thing I wish we went into and it might be too late. What happens when someone just starts digging out that personality of the other person. yeah. We just keep orienting them to the problem. Redirect, if you have it displayed right, then you could say, can we agree that this is the problem we're trying to solve? Forget about the solutioning part mm-hmm mm-hmm yeah. Can we agree on the problem? That's good. Yeah. So you start off the bat, even if you agree on the problem and nothing else, you've started off by agreeing with them on something mm-hmm and that's always a good, it's always a good entry into solving the problem because it's basically starting with ground that you've given mm-hmm they feel you've given some ground, right. And that's always a good way to negotiate politicians do this all the time, especially when they negotiate global, with other countries basically, right? Mm-hmm they always go into it with something to give. They know they're gonna have to yield a little and some people are very effective at that. They'll just go in and say right off the bat, this is all I can give you. Yeah. Right. Mm-hmm so right off the bat, if I come in and say, Brian, I let's solve this problem. I'm willing to give you this, but that's all I can give you. He's gotta feel good about that. Sure. Cause he hasn't done anything to get that. I'm I'm just giving that I' surrendering. That's right. I saw Hamilton. I know you're talking about . That's good. And then we also mentioned, we should observe, we should observe who we're dealing with. Are they a sociopath? Are they a narcissist? If so, we're gonna have to deal with this a different way. Maybe it isn't to deal with it at all. We know, like we can't get through to this person. It will be emo emotionally energetically, exhausting to do so. Yeah. So at that point you can leave the organization. It sounds like, and maybe worst case scenario bring this up to HR. Oh, I thought you were gonna say burn their house down or something's worst case scenario. I was gonna say with the house down, but you're right. talking to HR. Yeah. Worst case scenario. Yeah. You're right. I agree. We covered a lot of ground today, so thanks for hanging with us. Yeah. Everybody, both of you. Yeah. It was a good topic and then it became weird. We went off to a weird place. I feel that was mostly me. And we went super long on this. Like I'm, I'm kind of shocked how long we went on this. And we could have gone longer. You know, one thing I didn't ask it's too late now we wrapped up. But one thing I didn't ask was what happens after the one-on-one like, how do you measure success of that? One-on-one that's a whole nother success. That's a whole nother podcast, one-on-ones that's the podcast one-on-ones is the podcast. All right. Cool. This is a great topic. Thanks for playing.