Many agile struggles don’t start with the team. They start with leadership decisions that seem reasonable but create friction, confusion, or misalignment over time. In this episode, Mike Cohn outlines the patterns that most often hold organizations back and what leaders can do differently.

Overview

In this episode, Brian Milner and Mike Cohn examine the leadership decisions that most often derail agile efforts. Rather than focusing on team-level practices, the conversation centers on how leadership behavior shapes outcomes across the organization.

Mike highlights several recurring issues: treating agile as a process change instead of a mindset shift, scaling before understanding what works, limiting product owner authority, and prioritizing speed over focus. He also addresses how well-intentioned leadership actions can unintentionally slow teams down or create dependency.

The discussion emphasizes that agile is not something leaders delegate. It requires changes in how leaders make decisions, set boundaries, and engage with teams. When those changes do not happen, teams may follow the motions of agile without seeing meaningful improvement.

If your organization is “doing agile” but not seeing the expected results, this episode offers a practical way to assess where leadership decisions may be contributing to the problem—and where to adjust first.

References and resources mentioned in the show:

Mike Cohn
#118: The Secrets to Agile Success with Mike Cohn
#143: What Still Makes Teams Work (and Win) with Jim York
Why Teams Matter More Than Ever for Innovation by Mike Cohn
How To Fail With Agile: Twenty Tips to Help You Avoid Success by Mike Cohn + Clinton Keith
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Auto-generated Transcript:

Brian Milner (00:00) welcome back Agile Mentors. We're here for another episode of the Agile Mentors podcast. And today I have the one and only Mike Cohn with us. Welcome back in, Mike.

Mike (00:11) Thanks for having me, Brian. It's good to be here.

Brian Milner (00:13) ⁓ We really love having Mike on the show and wanted to have Mike on the show this time because we wanted to talk about something that I know is very relevant in today's world. I'm encountering this a lot with some of the people I've been talking to in classes and consulting, but it's about the things that often derail Agile and specifically the leadership decisions that derail Agile. ⁓ So let's just start there. Mike, when you look across

all the organizations you worked with over the decades, ⁓ what are some of the most common and maybe even most damaging mistakes you see in Agile initiatives?

Mike (00:52) Sure. That's a great question, Brian. I think one of them is treating agile as a change of process rather than a change of mindset. And we've got to think about this as getting people to think differently, not to just talk differently or type differently on their keyboards, right? So it's a mindset shift. think that's one of the biggies. Another one is leaders not doing their part. Leaders thinking this is just something teams do, right?

Let's do agile. ⁓ I wrote a check to a scrum trainer or a coach and I'm done. No, you're not done. If you're the leader, there's a lot more to it than that. ⁓ Another one there's, there's more, but I was just one more now would be ⁓ not empowering product owners, right? You know, we end up with product owners and organizations that they're not really owners, right? They're, they're just kind of shuffling backlog items. And so I think that's a common problem.

Brian Milner (01:50) Yeah, I agree with you on all of those. And I know there's a lot of depth in these topics. ⁓ just, I'll throw this out to everyone listening if you're kind of following along with us. If you don't wanna furiously scribble down notes as you go through this, we have put together a PDF for you for this episode. It's called the six leadership decisions that most often derail Agile. And that'll be linked in our show notes. So I know some people like to.

have those things in front of them when they go through. If you want to do that, it's fine. If you want to double back later and do it, that's fine. But we did come up with six of these things. ⁓ And the first one is Agile as process versus leadership change. ⁓ I know a lot of companies adopt Agile practices like you talked about, ⁓ but they still end up struggling. ⁓ Why do you think that is?

Mike (02:41) think it's because when you, when you just change the practices and you don't really understand why you're changing those things, you have somebody just kind of going through the motions of, of something. And there's, there's this story that a lot of people have heard. It's nothing new with Agile, I always hesitate to say it because I mean, the story is like probably like 80 years old, but it's this story about a young married woman who is making up

pot roast for her husband. I don't even know what a pot roast is, but I know that's always what it is in the story, but they're making a roast and they cut the end of the roast off. And after being married a few times, making the pot roast, the husband asks his wife, why are you cutting the end of the pot roast off? She goes, I don't know. My mom always did it that way. Right. And so the young married woman calls her mom says, mom, why do you chop off the end of the pot roast? It tastes better. Why do you do this? She goes, I don't know. Grandma always did that. So mom calls grandma and asked grandma.

And grandma says, well, it never used to fit in my pan. And it's it's totally silly story, but it shows the going through the motions thing. And, my, on the same cooking concept, my dad is the one who taught me how to make scrambled eggs. And he always taught me to put water in scrambled eggs, just a little bit of water, a little bit of milk. And I never really knew why, but I always put a little bit of water, a little bit of milk.

until the advent of YouTube telling me that that helps the eggs get fluffier because it evaporates and they fluff up or something like that. But I had no idea why, but I did what I was trained to do. And when you just go through the motions, you really have not made much of a change, right? I might've been able to make decent eggs following my dad's instructions, but really didn't know why, right? And so I couldn't handle anything that came at me out of the ordinary. couldn't, I can extrapolate that recipe.

And so I don't think agile fails because teams won't change. It fails because leadership doesn't change, right? Leaders have to change in how they're interacting with teams and they have to make this more than just going through the motions, just following practices. You can't delegate agility. You can't say go be agile and just end it there. It doesn't work.

Brian Milner (05:00) Yeah, completely agree. Because I think the purpose behind it is so crucial to understand. Otherwise, like you said, it's kind like you're just going through the motions and you don't really even understand what you're trying to accomplish by going through the motions. So how can you even assess whether it's successful or not? ⁓ Whether it's doing what you intended it to do or not? ⁓

Mike (05:20) Mm-hmm.

Brian Milner (05:26) So I agree, I think the purpose behind it and understanding kind of why we're doing what we're doing is really, important. ⁓ Otherwise you end up with kind of these zombie teams. They're just kind of going through the motions, but they can't figure out why isn't this working for us?

Mike (05:41) Yeah. Yeah. I mean, what's the point of a daily standup? What's the point of sprint planning? Right. It's like, okay, I don't know, but we'll do one. Right. And that's not agile. That's not agile.

Brian Milner (05:47) Yeah, exactly.

Yeah. Are there signs that you could spot this in a team if you don't know whether your team is struggling with this, not understanding purpose, and anything you'd look for to try to know whether that's happening or not?

Mike (06:02) What it is just when it, when you see a team just kind of doing these activities, meetings, activities, whatever they may be, mindlessly, right. Without any passion for what they're doing. Right. And I don't want to, I don't want to say I ever get passionate about going to like a daily standup meeting. ⁓ but if I understand the benefit of those and I've seen the benefit of those in the past, I, I do enjoy them. Yeah. Most of them are, you know, ended up being a waste of time. Nothing important came up that meeting.

But the, you know, one out of every three or four, where something important comes up, I'm very happy I was there. I do get motivated by hearing my teammates do work. Right. ⁓ and when a team doesn't really understand the purpose of those, and it's just people showing up, go, did this yesterday. I'll do this today. No blockers. Right. That's worthless. Right. That's the team that doesn't understand the purpose of that meeting.

Brian Milner (06:57) Yeah, I absolutely agree. Yeah, so I think that's a really important one, right? First, let's try to understand what the purpose is. I think another one of them that you kind of called out in our PDF is really talking about this idea of scaling too early. I know this is a story I tell a lot of times in classes where I talk about this one particular group I worked with where they were trying to become agile. no, they were coming from a waterfall kind of background.

Mike (07:26) Mm-hmm.

Brian Milner (07:27) And the very first thing they decided to do was to get safe training. That was their first exposure for the entire organization was trying to understand all the safe, huge diagram and stuff. So it seems like lot of that's not an uncommon thing that a lot of organizations tend to try to jump to that scaling kind of practices a little bit too early. What do you think tends to go wrong when they do that?

Mike (07:55) Well, if you don't know how to do it well with one team, why are you trying to do it with 20, 30, 50 or a hundred teams? Right. And so one of the things I've always talked about is get a one or a few teams to excellence, right? Get a couple of great teams. ⁓ you know, come on by this point, we know agile can be successful in organizations, but when you and I work with a company, we don't know what successful agile looks like in their company. Right.

We don't know if they're better off with user stories or job stories or something else. We don't know how detailed the acceptance criteria should be. Should they be written in Gherkin format? We don't know what sprint length is better. And you and I might have our personal preferences for how long a sprint should be. And maybe we recommend they start with that, but we don't know that that's the right answer. so organizations have to get a few teams to excellence to start to see what good agile looks like there.

And when you get it right with one team or a few teams, it doesn't have to be one, but when you get it right with one or a few teams, it's much easier than to extrapolate that. And so you're not at that point, just scaling the same problem to other teams. You've solved a problem and you're spreading it, spreading the solution.

Brian Milner (09:12) Yeah, it's like you're amplifying that, right? mean, if you have something bad and you scale it up, then you're teaching everyone else to do it the incorrect way, right? ⁓ I know we've used this phrase a lot about how you ⁓ sometimes need to slow down to speed up. And this seems like one of those instances where people wanna just jump ahead and go fast and get to the scaling portion of it. ⁓

Mike (09:21) Yep. Yep.

Brian Milner (09:40) Have you seen cases like that where this people kind of jump ahead and they speed up into doing this and they actually would be better off slowing down and understanding kind of more fundamentals?

Mike (09:52) absolutely. ⁓ know, you think about that and it fits with your comment about, the organization that just, you know, day one, let's start with everything and safe, right? You know, let's go for it from a management perspective. makes sense. Like, okay, we're committed to this, to this. Let's, let's show our commitment by going all in, right? We'll just, you know, do everybody all at once and we'll go with this, this bigger process. ⁓ but it doesn't work. And one of the early organizations I worked with, they,

started small. did start small. had one or two teams. Maybe it was three teams. They started with three teams. And after those three teams did it for maybe two months, they did a little survey of how much they liked it. And people loved the new way of working. It was very empowering in this kind of stodgy bureaucratic organization. It was a big shift and they absolutely loved it. And the general manager of this division, about, I don't know, about 50,000 people, she

loved those results and logically she decided let's spread this to everybody. Right. And so they spread it to a couple hundred teams right off. And, they called me about a month later because it wasn't working. Right. and even though they had a couple of teams that they had gotten started, those teams weren't really excellent yet. They were just kind of, you know, we'd look at them today and go kind of mediocre, but you know, they were, they were starting new stage teams.

But they had gone too quickly at this and really hadn't figured things out. So one of the things we did there was, ⁓ try to slow, slow it down a little bit. We couldn't really stop those other teams from doing agile once they'd already started. Cause they, could see the promise of it, but we had to bring in additional coaches, ⁓ to help them quite a bit. had, they had a fair amount of coaching for the next year or so, through us and another company that we were working with because they were a little too ambitious and how quickly they started.

Brian Milner (11:47) Yeah, yeah, I agree. ⁓ I know you've already kind of mentioned this third one ⁓ that is a really important aspect of ⁓ this topic. And that is really about product ownership and really how that relates to decision making within the organization. ⁓ I know we talk quite a bit about how important that is in our classes, but ⁓ what do you think happens when that

accountability ⁓ on the product side specifically isn't clear.

Mike (12:23) think product owner is probably the hardest job in agile because as the team gets better, you know, we're talking about teams improving, right? As the team gets better, the scrum master job gets a little bit easier, right? You know, scrum master's like, you know, I can totally, I mean, I can imagine, I can remember doing this, but kind of sitting back as a scrum master going, man, I got my team going. Well, this is great. Life's good. Right. ⁓ you know, let me go read some sporting news, right? I mean, I got my team kicking butt.

⁓ the product owner, when the team starts to really Excel gets busier, right? because the team's going faster, they need more backlog items. They have more questions because they have more backlogs. They're going faster. And so POs are a really difficult job and it, they're pushed to make decisions. And when product owners don't have the authority to make decisions, they either get overruled, they make a decision, get overruled, and then they get kind of conservative.

So they start running decisions by a lot of people, maybe a committee forms to make a decision, right? ⁓ You know, I've seen plenty of organizations where we'll have to have a committee prioritize the product backlog. ⁓ And I'm not opposed to the product owner going and getting some feedback, right? But that's, for example, you know, suppose I'm the product owner, go, Hey Brian, what do you think? How important is this to you? And you're like, well, pretty darn important, but I don't really need it this month. I could wait a month or two. So, you know, if you promise to get it to me in a couple months, I'd

don't need it right now. I'm like, cool. can go factor that in as the PO and make a decision on that. And it's really tough when product owners are not given the authority they should have.

Brian Milner (14:03) Yeah, yeah, I agree. Because it kind of just undercuts the position so strongly that it just kind of ⁓ nullifies it a little bit. It kind of ⁓ makes it completely ineffective. ⁓ I know that ⁓ when you're talking about this decision making authority for a product owner, a lot of times you think from the perspective of the leader. ⁓

And I have talked to leaders in the past who are kind of hesitant about it because they're a little afraid to empower that person. They kind of think, you know, I'm afraid to give them the power to make these decisions because what if they make the wrong decision? What do you say to leaders who are afraid that their product owner might make the wrong decision?

Mike (14:51) I mean, that's understandable, right? I mean, we're always worried about somebody making a wrong decision. But I think what you want to do in that situation is put a boundary around the decision, right? Say you can make decisions in this area, this part of the system, totally own that. This part of the system, bring it to me. You know, let's talk about this one, because this one's kind of my baby. Maybe I'm the former product owner of that area, right? And I'm the leader and I want to be involved in that part.

run those ones by me or, know, anything that's going to take more than two months to develop. Let's talk about that. Cause I would, you I'd like to toss in my opinion. Right. And I may, as the leader may say, Hey, product owner is still going to be up to you, but I want to give an opinion on anything that's going to cost that much time. Right. ⁓ so put boundaries around that. So the product owner knows what they can make decisions about and what they can.

Brian Milner (15:44) Yeah, I think the sprint time box also really helps with that because they're making, you know, they're not making six month decisions, right? They're not making a decision that you can't alter for the next six months. They're making a decision sprint by sprint. And, you know, we can iterate through any decision that they make.

Mike (16:03) Yeah, absolutely. That's a really good point. How far astray can we go in a week or two, right? You know, most teams are doing two weeks sprints. How far astray can you go in two weeks? It may not be, I the absolute worst there would be that the product owner has the team work on something that the leader didn't want them to, right? Well, okay, we lost part of a team's time for a couple of weeks, but, that's bad. We, you know, we've wasted some money. On the other hand, if we feel like every decision has to run by that leader,

We're slowing the team down on everything they do, including when most of the time it's like, yeah, go for it. Right.

Brian Milner (16:37) Yeah.

Yeah. You want to give them that autonomy because otherwise they do have to check in with you for everything. You create that dependence and then, you know, those leaders, obviously they're thinking of higher level things. They're needed in other areas. And if they're having to, you make these day by day decisions, then they're not doing those other things.

Mike (17:02) Yeah, they're not available and they're not going to be able to respond as quickly. Most delivery problems are really decision problems. And we see the wrong decision being made by the wrong people at the wrong time.

Brian Milner (17:15) That's a great point. That's a really great point. ⁓ Well, that leads me to the next one because I think this is a big one as well. And I know this is this is a constant struggle, but that's the struggle with speed versus focus. ⁓ I know that there's always the pressure to do things faster. And that seems to be the overwhelming sort of ⁓ top line pressure that I know a lot of leaders face. ⁓

And I know that they want their teams to move faster, but ⁓ from what you see, is speed really the issue that teams are facing in today's world?

Mike (17:52) think this is the... No, I don't think speed is the primary issue. I think a big part of this is the Stephen Covey, Seven Habits of Effective People comment about sharpening the saw, right? A quote from Abraham Lincoln. I don't remember the quote, but it was like, know, if I had a certain amount of time to chop down a tree, I'd spend most of the time sharpening my saw. And, you know, if you got a certain amount of time to do something, make sure you're spending a fair amount of that time figuring out what the right thing to do is, right?

You know, there's no point about going fast and building the wrong thing or go fast and build the right thing and the wrong way. Right. And so most organizations don't really have a speed speed problem. have a focus problem. And what we want to do is to have a team focus on fewer things. Get those things done. ⁓ Brian, know that some podcasts was mostly audio, but I'm going to do something visual and I know you're a movie guy, so probably.

probably catch my reference, but I was in a meeting with some folks yesterday and we were talking about exactly this and the need to focus. And I held up one finger and said one thing. Remember my reference.

Brian Milner (19:02) Curly.

Mike (19:05) Curly, Curly

and city slickers, right? Great movie. And I have shown that movie. I've shown that little like three minute clip of, of, of Curly and city slickers with Billy Crystal, taught them to figure out the one thing, right? What's the one thing. And if organizations can focus on the one thing, right? The one thing that's most important right now, they get the speed because the distractions go away.

Brian Milner (19:29) Yeah, this is such a vital point, I think, because I see this in multiple areas. I see this in the product area because we have so many possible things we could do. And it's a prioritization kind of thing of what do we focus on first. But I also see it in the improvement side as well. We have all these problems, which is the one we should focus on first. And I think the trap here is to kind of get lost in the

the abyss of all of the things you could possibly do without ever actually doing any of them. ⁓ So yeah, I completely agree. I think it's focus that's really the important thing is trying to determine what's most important and then focus on it.

Mike (20:04) Yep. Yep.

Absolutely. Nothing slows delivery more than trying to do everything at once. Right. We try to do everything. It slows us down. I realized, a while back, why leaders tend to do this. And it had to do with why I do it. Right. Because I'll ask a team to do something and then I'll come back shortly later and ask them to do something new. And I realized why I was doing that. And here it is. It's because I trusted my team.

Right. I give a team project a to go do and literally because there's so much in my head, I now purge my, my mind of things to do with, with project a right. It's as good as done. I've asked my team to do it and they said they'll do it. Right. It's as good as done. I don't need to think about project a anymore. So now think about what's happening. I'm not a neuroscientist. I don't take anything you're scientific, right? But my brain has now clicked off project a project. He's got a checkmark deck, so it is done.

And so my brain goes to start and think about, project B or C, what should we do next? And so my brain starts to want to have the team do B or C. And so I go ask them, Hey, can we do B or C? And they're like, dude, you told us to do a yesterday and it's a three week thing. Right. But, but it was a good thing. was because I trusted my team. I'm not rationalizing my behavior. I may really do believe this, but because I trusted my team, I mentally checked that off. And now my brain was onto the next big thing.

And what I had to rein myself in is remember I told them about a right. but I think that's why leaders do it in, many cases, they do trust their team. They've clicked off a in their head and they're ready to move on to the next thing. Mentally we got to stop as leaders got to stop and not give that to the team yet. But I did understand why it was happening.

Brian Milner (21:58) Yeah, yeah, that's a great point. ⁓ By the way, if you're listening along to this and you're thinking, gotta remember this to write down a note or something, we do have a PDF for this episode that we put together that's called the six leadership decisions that most often derail agile. And ⁓ that's gonna be a really handy guide for you if you're listening to this or you wanna go back through it later, maybe you point out some of these things to your boss or somebody else, ⁓ there's a handy little.

follow on guide for you if you wanna download that, that you can find in our show notes. ⁓ Which speaking of telling the boss, the next one is about leadership's role in Agile. ⁓ And I agree with you on this. I think this is one of those big areas that gets missed. ⁓ What do you see as the biggest thing that leaders most often misunderstand when we're talking about a leader's role in Agile?

Mike (22:52) that they think it's a checkbook issue, right? I write a check and we're agile, right? I don't have to do anything. just, you know, pay whether I'm paying a consultant or whatever, or, you know, pay by giving the team permission to go do this, right? That it's more than that. have to change their behavior. so leaders are making a mistake if they think that agile is something that only their teams do, right? Teams can't do things like fix the incentives.

inside an organization. Teams cannot fix ⁓ how projects are funded or budgeted, right? Teams cannot fix structure, right? They can't necessarily change who's on their team or how their team interacts with others or how ⁓ designers are spread across too many projects, right? Teams can't change those things. Only leaders can. And if leaders don't change how they work, agility stalls, right? We don't get the benefits we're after.

Brian Milner (23:46) Mm.

Yeah, I think it's one of those situations sometimes where they ⁓ might think they're helping, but they're actually hurting. And ⁓ I'm curious from your perspective, do you see things like that? Do you see things that leaders ⁓ in agile organizations think, I'm doing this and that's helpful to the team, but it actually ends up hurting the team?

Mike (24:12) probably in terms of some of the, some of the things like, you know, even like we can change our minds too often and things like that, right? You know, all my teams agile means I can change my mind. Right. ⁓ no, you know, there's still a cost to changing. You know, can't have a team start on a, and then two days later go say, want B now. I mean, there's a cost to that. So I think leaders kind of misinterpret some of what agile's about, you know, agile sounds so good, right? Where agile we're flexible. can do all these things. And, you know, it's.

still want to have some kind of guardrails of sanity around it.

Brian Milner (24:46) Yeah, absolutely. ⁓ Well, that leads us to the last one then, which is really talking about people's expectations and their expectations for what Agile is and does and what it will look like. I guess, why do you think ⁓ Agile sometimes feels like it maybe isn't working for organizations?

Mike (25:11) This is an interesting one, Brian. I was thinking about this when you were doing our introduction to this episode, talk about what we were going to talk about. And what I was thinking as you were describing that was all of the just the barrage of articles of Agile is dead, right? ⁓ And thinking about that, and I think in part of that, it's because people have these expectations that Agile is this silver bullet, right? And so,

Brian Milner (25:26) Hmm.

Mike (25:37) No, maybe it's not that agile's dead. Maybe it's that silver bullets are dead. mean, something Fred Brooks told us probably 40 years ago and that agile's not a silver bullet. It's not going to fix everything. And I think we end up with these feelings that agile failed or agile should be dead because it doesn't live up to impossible expectations. It doesn't live up to the expectation that a team can change on a dime that leaders don't need to do anything.

And when we have these expectations that are impossibly high, of course, Agile is going to fail when measured against those, right? So Agile is a feedback system, right? It's not a magic solution and organizations need to act on the feedback they get in order to get the benefits. And when they don't do that, that's when it fails.

Brian Milner (26:27) Yeah, I've heard the phrase before that it's not a silver bullet, it's more like a silver mirror. It honestly gives you an honest reflection. ⁓ And I think that's a good analogy. like, I ⁓ try not to make this too personal, but you you get up in the morning and you look at yourself in the mirror and think, is that bedhead okay? should I leave the house with that big, you friendly... ⁓

Mike (26:36) That's good.

Brian Milner (26:54) alfalfa things sticking up in the back of my head or should I? This is why I thought, I'm in trouble here with this analogy. Yeah, exactly. But yeah, I think it's correct in that it is a process to help you see the reality.

Mike (26:57) I can't relate to, I can't relate to bedhead problems. So you lost me there.

What's bedhead if?

Brian Milner (27:20) And then what you do with that reality is really up to you. And if you decide, hey, we're going to just live with that bedhead, right? If we're going to live with it, that flaw in our organization or something that we're doing wrong, well, that's not going to get fixed then. It's not going to change. It's not going to improve. Nothing's going to be better. But at least you've addressed it. At least you've been forced to confront it and say, yeah, no, I'm making a deliberate decision to stick with this.

Mike (27:47) Well, that's the, the old, ⁓ famous Ken Schwaber quote of Agile's like your mother a lot points out all your faults, right? So, you know, anything you're doing wrong, Agile is going to help you notice that because we're because of the short cycles, the feedback loops, we're going to, we're going we're going to discover problems.

Brian Milner (27:54) You

Yeah. Well, this has been great. Now, I just want to, as we kind of wind this down, if you were going to kind of sum this all up, why do you think Agile initiatives fail so often?

Mike (28:20) think agility doesn't fail because teams won't change. It fails because leaders don't change. Leaders need to change how they interact with their team. And that's kind what we've been trying to go over here is to encourage leaders to make some of these changes because agility can be a wonderful thing, not a silver bullet, but it can be a wonderful thing. But it's not something that you just dictate, right? Leaders need to change their behavior to get the benefits.

Brian Milner (28:48) What would you want leaders to take away from this or what's one thing that you think a leader could do to make a positive impact on this topic?

Mike (28:57) Probably one of the best would be to talk to their teams about, what do you need from me? Right. ⁓ you know, we talk about in, ⁓ I know you and I both trained in retrospectives to think about things to start, stop, continue, right. What should a team start stopping in you as a leader? ⁓ go to a team or two and say, Hey, ⁓ of my behaviors, be honest with me. What should I start doing? Stop doing, or continue doing, you know, help me, help me help you better.

Brian Milner (29:22) Yeah, yeah, I think that that takes, that takes bravery, that takes courage for leaders to be able to do that. And ⁓ it's scary, I know, but it also kind of demonstrates to them the expectation of here's how you do it.

Mike (29:28) Yeah.

It also takes courage from the team to answer that, right? And if the leader gets a, you know, a lip service answer, oh, you shouldn't change anything leader, you're great. Well, you better go change cause there's a real big problem if that's the answer you got. So.

Brian Milner (29:59) Yeah,

yeah, absolutely agree. ⁓ Well, this has been wonderful. And if you're listening to this and want to read more about it, find out more about it, please do check out our show notes for this. We have a link there to a PDF that's put together just for this episode for you that I think could be really helpful. So Mike, thanks so much for coming on and talking through this with us.

Mike (30:19) Thanks, Brian.