AA136 - Selling Management on Retrospectives

This is going to be a good one because I did not allow him to see any of the notes going into this podcast. So we're going to get his. It's off the cuff, pure reaction. How can I sell my management? On retrospectives. Yeah, that's a great topic because oftentimes management, didn't say leadership, management don't really understand the value of retrospectives, right? The work is already done. Why aren't you working on the next? piece of work that I asked you to do, because they usually demand there's no thinking involved on the team's part, they are told what to do. So unlike in David Marquette's book, they're not giving you intent, they're giving you direction. But anyway how do you sell management on retrospective? Well, I think you can look back at historical performance of your team and say, going back five sprints, six sprints, use something like n equals Four or more, probably and say, here's how we were doing. And here's how we progressed from one sprint to the next in terms of our our team output because they probably don't care about outcomes. So if you look at it from that perspective and then pose the question Would you like us to improve next sprint by 5%? 10%? Right? That's how you sell it to them or at least pitch it to them. You haven't made the sale yet, but you can pitch it to them and say, if we get together for an hour, hour and a half, we can figure out ways that we can improve our process so that we can have better quality, perhaps more. Work that we can get done because we're, we're stopping bad practices and so forth. Have that discussion and get there by into at least try it for one or two sprints. It's don't ask for this thing for ever, right? Because they're probably going to say no two hours every two weeks at times of six, six, seven developers. That's a lot of time. So just ask for a couple of sprints and say, let's come back to this in two sprints. You're already started. Going down the road that when I heard the question originally my brain was headed down was You probably have a management team or at least specific managers that are saying in their head They're doing what you just did in your head you touched on and then like moved on You probably have a PMO to be honest if they're saying wait a minute, it's it's an hour every other week It's an hour every other week and there's ten people on my team So it's 24 retrospectives in a year with 10 people. I've got to now I've got 240 man hours, so basically I'm losing six, six weeks, six weeks, a month and a half of work. They think that's the way that it would look at it is I'm losing a month and a half of work. Yeah. Rather than, so I, I also I remember I don't remember if I watched it on a podcast or I heard somebody say, I can't remember where I picked this up over time. But I remember hearing someone say, if you're going to steal anything from scrum, and abandon all the rest of the events in Scrum. The one thing you should keep is the retrospective because it's the only time that we look at what we're doing, the processes of what we're doing, or the work, or both, and decide what can we change to make this better. So at least we're incrementally approving. Incremental? Incrementally? Did I say that word right? Okay. Yeah. I don't know why my brain is like, that's not the right word. At least we're incrementally approved, improving, I think, improving. I said, approving we're approving and improve. We're improving the improvements. Nevermind. Incrementally. Incrementally. That's right. That's a fallacy. First of all, obviously, as everybody knows, right? I mean, one of the things that you can do in the spirit of offering things to kind of mitigate this situation, right? I mentioned that you look at. Historical numbers only for the from the perspective of pitching it to them that we have done what we've done, right? You may not have improvement. Maybe it's not a linear improvement Sprint on sprint if you've done retrospectives because it depends if you actually put these findings into practice or not But just show up show the numbers for what they're worth and say on average we could potentially improve again No guarantees. Potentially improved by X percent. 5, 10. Right. If we examine our processes. So another, another thing you can do here is to say, listen, over the last 5, 6 sprints, we had churn on the team. So not everybody is attuned to how we work together as a team because we have new team members, right? So we need to sync up again. And that's a good way to do that at a retrospective where we can not only use it to reflect on our sprint, but also. Impart how we work and kind of bring in the opinions of the new person and, and maybe we'll learn something new from them. Let's go back a second to the first category of, of the, the book. The what? The note I wrote down was highlighting the r o I. Yeah, for management and I also I'm assuming at this point if you have to if you have to go in front of some board or whatever, like you're not really talking to leadership. You're not talking to the decision. You're talking to some gatekeepers in the in the organization or some middle managers. You're stuck. You're stuck in middle management purgatory that you you have to get through these gatekeepers to actually make meaningful changes. Improvement. The organization. Sorry about that. Keep your resume updated. But what I wrote down was highlight the ROI because in your example, you went first to, I'm going to start tracking what we're doing and I'm going to have metrics for a baseline of how the team is performing on a normal basis, right? For a normal day to day type of operation. And then I'm going to suggest an improvement and measure again after the improvement has been implemented. Right. And I'm going to use this in order to get a little more leeway. A little more runway to do more of this type of thing to make it a regular thing in the culture. So you're, you're doing two things. Number one, you're starting with a data focus of, I'm going to gather some data and then, well, we're going to say, why don't we try something and then try it, right? You're doing that. So highlighting the ROI, the other thing I wrote down in this category is the thing that we suggest over and over again, almost every podcast is starting small, say, Hey, why don't we try this small little thing that doesn't impact? Maybe it doesn't even go outside of our team. Maybe it's just our team, or maybe it's a few people on our team. Maybe even start even smaller. So those two things go together. It's measuring writing down and measuring your experiments in your observations in data so they can't be disputed. Right. And then starting small to make small frequent improvements rather than trying to do a big bang or whatever. Absolutely. Yeah. So the keyword there is small other than the experiment, which I love small, right? So if you get together with your team for a retro and the team identifies, let's say three, four things. Pick a couple. Chances are slim that you can actually implement all four things to their full potential just in the next two weeks. So pick a couple, but you know, make sure that the team understands those are the ones, those highly voted ones possibly, that you're going to focus on. Then you'll have a better chance of showing progress to management on those two things, right? Yeah, fully agree with that. Start small. And stay within your team is a good one because if you have... Retros off teams and teams. If you're if you're in some sort of scaled environment, let's say it's a it's a lot harder to illustrate. Success after getting approval to use retrospectives for a sprint or two because there's too many moving parts. You have your team. You have another team or possibly more teams. So the effect of that improvement is is hugely diluted typically. you kind of alluded to key stakeholders, like the John Cotter, like the guiding coalition getting, getting your people together that are on your side. But this, this could be more than that. This could be getting by. And I think of like transforming agile transformations, like you have the one person in the organization that is basically supporting the agile transformation. And when that one person leaves the edge of transformation kind of like goes away. Slowly, kind of slowly collapses after they're gone. I don't know why I did this. That's a slow collapse. Yeah, it's a slow collapse. I don't know. It's not getting any better. It's an implosion. It's an implosion, yes. Yeah. But talking to those people one on one and getting buy in from what you're about to do before you do it. Again, in this theoretical world if you're at a small startup, You probably don't need to do any of this stuff. You probably get everyone together in a room and it's like, Hey, I want to do this. And then you just do it and you go for it. And they're like, way to go, Brian. You're a go getter you're basically Nike in it at that point. Just do it. But I like the idea of the one on ones because again, we're talking about management, right? They probably aren't, I was going to say well versed, but even aware of the agile ways of working. So this whole idea of the team getting together for an hour, hour and a half every two weeks. To just discuss and natter about what they've already done. That's border under bridge. It's done. Get on with the new. So it's, it's a good way to deal with this by having one on ones and say, this is how we work, right? So educate those people. You have to do that. Another thing that I thought about the sort of in line with this. Along with highlighting the ROI and building support with your with your stakeholders, building support within your organization, basically. Well, building support. That's what it really is so another thing that goes with that is trying to figure out Which things to improve in which order like sometimes some teams these like this needs to be improved over and above or anything else. This will have the biggest impact I mean, this thing, which is small to change will have the biggest impact, that kind of thing. But I kind of think if you're trying to do this, you can align the improvements that you're looking to make, With business objectives, like directly aligned with business objectives, like now you have even more firepower to go about doing it because you're saying like, Hey, we want to improve the we want to improve the customer experience and in order to improve the customer experience, we're doing this automated testing and you know, here's how it directly aligns to that. So I guess. This is sort of sneaky though, because some of it is aligning to the objectives and some of it is like just plugging anything anyway to like, well, this, if we do a, then B, then C, and then we'll end up on planet Z like, I don't, I mean, you gotta be able to tell a good story, right? You absolutely do. So the team's ground reality is you have some areas that you can improve on, and most of us have seen areas like not delivering the sprint goal fully or not delivering everything the team took into the sprint, for example. I mean, these are, these are fairly, frequently encountered. I was gonna say common, but yeah. So one of the things you can do is to look at the opportunity cost of the equation and say we missed two stories out of the six that the team took over into the sprint took into the sprint rather. So those two stories represent What? A third of commitment that we didn't make, right? We didn't actually meet. In order to not do this kind of thing in the future, we need to figure out what we did that we need to stop doing. Right. And sell it from that perspective. That's a, I gotta think about how that would go over. Well, PMOs are always looking for you know, percent complete, right? That's why I say that. But if you have leadership, then yes, the outcomes, customer experience, all of those things matter, right? Yeah, well, also like, I'm thinking about like think about like a team of leads, like a team of leads that's across programs where they're all like the development leads, QA leads, stuff like that, you know. But they in in and of themselves are a team, even though they're not really like, they don't sit together and they don't they're distributed to the rest of the organization, but they're, they're enablers basically for, and I'm thinking of a team like that doing retrospective is that the, the, if the organization comes with a goal of, I want to improve our say do ratios. For the leaders of the organization, the leadership basically, when someone in my company in leadership says they're going to do something, I want to make sure that they're doing it like show, show me those numbers and then let's as a lead at a team of leads, let's talk about what we can do to improve it. Like I, I think at one time, one at one company I've ever been, I've ever heard anything like this vetted and then never follow through. I don't know. I don't know why teams do this. Like what is our say do ratio? And then they commit to improving by not rolling stuff over sprint to sprint and stuff like that. I've seen team fixes. Definitely. I put that on a dashboard for the teams, but to go back to your point about leadership, right? So don't wait till the end and say you'll say do ratio is X have them. We always say this on the podcast. Leadership should have a Kanban board. All their work should be visible. So when their work is visible for the sprint, the duration of the sprint and it's sitting in the to do column or sitting in progress and not moving, the time to kind of nudge them along isn't at the end of the sprint. It's every day you're looking at this saying. Listen, Mary, John, whoever, right? You're supposed to do this. How can we help you move that ticket to the column to its right? That's the question. So you're not saying you didn't, you didn't do this, right? But you are saying that in a way, right. You're just saying we're all accountable for this work. This is, this is your piece of work here. And yeah, yeah, let's go. I know we're not talking about disagreements, but like this is prime area where the scrum master can step in. To start coaching the organization and that the organization doesn't even really realize they're being quote coached, right? You know, I I did this I was I wasn't really a scrum master But it was a scrum master thing to do where I walked into the CEO's office he had a big whiteboard on his wall and you know, I walked in there with my I don't remember if I walked, I don't if I had tape. Did you take, did you take masking tape or did you take masking tape? I don't if I had ma I don't remember if I did it with markers or tape. I either did it with markers and like a, I don't remember, like a big straight edge you know, like a yardstick or something like that as a straight edge. I either, I, I did it with markers and straight edges, or I did it with actual tape. I, I can't recall. But I remember the lines being actually straight. Cause I use something. I don't remember what I used. Anyway, the straightness of the lines is starting to become the point of this story. That's weird. But I, I remember I said every, every executive you need to have their departments as swim lanes and then the executive speaks as a swim lane. So what is sales doing right now, what are they doing right now? Well, they're trying to sell this. Well, engineering is not building that. Why are they selling that? You know? This is basically start lining up and then, and then there's, there's product stuff, but then there's all product marketing stuff, but then there's also like internal culture stuff. Where does that live? Does that live on this? If it doesn't live on this board and it's, and you don't have any other way of capturing it, I'm going to assume it just isn't getting done. It's probably getting lost actually, if it's not there because if it's not there at this level, it's probably not there at the lower level. So. To, to carry your example for just a little bit. Let's say the, the CFO's there, so they have a, a lane on that board finance, and there's stickies that represent initiatives that they're working on, but the finance person gets to talk about that, right? The, the, the head finance person here, leadership, probably a C-level person. Mm-hmm., but they're not executing on it. What they are accountable for is moving that forward. Typically delegate that down to their team. If it's not on this board, you can be sure it's not on the team board either. Right. Cause the team's so mired in the day to day. Yeah, I always wanted to go into an office like that and just use like a permanent marker to draw these, even if they're not straight. Yeah. So that they're captured perpetuity, but blue tape works well. And every time you go through a corporate restructure, you got to repaint the wall. Cause you got to change your teams. That's right. Now this it was pretty easy because the, the, it was a small company and they only had I think three C level executives, maybe four. So it was like a four swim lanes and every department and every person in the organization was captured under the swim lanes. But it's like when you hear it, when you go in front of the company and you hear like company events somebody might say like, Oh It's hard to hire people because you know, traditionally we pay below the market, whatever well, I'll have a HR CFO or somebody pull some salary surveys, the current salary surveys to see if that's true or not. I remember I was like, I was at a company one time where I heard that we heard that all the time. So we always assess the market and we always looking at, we want to be competitive. We want to have, make sure we can retain and hire the best people. And then that you'd hear, you'd hear that in all hands meeting and then. Nothing, nothing, nothing and I'm like, is this just something you guys say in the old hands and it goes that this is what I'm, this is the, this is the say do ratio I'm talking about now what's coming up with the, Oh, we're going to move, we, we might move corporate offices. Well, we'll let you know when we figure it out. Well, when are you guys going to figure that out? Who owns it? Who owns that? Where does it live? You know, who can I go to when I think, I think about JIRA is like at any time as a product manager, you can go to my backlog. Okay. Click on the item that I talk about in my law, like high level updates. And you can go read all the details you want you. If you really want to be in the know, my S my system is completely transparent to you and it's allowed, it's no problem. You know, go click it, but I know you won't, but it's there in case you want to. So a Kanban board like that, especially the leadership level, it's not a one on one and done right? You treat that just like any other Kanban team. In other words, you meet every day and say, what is stopping us moving any of those tickets? No, what's stopping us moving it to the to the right? We're talking about Transparency as well as accountability in the bigger picture. So you have X number of C level folks that are all in the meeting, right? And they can see that a promise was made, the say piece of it and then the next day it's like, Okay, what do you need to get this to done? Right, right. Unless you're doing that, Yeah, you're just wasting time, honestly. Yeah. Because eventually things will just get... You know, swept away. Well, I would, I mean, I think you need to do something like that in order to stress continuous improvement like you can, you can we started off as like, well, highlight the ROI and. Connect get, get your, get your posse together and roll, roll out on your horses from town to town in the old west or whatever. But you know, can, and try to connect to the business objectives while you do it, but it's much better to make it visible and then to make it, to actually make it. Functional. And now it's part of their now, now it's here every day. Yeah. The guy in coalition you referred to is the who part that's, that's obvious, right? You need to know who, but also Carter did talk about the burning need, right? The platforms on fire. Yeah. So we need to create that burning need. Otherwise it'll be like, well we'll get to it when we get to, because we're busy. right? So there's always things to do every day. Are they the right things to do? And then if you've already committed to some sort of initiative as your transformation yeah, this needs to happen daily. So you need to remind them, you need to remind them this is why we're doing this, right? And that say do ratio should be charted as well, just like the team say do ratio on a, on a dashboard. There should be an executive leadership dashboard and people can see What the overall is, as well as what the individual say do ratios are. I mean obviously, like you start with the people that you can convince first, and you build from there. You know, I, I I once pitched a community of practice for different departments. You know, the developers usually are the first people to actually get it running and have it be. Useful back in their work because for developers to share the learnings and things they're doing, like actually show show pieces of code that, that they're using or show new technologies that they've implemented. What, I don't know exactly what the variances, the proper frequency is, but it's pretty easy to start with developers. It's pretty easy to start with scrum masters although I don't know how many. Yeah, well, that's a problem in and of itself. They have more than one team, but I think the guidance around the frequency is you know, no less than once a month on these on these community practices. But this is something that again, if you're trying to educate and you don't have the option of getting help, I mean, I guess that's another option that we probably could explore is you know, once you have, Highlighted the ROI and said that we could, there was significant savings in this, should we start doing these retrospectives and, and treating them seriously? Can we get someone who is actually experienced in running retrospectives to come in and help us for a period of time, whatever, you know? Yeah, as a, as a means to kind of jumpstart, yes, that's a great idea because this requires facilitation skills and not everybody has those on the on the team, right? Scrum masters should have them. I'd argue anybody on the team should have them, but specifically scrum masters and product folks, because you're always dealing with different audiences. You should definitely have those, but that's not a given. So yeah, bringing somebody in for a period of time to kind of jumpstart your retrospective is not a bad idea. You're going to convince that those management layers, right? Why are we doing this? And we're spending money on this? Are you saying middle management is lacking facilitation skills? Oh my goodness! Completely. Tell me other things I know. the continuous improvement aspect of it. There's a marketing problem. With continuous improvement, I feel like that. Once you're once you've highlighted the ROI once you've gone around just key stakeholders And once you said we can do XYZ like now You gotta do it. Congratulations You've got to do it or at least you've got to paint what you have done in the most I was gonna say positive marketable light that you can, because everything's, listen, everything's riding on you know, this is why it's important to pick your battle. This is why I say pick the areas of improvement that you know, your team can improve upon quickly in the first few sprints, because it's a CEO, you're trying to sell this whole idea that retrospectives are a needed and be valuable. So if you can do that, right, then it's easier. To meet your own say do ratio right there and say the team decided to improve on these two things Here's how we did right show tangible improvements as a result of Breaking down stories smaller, we were able to complete more stories than not. We had one left over, and that's because of lack of clarity on the requirements. Here's what we decided to do on that. Like, just build on it. Right? Sprint on sprint. And, don't stop there. Don't, don't, don't stop. This is what I call mechanical facilitation. Don't just say we did this many stories instead of this, that many. What is the impact of that? Right? As a result, we delivered. This feature to the customer, right? Or in UAT, it doesn't matter, whatever it is. It's a real benefit that resulted from this retrospective and process improvement. So if you can do that, I think you'll, you'll soon get those people to leave you alone. And you can actually get on with doing retrospect is every single sprint. So say what you're going to do, do what you said you were going to do, and then go back and talk about it and say, this is what we said. Here's what we did. And we've done it, so we're going to keep doing this, right? Don't ask permission at that point. What if the pushback is I had a, I'm, I, it wasn't exactly this exact pushback, but it was very close to what I'm about to say. It basically was, you guys don't need to spend a bunch of time not coding without hands on keyboards, doing these retrospective things. Whenever you have an idea... Just bring it to me, the VP, or director, or department, or whatever, and I'll, I'll implement the improvement. And then you don't have to waste, and I'll, I'll get rid of the bad ones and I'll keep the good ones. And you don't have to waste time with the whole team. This is classic dictation. And you'll, you'll implement the improvement. So how, how do you exactly do that? Cause you're not hands on coder. Anyway, you're going to tell people that are. Do what I say, this is again, directives, right? So remember David Marquette said directives. If you want people to think, don't give them directives, give them intent, right? If you give them intent, then they will think and come up with the best solution. You're not going to convince the manager who says that to you, right? So here's where I, I don't know if this is even right to do this on the podcast. Here's what I, what I would say. Somebody like me might suggest doing some guerrilla tactics here. Do the retrospectives. Nobody knows you're doing them. Then what happens? Right? So you have less pushback because, well, no one is aware that you're doing them. So get your team together. Sneak them in. You don't have to necessarily do them as a stand alone event. Preferably, you should do that. But if you're prevented from doing that, or there's a lot of pushback against it, Have another refinement session. Refine a story in that hour, hour and a half. One story. And then spend the rest of the time on reflection. Change up the word retrospective when you're discussing this with your teammates. So one of your teammates doesn't blurt it out to someone, then it gets up to you know, management. Oh, that was a retrospective? No. That word isn't talked about now. We're simply going to reflect upon how we did. When I look back and see how we can improve any of those words, like whatever, pick something, don't use the word that is a trigger word, right? So guerrilla tactics sometimes. You know, work, but you have to use'em sparingly and you have to use 'em exactly when they're needed and no more. Mm-hmm. My example was the opposite of team empowerment is like, Hey, yeah, definitely team disempowerment. Yeah, that's right. Yeah. I'll, I'll just tell you what you need to, like what I'm trying to think if, if this is, this is a completely different podcast. The, the topic of team empowerment, but I was gonna say may, maybe just because we are here. Like if you are working for a manager like that, that completely is the opposite of team empowerment other than just do it and don't tell them, which I can't, which I am a big fan of, but also like keep your resume updated with tactics like that. I'm not saying it won't be effective. I'm just saying like, that's the kind of environment where, because usually managers like that. They have, they have their, quote, eyes and ears out in the organization. They sure do. And the minute the retrospective improves productivity, they'll be the first ones to claim credit for it. And the minute that something happens that does not, Then they will be blaming you and saying that you did it behind their backs. And you know, all the, all the negative connotations that people might think of cause cause every, any team that's actually empowered, this wouldn't be a problem. The team, the team is managing themselves. The team is organizing and managing themselves. They say they need to stop and examine something and figure out how to improve it. Then they're taking the time and doing that. I trust the team to do it. This is the opposite of that. The opposite of that is, well, obviously, right? I mean, you don't trust the team to do it. To your point, though, about getting blamed and them stealing, robbing credit. We shouldn't be in that. Market of like working for the credit. However, however, we should be in the market of deflecting blame when it's not deserved. I'm a full proponent of that. So when something works well, and let's say the team actually made an improvement and you can show that, right? Go back to that manager and say, thank you for letting us Do the retrospective as a result. Here's what's happened. In other words, implicitly, you're giving them the credit for allowing the retrospective to even take place. Think about what's going to happen the next time you want to do a retrospective. If you've done that, right, chances are high that they're going to say. Oh, okay. Because they're getting something for free. They're not doing any work. They're getting the credit. Now let me talk about the other side of the equation. Getting the blame for it. I mean that's a, that's a really smart tactic, but like, I just want to pause here and and say that's a really smart tactic because it, it, it, it helped the person in my situation narcissist. So it really would have made an impact on that individual to just shoot out an email, kind of going in front of them to say, Hey, we made an improvement and it had nothing to do with that person. But I want to thank that person for giving us the space, and the time, and the support to come to this decision ourselves, completely separate from, it would have completely worked, and, and, and that individual, again, giant narcissist, , it would have completely flown under his radar because his head was so full of hot air, he wouldn't there's no way he would have intercepted that. He also couldn't read. I don't, I don't really care. Well, listen, a couple of, maybe more than that, a few jobs ago, I had that exact situation where this person was... Basically just saying I want everyone to be fully utilized, blah, blah, blah. And I use this tactic without even recognizing that I used it. That's what I was looking back on. Gee, that person changed. Wait, what made him change? This is what made it change. So yes, get ahead of that. Give them that. And I did something a little bit. Kind of risky, right? But I'll put it out there. Risqué. A little risqué. Yeah, let's use our French words. Here's what I did. I, I invited them to the first retrospective. And I invited them under an agreement, which was the retrospective is for the team to reflect upon the practices of the team. You're a fly on the wall, so I will keep you muted. So you can observe what this thing is all about, right? So we come in, I always, always, always start my retrospectives with the prime directive. So I did that, kind of went over his head, but that's okay. And then I get into the icebreaker, right? Because the team just spent two weeks working hard. We've delivered something. So the icebreaker part, I could see kind of I could see his face getting all like, what are these people even doing here? That was only five minutes as an icebreaker. And after that we get into this. People were free spiritally just like putting in, that's not even a word freely. It is now. Putting in their thoughts, anonymously. Mm hmm. On stickies. We were still using at that time we were just using a like a rudimentary collaboration tool, but it was a digital tool. Sure, sure. So they would put their stickies in and nobody knew who was writing what. And then they voted. Right. So the highest democratically, the highest vote getters are what we discussed and When it came time to pulling them into adopting them as actions, I asked the team, which ones? Obviously the the highest voted ones are prime candidate. We don't have to take them if we don't think that we can actually deliver them in the next sprint. Now, do you have to deliver them in the next sprint? No. But given the situation where we were being watched by hawks I wanted to make sure there was some tangible improvement at the end of that two weeks, the next two weeks. And the team only voted on one. I mean, they voted on two or three, but they said, just take that one because we know we can deliver it in good faith. But as a stretch goal, can we pick up another one? And I'm like, what to do now? Because this guy's aware of stretch goals. He's loaded us up before with stretch goals to do with work, not retro items. And I refused them as this is not a good idea, but here's what we do that. Number two, we're going to keep that right. And if we deliver on this, like if we actually adopt these practices, then we can pull that in and we may not deliver that because depending on when you pull it in, in the next sprint, but then we'll just float it over to the sprint after. Yeah. Right. He saw the process, but the point, sorry, long, long story long. the point, my story was When I invited him, I said, if you want to contribute, you can. And he said, you're going to put me on mute. How can I contribute? I said, well, how about buying pizza for the team? I asked. It was declined. That's fine. So in the email that went out, the sprint after, I basically said, thank you for giving us the opportunity to, to perform a retrospective, blah, blah, blah. Here's what we said we would do, here's what we did, et cetera. And the team loved. The fact that you're supportive and they're looking forward to having you back this time with pizza. There's a little bit of pressure now, right? But anyway, I'm not necessarily saying you should do that. I'm just saying that there are ways to do this, right? Come up with your own way, but be brave. That's a brilliant idea of how to bring people along, you know. And honestly, how to turn enemies into allies, because that's really what happens along the process. You know, again, assuming they can be quiet for... Period of time. Well, remember you're facilitating the meeting. That's true. You have control over the mute button. That is true. So be courageous and use that mute button and also Keep that resume updated, keep it updated. Third time on this podcast. Oh, this is like, this is a, this, I just wanna have a quick, a quick sh you know, short to the point podcast on this subject of selling management on retros, it could have been selling management on anything. Anything like retros is a good one to sell 'em on. Like if they're gonna lift any piece of Scrum and implement it in a vacuum outside of a vacuum, in an atmosphere, I don't know if they're gonna implement it, try to implement it anyway. Right. This is a good one. And you know, scrum master, you listen to this. What a great opportunity. What a great opportunity to move around the organization. Oh, you guys are not using scrum. Let me bring this piece of scrum to the other teams. And now I've got now I'm way more valuable to the organization. So when there's a 5 percent reduction in head count because you know, we need to Move some numbers around on a spreadsheet or whatever, you know Maybe they think twice about reducing the the only person with advanced facilitation skills. Absolutely This is your chance to not become a red cell on the spreadsheet. Absolutely we like this podcast. I hope you like this podcast. Yeah, I learned something I learned a great tactic just ignore my Manager and do what I want. Yeah, just like it. Listen, let us know what you think about this podcast subscribe and like below And yeah, let us know other topics that you want us to talk about.