Powered by RND
PodcastsTechnologyAgile Mentors Podcast
Listen to Agile Mentors Podcast in the App
Listen to Agile Mentors Podcast in the App
(524)(250,057)
Save favourites
Alarm
Sleep timer

Agile Mentors Podcast

Podcast Agile Mentors Podcast
Brian Milner and Guests
The Agile Mentors podcast is for agilists of all levels. Whether you’re new to agile and Scrum or have years of experience, listen in to find answers to your qu...

Available Episodes

5 of 135
  • #134: How Leaders Can Reduce Burnout and Boost Performance with Marcus Lagré
    Is workplace stress just about long hours? Not quite. Brian and Marcus Lagré unpack the real equation behind stress—how pressure, complexity, and security interact—and why your team’s performance depends on getting the balance right. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with Marcus Lagré, product organization coach and author of The Stress Equation, to break down the science of workplace stress. They explore the differences between mental and emotional stress, how pressure and complexity impact teams, and why security in the workplace is a game-changer for performance. Marcus shares research-backed insights on interruptions, stress contagion, and how leaders can create an environment where teams thrive without burning out. References and resources mentioned in the show: Marcus Lagré The Stress Equation by Marcus Lagré Certified ScrumMaster® Training and Scrum Certification Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. Marcus Lagré is an author, speaker, and consultant with 20 years of experience in software development, from small-team Scrum to massive 50+ team LeSS transformations. Creator of The Stress Equation, he helps organizations tackle workplace stress systematically, ensuring teams thrive under pressure without burning out. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm here as I usually am, Brian Milner. And today we have with us a really special guest, Marcus LeGray is with us. Welcome in, Marcus. Marcus Lagre (00:13) Thanks, Brian, pleasure to be here. Brian Milner (00:15) We were saying before that I'm actually kind of butchering or Americanizing his last name. Marcus Lagre (00:20) Nah, Americanizing, yes, but butchering, no. I wouldn't say that. Brian Milner (00:24) So I'm gonna give you a chance to set the record straight. Why don't you tell us the actually the correct pronunciation? Because I probably can't do it. Marcus Lagre (00:31) Well, my... I would say La Gré, but that's with a Swedish southern accent and not even most Swedes do that, so... Brian Milner (00:34) Okay. OK. Do the Swedish people look on people in the South like we do here in America? Like they're kind of more laid back and slower and... That's funny. OK. Well, we have Marcus on because, first of all, Marcus is a product organization coach. He's an author. He's a speaker. Marcus Lagre (00:48) Yeah, yeah, I would I would say so I would I would say so yeah Brian Milner (01:03) And he has a really great book that we wanted to kind of dive into the topic of here. Because in this day and age, this is a really important topic, but his book is called The Stress Equation. So you can kind of see where we might be going there with that. Well, so let's dive in. Let's talk about that a little bit. And I think probably a good place to start would be, how would you define then stress, when you, if we're talking about stress and the stress equation, how do you define stress? Marcus Lagre (01:30) I usually use the definition of stress because I let's start like this. I think that most people have like a too narrow perspective of what stress is. Like most people probably see it as working long hours and you know, spending a lot of time at work, but it doesn't necessarily have to. And there's this definition of stress from the Oxford English Dictionary that I found really well that stress is the result of, of, of, emotional or mental strain due to adverse or demanding circumstances. So yeah, so there's differences there. And I think that most people, if you're not in a very toxic environment, you don't suffer from emotional stress a lot at work, but mental strain is probably what we're looking at most often. Brian Milner (02:04) Yeah. Okay. Yeah, I mean, I, you know, I wouldn't discount that entirely. I think that there's probably a lot of people out there that have the emotional strain of a bad boss or manager or something like that, right? But yeah, hopefully, you know, hopefully you're right that the majority might not be, you know, dealing with that. It might be more of the mental side of this. So what is mental stress then? What is a mental strain? Marcus Lagre (02:38) Well, mental strain is usually diversified by saying like emotional strain is like the stress from being like in a toxic environment, for example, which is more common than it should be. But mental strain is more of the when you have too much of a mental load, like you're trying to solve a complex problem, like you have high cognitive load in order to solve it, or you need to Brian Milner (02:48) Hmm. Marcus Lagre (03:03) Well, it's also related to cognitive load that you have a lot of context switching. So you need to change information in your working memory quite often and a lot. And that can lead to mental strain. And the problem with mental strain, as I see it in white collar worker or knowledge workers, is that most of us are, we like mental challenges. We like puzzles, we like solving problems. So we're not great at identifying when a mental challenge becomes a mental strain for us. We're used to just pushing on. we try to just, you know, it's just something that I haven't figured out yet. If I push myself just a little harder, I'll crack it. Yeah. Brian Milner (03:42) Yeah. Yeah, that's great. Yeah, I mean, I think you're right. We do like puzzles. We do like challenges. I I know one of the popular things here in the US is the escape room kind of thing. I don't know if you guys have that there as well, but we actually pay people in our free time to give us puzzles and challenges that for fun, we'll go and put ourselves under some mental duress and try to figure out. So I think you're right. there is part of us that really wants to do that. Well, if that's true, then the other side of that is, shouldn't we all be under some kind of mental stress then, since work is challenging and complex and hopefully. Marcus Lagre (04:20) Well, yeah, I mean, not all stress is bad. So I usually say that the stress that we feel at work usually comes from two different sources. So this is the equation. Like the mental strain comes from the complexity that we need to, now that we need to handle. Either the complexity of the problem that we need to solve, or if we're working in, the complexity could also be like the frustration of working in an inefficient organization. That could be part of the complexity. Brian Milner (04:23) Yeah. Marcus Lagre (04:46) So I usually say that pressure is our sense of urgency. The pressure comes from our sense of urgency in order to finish the work that we're, the task that we have at hand or whatever it is that we're trying to solve. And the complexity is whatever makes it harder for us to actually finish that work. So to relate back to what you were saying, shouldn't we be under some kind of stress? Yes, we should. If we don't have any sense of urgency, we're probably not delivering at all. And if there's zero complexity in what we're doing, That should probably be an automated task long ago. We will probably suffer from severe boredom if there's zero complexity in what we're doing. Brian Milner (05:25) Yeah, I always, you know, this comes up sometimes in classes where, I think, you know, I want to find those people who are under zero pressure at work, because I've never been in that situation. I've never had any kind of boss or organization that was like, just take as long as you need. It doesn't matter. There's always some pressure and some places it's more than others and some places it's extreme. But yeah, I think you're right. There's a right amount of pressure. that can be applied. Marcus Lagre (05:48) And there's also constructive stress. I usually diversify like constructive stress is when you try to achieve something because if you're under a lot of pressure solving something very complex, there's also pleasure in actually solving it. So there's some kind of release in the end. But if you're constantly under a lot of pressure or... Brian Milner (05:51) Hmm. Marcus Lagre (06:09) I usually say that the pressure usually comes from things like how we set deadlines, how we handle our backlog. So if you have two short deadlines, then you're under negative stress or unconstructive stress, or we have an ever-expanding backlog. We can never finish everything in this backlog. have no way of saying no to things. They just keep piling on. That's unconstructive stress, but... Brian Milner (06:30) Yeah. Marcus Lagre (06:34) A sense of urgency to reach like a goal? That's more of positive kind of stress. Brian Milner (06:39) Yeah. Yeah. I I've heard, my boss, Mike Cohn talk about before how scrum has just the right amount of pressure that it's, it's not, you know, it's, it's not the kind of, when we think about commitment and stuff inside of a sprint, it's not the kind of thing of, you're going to lose your job if you don't make this sprint commitment. But it is kind of, you know, my, my word is on the line. My name is on the line. And if I don't deliver. I'm letting down my team, I'm letting down those around me. So that's way he describes it. It's kind of just the right amount of pressure that's kind of baked into the way Scrum works. I've always liked that. I've always thought that's kind of a good take on that. So we're kind of in these pressure cookers a little bit, right? We've got pressure and sometimes more than others and we do need some kind of pressure. So we have some sense of urgency in what we're doing. How does this align with our Agile Manifesto kind of ideal of working at a sustainable pace? Is the pressure going to crack us under trying to keep a sustainable pace? And what if we don't have any say over the amount of pressure we have? Marcus Lagre (07:46) Well, if you don't have any say, then I usually say that the pressure isn't a force of nature, that it usually stems from someone's decisions. And if we don't have a say in it, then we can't influence that pressure really as a team maybe. But from a leadership perspective, if you put unlimited pressure on the team, you're gonna see decreasing results anyway. It's not... constructive, you're going to burn your people, you're going to lose, worst case, lose them from the company, either because they change jobs or because they burn out and they have to go on sick leave. So and that's going to cost you in the end. But also that you're going to see either a lot more well, as I said, either a lot of people leaving or people doing quite quitting. That's that's what's going to be because once caring about your own performance becomes dangerous, people are gonna put in the bare minimum. That's the people you're gonna keep. Brian Milner (08:41) Yeah. Yeah. I'm sure there's lots of research baked into this and you've probably crossed a lot of different studies and things that have kind of jumped out at you. And to me, that's always one of the things that's the most interesting when I dive into a topic like this and go really, you know, kind of knee deep into it. what, was there any kind of research that you stumbled upon as you were preparing for this or, you know, creating this book? that really kind of surprised you or that you found extremely interesting? Any studies out there around the effects of stress that kind of shocked you even maybe? Marcus Lagre (09:18) I wouldn't say shocked, but one thing that surprised me was that there was this study that showed, because I talk in the book about complexity, and I mentioned earlier that if you need to change the information in your working memory a lot, that leads to mental strain. But there were actually studies that showed that interruptions in work does not lower the quality of the work. It does, however, increase the sense of stress. But it doesn't necessarily lower the quality of work, which was something that I was absolutely convinced it would. However, there was a correlation between how far if you got interrupted, if it was on topic, so to speak, so that you didn't have to throw everything out of your working memory, then the quality level was still on par with what you would have seen if you weren't interrupted. However, Brian Milner (09:48) Yeah. Marcus Lagre (10:06) if it was something that was diametrically different to what you were actually doing, then yes, the quality would also drop. But I actually thought there would be like a clear correlation between interruptions and lower quality of work. And it wasn't. Brian Milner (10:20) Yeah. So it's not, I mean, what I'm hearing is it's not necessarily the interruption itself. It's the content of the interruption. And if the interruption is, you know, taking you wildly off track from your thought process, that's higher stress kind of a reaction to it. And that leads to more problems. But if it's, if it's an interruption that's near in the same area of what it is you're working on and thinking about, then it's not as hard to get back to it. Less stress, less, let's kind of end result effect, right? Marcus Lagre (10:52) Yeah, there's less mental strain in that scenario. However, you do often feel like you're less efficient, that you get less joy out of what you're doing if you get constantly interrupted, and that the workload is heavier than it actually is. So there's negative sides to getting interrupted a lot, but as long as it's sort of on topic, as you say, it's not really that harmful. Brian Milner (10:54) Okay. Yeah. Well, I know you do a lot of work with organizations and with leaders and organizations. And I know one of the difficult things, difficult kind of parts of having these conversations with leadership is trying to help them to understand the importance and kind of the impact and why this is important in a business sense to them. Not just that, you know, the way I phrase it in classes, it's not just that it makes you a better person, right? which there's value in that. not negating that being a good person is bad. I'm just saying from a business sense, oftentimes leaders want more than just saying, yeah, I'm a better human by doing that, but is it better for the business? So how do you have that conversation with leaders, with organizations to say, this is actually an important thing to focus on. This makes an impact on your business. Marcus Lagre (12:07) usually the challenge is to get leaders to understand that they are also affected by this. Because a lot of the challenges I see in organizations is that I come in and I usually do like an analysis of the organizations, ask around, do interviews and analyze everything. And what I come up with is rarely news to the leadership. They have seen the same thing. The problem is that they never had the time to just sit down and figure things out because they're constantly rushing between meetings. They're constantly rushing to do various budgets, updates, stuff like this, just keeping the mill going. So I usually say that they're too operationally occupied to take a look at the strategic goals and the strategic direction that they need to be going in for the business to run smoothly over a period of time. And so I usually tell them that the most important thing that you can get yourself is like an hour, at least every week that you just sit on your rear end and just contemplate things. I usually use a different word than rear end when I tell them this, just to drive the point home. But yeah, they need to find time. where they can just like no phone, no computer, just sit down for an hour and let whatever enters your head, enter your head because otherwise you will never figure this out. And you don't have to pay people like me premium to come in and tell you things that you are actually clever enough to figure out yourself. Brian Milner (13:41) Right, right. Yeah, so that's so interesting. So it's hard to convince them that stress plays a big impact on their work. I hadn't really thought of it from that perspective, but that's a great point to make. If you can help them understand the impact it has on their work, maybe it's an easier conversation than to say the impact it has on your teams or on your employees' work. Yeah. Marcus Lagre (14:06) I have never, mean, stress is contagious and it ripples down. If you have a really stressed out management, you're gonna have stress in the rest of the organization as well, like on the floor and in your teams. That's just a given, I would say. Brian Milner (14:11) Yeah. Yeah. All right. Well, so I'm following along. I think this is good. So we're talking about how you kind of explain this a little bit more to leaders and help them understand the impact. What about when you get one of those leaders who's just, and I know I've had these before where they're kind of more old school and they look at things and think, you know, you... Well, on your graph of pressure, right? They're much more leaning towards the higher pressure side to place on employees because they take that attitude of, you know, the old phrase that we all hate, work expands to fill the time allowed or whatever that thing is, right? How do you convince that person that, you know, there's an okay amount, but you're kind of really skewing it to the high end and this is now going to have an adverse effect? Marcus Lagre (15:00) yeah, yeah, Brian Milner (15:12) on what you're ultimately trying to do. Marcus Lagre (15:14) My usual angle of attack is to address the complexity of the part of the equation. I probably can't get them to understand or accept that they're applying too much pressure, but what they're actually trying to achieve is to get more output. I mean, that's the goal of their actions. And so I try to get them to understand the complexity that their teams are working under and try to get them to understand that you need to reduce this in order to free up more time and mental bandwidth for output. And that's usually a better way forward than trying to get them to accept that you only get so far with a whip. Once you've whipped one time too many, people are going to just stop caring. Brian Milner (16:02) Yeah. Yeah, you can't come back and use that tool over and over again. It's going to have kind of the opposite effect that you're hoping it will have eventually, right? Marcus Lagre (16:14) People are going to start telling you about problems, for example, because these people are usually the same people who don't want to hear about problems. Don't tell me about problems, tell me your solutions kind of attitude. And I usually get them to understand that you have absolutely no idea what the problems of this organization is, because people are afraid to tell you. Brian Milner (16:22) Yeah. Right. Yeah, that's such a huge point, I think, for leaders to kind of soak in and understand. If you have that culture, if you are generating that culture of fear in the organization of, don't come to me with problems, only come to me with solutions, then you're right. You're absolutely right. You're closing yourself off. And you're kind of establishing the norm that if there is an issue, The last thing to do is to raise it, to let people know about it, live with it, right? Just kind of exist with a status quo. If there's a problem, then you just have to learn to live with the problem. Marcus Lagre (17:09) Live with the problem or game the system so the problem isn't apparent. Brian Milner (17:13) Right, right. So back to the equation then. So your equation here, pressure times complexity over security. I don't know what we've talked much about security so far. So how does that come into play when you calculate this kind of pressure equation, stress equation? Marcus Lagre (17:25) Bye! Yeah, well, we kind of touched on it now, like with leaders who act in a way that lowers the security or the sense of security. So I define security as the freedom from fear at work. And psychological safety is one part of that. But it's also that you feel that you have... I'm sort of reluctant to use the words servant leadership anymore because there's sort of... sort of become a tainted word in some ways. People see it as a passive leadership style, which is not really, I don't quite agree with that, but security is in essence that you are able to take high pressure and high complexity if you feel that you have the management in your back, that you're taking it on as a team, that you're not alone with all of that pressure and all of that complexity, but you have people around you who you can rely on and ask for help. If you have that, then your security is higher and then you can take more pressure, you can take more complexity without burning out. Brian Milner (18:32) Yeah, yeah, that makes complete sense because if I have the kind of that sense of security that I'm not at risk, I don't feel like I'm being put in a position to fail so that I'm now in danger, but I've been given difficult problems because I have been trusted to conquer them. I've been trusted and empowered to kind of overcome them. That's such a different approach and mindset from an employee standpoint than, my gosh, I got to do this or I'm going to get fired. Marcus Lagre (19:05) Exactly, there's probably, management has probably let me know that we understand, we're handing you like a really tough thing to solve. if you need anything, if you need any resources, if you need any extra help, just ask us for it and we'll solve it. And in that situation, you're a lot more likely to... be able to get into that without burning out simply because you know that I have the management backing me up. Brian Milner (19:37) if I'm one of those employees who's under a high pressure environment, and I don't really feel like I have the power or authority to make that change, what can I do about it? Marcus Lagre (19:50) I mean, the thing that you can do is to change what I usually, one of the reasons why I wrote this book is that stress is one of the leading causes of mental illness and sick leave in our line of work, which is software. So if something is the leading cause of a problem, it's probably systemic, it's not individual. So one of the most important thing, that you can do is to identify what in the system is causing the stress in me, because ultimately stress is a subjective feeling. it manifests itself in people, but you can get the tools to identify what in the system is causing the stress in me. that can be quite a relief to not put that... I mean, put additional pressure on yourself by thinking that you're the one who's bad at your job or you're the one who don't have the correct coping mechanisms for the situation. The situation might actually be insane. Brian Milner (20:51) Yeah. Yeah, it's that subjective nature, I think, that is kind of a variable that I would throw into this equation. It's sort of like, I know one of the things I found really fascinating in kind of the earlier history of Agile and the idea of a sustainable pace was originally there was kind of talk about saying, using words like, no one should work more than 40 hours a week. But then that got changed to sustainable pace because of the realization that for some people 40 hours was too much and for other people 40 hours was not enough. And so that idea of sustainable pace was, it's individual, it's different to different people and that's part of what we got to do is know ourselves enough to know, hey, I'm kind of slipping beyond that point where I can sustain this indefinitely. Marcus Lagre (21:37) Yeah, and I think that's one of the myths that I want to bust a little bit is that, you know, it's not about 40 hours. It's not about the hours. I mean, there are some people who can work 60, 80 hours without burning out. So it's not the hours. It's something else. You know, so it's the end of the... Maybe it's the pressure that we have too much pressure. Maybe it's that we have too high complexity in combination with pressure. Maybe it's that we are in a toxic environment. So it's like how much mental energy do I need to handle the context that I'm in? That's. Brian Milner (22:13) It's almost like there needs to be kind of this balance between those three things that you've got to, one thing might go a little higher, but the others then have to drop a little bit so that it kind of equals out, right? Marcus Lagre (22:22) Yeah. That's what I, like, I always say that if you want to put high pressure on your teams, on your organization, you have to reduce the complexity because you can't do both at the same time. Those are the two variables that increases the stress. But then as we mentioned, like feeling of security is the lowering factor. So you always do well working with Brian Milner (22:38) Yeah. Marcus Lagre (22:46) the sense of security within your teams and working with your culture and making sure that toxic behavior is simply not acceptable in this organization, for example. And so that's always, you always get a reduced level of stress from that kind of work. But as I said, if you have high complexity and you put too high pressure on something, it's gonna break sooner or later. You're either gonna break your people or you're gonna break your product. because you're going to reduce the quality of the work because you have to stress through everything. And quite frankly, I don't care about your product. You're free to break it if you want to, but breaking people, that's just not okay. Brian Milner (23:18) Ha ha. Yeah, now we're back to being a good human, right? mean, these are humans. They're not AI programs, at least not yet. And they have lives. the more that you, like you're talking about, the more that you increase that pressure on them or decrease their sense of security, the less complexity they can handle. And you know, You have diminishing returns on your employees, on their productivity. Marcus Lagre (23:48) It is unsound business. Brian Milner (23:50) Yeah, yeah, absolutely. Well, this is fascinating. I really appreciate you coming on and talking about this. Again, for anyone listening, if this topic is interesting to you, highly recommend you check out the book, The Stress Equation by Marcus Le Gray, even though that's not actually the way to say the name. it's L-A-G-R-E, just so everyone knows. I don't want you to struggle searching for it if you're looking for it. We will put the links to it in the show notes for this episode so that you don't miss out if you're trying to contact Marcus or you want to know more about the book. We'll make sure you find a way to do it. So Marcus, I really appreciate you coming on. This has been a fascinating topic and I appreciate you sharing your wisdom, your research and your knowledge on this with us. Marcus Lagre (24:31) The pleasure was all mine, Brian.
    --------  
    27:35
  • #133: Trending Agile: Scrum Masters, AI, and the Future of Agile
    The Agile Alliance partners with PMI—what does it mean for Agile’s future? Plus, how AI is reshaping Scrum Master roles and why honesty (even when it stings) is the key to career growth. Brian Milner and Cort Sharp tackle these hot topics in a no-holds-barred discussion. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Cort Sharp dive into the recent Agile Alliance-PMI partnership and its potential impact on the Agile community. They also explore AI’s growing influence on Scrum Master roles—will it replace them or elevate their value? Finally, they tackle a tricky but crucial topic: when to speak up in the workplace, balancing honesty with career preservation. If you want to stay ahead in Agile’s evolving landscape, this is a must-listen! References and resources mentioned in the show: #32: Scrum in High School Sports with Cort Sharp #82: The Intersection of AI and Agile with Emilia Breton #129: 2025: The Year Agile Meets AI and Hyper-Personalization with Lance Dacy #132: Can Nice Guys Finish First? with Scott Dunn Mike Cohn’s Better User Stories Course Join the Agile Mentors Community 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years. Auto-generated Transcript: Brian Milner (00:00) Welcome in. Welcome back, everybody. This is the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, we're going to do something a little different. We're in this mode right now. We've kind of been open to some suggestions recently about maybe we should try some experiments and try some different things. And so today's going to be one of those little experiments. We have someone that's going to be with us, Mr. Cort Sharp. So welcome in, Cort. Cort (00:23) Hey Brian, thanks for having me on. Brian Milner (00:26) Absolutely. Cort is our community manager for the Agile Mentors community. And Cort and I do classes together a lot. He is often the producer in the classes. So we see each other a lot. We talk a lot. Cort's also a certified Scrum professional. So he's been doing this and has encountered Scrum in some kind of unusual circumstances as well. He's a high school swim coach. There's an episode that we talked about that. way back so that anyone wants to dig that out, they can go back and find that and learn a little bit more about it. But we just thought it would be good to have maybe periodically a little check in about maybe some stories that have come up in the news about Agile or things that have been flashing through social media feeds or anything like that. know, Cort and I are a little bit different age groups, a little bit, more than a little bit. And I'm sure the of things that cross court's radar may be a little bit different than the things that cross mine. And we just thought maybe it would be an interesting kind of thing to have a little discussion, the two of us, about some of these major burning issues and things that people are talking about on LinkedIn and Twitter and, I'm sorry, X, anywhere else. I'm going to kind of... Give the reins over to court here a little bit, because I know he's pulled some things that he wants to talk about, and we'll just kind of see where we go. Cort (01:40) Awesome, yeah, thanks Brian. Not just X and LinkedIn, we're also looking through Instagram, YouTube Shorts, where the cool kids hang out, I guess is. That's at least what my swimmers tell me. Brian Milner (01:50) Okay, okay I Got it I got a yeah, I you know, I had to learn a lot about an Instagram with my daughters and I still don't get it. just I mean I have fun flipping through stuff but I don't I could never like get a following there because I just don't understand how to Do all the but that's old guy talking. So Cort (02:11) It's a weird place, Brian. I don't blame you. It's totally good. But I've seen a few things come across my feed, and we've kind of had lighter versions of this conversation, whether it's in classes or just kind of on the side or something like that. So we just kind of thought, hey, let's sit down and actually go into depth about this, because I'm curious what your thoughts are on some of these things. And I don't know. Brian Milner (02:14) Yeah Cort (02:35) Hopefully I'm able to add into the conversation a little bit more than just here's a young guy yelling at a cloud instead of an old guy yelling at a cloud, right? No, I hope not. But let's come out and I'm gonna come out swinging at you. So the biggest news bite that I have found over the last couple of months or the last month-ish is that the Agile Alliance and PMI Brian Milner (02:37) Ha ha. young guy and old guy yelling at each other. That's not what anyone wants to hear. Yeah. Yeah. Cort (03:02) have entered, have announced that they're entering a partnership. We don't really know a ton about what that partnership looks like, but it is presumed that the Agile Alliance will be hosting some kind of content through PMI or PMI will be hosting some kind of content that the Agile Alliance has created. So I'm just curious, like, what are your thoughts on that? Do you think it's a good move, bad move, any kind of potential impacts that you see? It's a big one. Brian Milner (03:30) Yeah, way to start with a softball that we just, yeah, mean, it's obviously a hot button topic right now. I've heard lots, I've read lots of opinions of people on different kind of forums and discussion boards and things where people are talking about kind of, what does this mean? That kind of thing. And so here's kind of, Cort (03:34) Hahaha Brian Milner (03:57) Here's kind of what I've heard from both sides, right? The people who are kind of anti feel like this is maybe a little bit of a betrayal. And I think that the reasoning behind that kind of feels like maybe historically or somewhere maybe further into the past, the PMI may have been a little bit of an antagonist towards the Agile movement, or some people feel that way. I'm not saying this is my opinion, but this is what I've heard. Some people might feel that way. And so they feel like, would you attach your name to something like that? But I've also heard from people who are pro and have said, look, the basics of the deal are that it's not going to change anything for the Agile Alliance other than the name. It's officially the PMI Agile Alliance. But other than that, what I've heard from people who are board members that have posted Cort (04:43) Sure, yeah. Brian Milner (04:50) from the Agile Alliance have said, it's just nothing more than our name is now different. We're autonomous. We can still do the things we've always done. And we feel like the connection to this larger organization will enable us and help us. And I know the Agile Alliance has gone through some tough times, as a lot of us in the industry have, with the conferences. At least I know the conferences last year was kind of not what people have hoped, and not just the Agile Alliance conference, but other conferences have had down attendance and other things. Maybe just a sign of the times, I don't know. But personally, I kind of look at it and I got to preface this. got to, before we talk about anything else, right? Because now we're going to get into opinion. But I would just say, let me preface by saying the opinions you are about to hear. are not the official opinions of Mountain Goat Software. They are just the opinions of the individuals that you will be listening to. So this is just one guy's opinion, right? I think I would just say I get it from both sides. I understand. I see kind of the concern. From the people who are pro and they say, look, it's just the name, I don't know why anyone would freak out about that. It's just a, we're just putting letters PMI in front of our name. hear that, but I've also heard other people counter that to be like, yeah, but it would be like Greenpeace saying, you know, we're now Exxon Greenpeace, you know? And I don't think, I think that's quite, you know, a huge overstatement. I don't think that's the same thing at all. And I, you know, I recognize that the PMI has, you know, they've adapted. anyone who thinks that they're the same way that they've always been, I think is wrong. I think that they have incorporated over time more and more agile ideas into their certifications and other things. they certainly, I feel like they've recognized the agile sort of the future and they've tried to invest more heavily. I think this is a sign of that as well. They're trying to invest a little bit more into agile because they see it as, you this is the future of project management. You know. But they also see it as one of the paths. It's one way of doing project work. And it's not the only way. There are other ways that are good as well. I don't know that I disagree with that. Depends on the project. It depends on what it is you're trying to do. But we talk about this in class. If I know what it is that we're going to make, I know exactly how to make it, the customer knows what they want, and we're not changing anything along the way, then Cort (07:02) Yeah. Yeah. Brian Milner (07:16) Agile may not be the right way. But if any of those things are not true, then I think Agile is the right way. end of the world, no. I don't see it as the end of the world. I don't see it as the sky's falling. I think it is a sign of the times. I think it is sort of a benchmark kind of thing to say, wow, things have reached this point where they've joined forces. I think that's not an indication of either side bending a huge amount, but that both sides have bent and met in the middle. And that's kind of my opinion on it. The sky's not falling, but I don't really know how it will change things moving forward. They tell us it's not going to really. We'll see. Cort (07:58) I think I agree with a lot of what you're saying. And that's what I've seen as well amongst the social media spheres. Kind of a lot of discourse of, this is really bad, or, this is not as bad as you think it's going to be, or, this is actually really good. Because I think one point that I agree with a little bit more so is, in principle, at face value, This might not be what the Agile Alliance was founded on or anything that goes, or I wouldn't say anything, but it doesn't align with the foundational values of the Agile Alliance. But in the long run, I think this might be pretty beneficial for Agile as a whole, because PMI is massive. They have a huge reach, very big name recognition, and for them to acknowledge, not only acknowledge, but acknowledge in this way and bring in Agile into this space within their reach, I don't see a ton of harm that could really be brought to it purely on the basis of our reach, PMI's reach is significantly larger than the Agile alliances. So it just helps Agile grow a little bit more so and get a little further reach. Do you agree with that? you disagree? Thoughts on that? Brian Milner (09:14) Yeah, I mean, I've heard Mike say this before, where he says, you we talk about partnerships, you know, who's bringing more to the table? Is the Agile Alliance funneling more attention, eyeballs to the PMI by this Alliance, or is the Agile Alliance getting more eyeballs and more attention because of the audience of the PMI? I would think it's the Agile Alliance is getting more. Like you said, I think the PMI is a huge behemoth, pretty highly recognizable. their certifications have been out. They're kind of one of the first of those kinds of certifications that existed out there. And I just think that they're probably bringing more to the table to the Agile Alliance than the Agile Alliance is bringing to them. Cort (09:56) Yeah, yeah, the Agile Alliance is kind of getting the better end of the deal, so to speak, as far as exposure goes. Brian Milner (10:00) Yeah, but I think time will tell. I think that's really what I would say to anyone is just don't freak out too much yet. You need to just wait and see what will happen. When the moves happen, if something happens, it's like all of a sudden now the Agile Alliance can't in any way talk about how traditional waterfall is not a great way of doing things. Well, now I would raise the alarm and say, OK, well, now you see the compromise. But if that doesn't happen, if it truly is, as I've been hearing, it's just a naming, we're autonomous, I don't see the grave harm. Cort (10:33) Right, right. Right. I think one thing that's kind of overlooked or maybe just a little glazed over that people didn't pay too much attention to is they didn't announce this as a merger. They announced this as a partnership. So to me, when I hear partnership, hear two entities working independently with a common goal of whatever it may be. Brian Milner (10:54) Yep. Yep. Yeah, a little insider baseball on that because I have heard some discussions around that as well. And just what I've heard is, there is a trickiness there because the agile Alliance is a nonprofit organization. And so from a for-profit organization, you cannot acquire a nonprofit organization unless that nonprofit organization changes and becomes a for-profit entity. Cort (11:28) in for profit. Yeah. Brian Milner (11:31) I'm not a lawyer. I don't know any of that kind of insider, the legalese that's around that. But I've heard a little bit of conversation around the fact that it might have been an acquisition had they been a for-profit company. But since they were a nonprofit, it's a partnership. So that may be the case or not. I don't know. Cort (11:50) So that brings up just a question to me then. A lot of times when companies merge, they tend to merge as either an industry or a sector is kind of starting to go down, trickle down a little bit. And they merge as a method of of like bulking up, strengthening where they can, trying to... that they acquire, they merge in order to withstand the rough times. Do you think that that might be what's at play here? Where just from a business perspective, this is kind of the business smart move for both entities, both organizations, so that they can withstand, I think I saw somewhere like a 35 % reduction in middle management positions, postings or something like that, right? Brian Milner (12:31) Yeah. Yeah, absolutely. mean, I think, the, the past few years have been kind of difficult economically. please don't think I'm being political and saying that at all. I'm just, yeah, I can only state what I've, I've seen and heard from other people in the industry. And I've, you know, I've heard about people talking about less job postings, those going down. I've heard about, know, trainers and coaches and other things. you know, losing percentages of their students or their coaching engagements or other things. So I've just heard that it's been, and we've kind of experienced some of that as well, decline a little bit. I don't think it's that one of those two entities had a decline. I think they both are kind of recognizing this is a tough economic climate and strength in numbers. You know, if we can support each other and maybe that's the path forward is that we kind of combine forces and combine and conquer a little bit. So I think you're right. I think that may have forced it and it's just the opportunity presented itself. Cort (13:37) Just kind of a contextual thing where the context of kind of where we're at right now. That's really what drove it. Yeah, I can see that. could totally see that. Awesome. Well, let's jump over to our next kind of topic right now. Everyone's favorite topic right now, AI, right? We've talked about it substantially. But kind of with that whole idea of Brian Milner (13:52) Sure. Yeah. Yep. Yeah. Cort (14:03) or that little note that we had there of these mid-level management positions, we're not seeing them rise in open positions. We're kind of seeing them get squeezed down a little bit. We're seeing them reduced. And a lot of that is attributed to AI, where a lot of these mid-level management positions are tasks that can be done by AI, because a lot of it is kind of this data analysis stuff and what do we move forward with? Relating it to Scrum specifically with AI being on the rise and Scrum Master roles appearing to be bringing less value as a result, because I think you've seen it, I've seen it a lot. A lot of my friends are talking about it. I've seen it a lot on social media. Actually one Instagram reel that sticks out to me right now is someone was like, hey, do you want to get into tech without having to learn how to code, be a scrum master. It's super easy. You just take a two day course and you're going to make $110,000 a year or whatever. And it's like, you know, little tongue in cheek, but at the same time, I think there's some truth to what that real was saying. Um, however, with that, I think a lot of scrum masters are being shoehorned into roles or have been shoehorned into roles of. Logging meetings. creating meetings, facilitating those meetings and then entering in the next one and saying, Hey, everyone has to show up here and, you need a story point this. I need point values for this bug before we start working on anything. and a lot of that seems to be replaced with AI or at least is able to be replaced with AI. So Scrum Masters now are in a position where they have to drive more value. where, where do you think Scrum Masters? in their role can bring more value? And do you know of any resources that are either widely available, freely available, available at a lower cost to help Scrum Masters learn how to actually bring more value to their role? Brian Milner (16:04) Yeah. Well, the first thing I'll start off in saying is, you know, one of the great things about living in today's world is there is so there's such a wealth of information that's free. You know, I can learn how to do, I can learn how to cook anything in the world by just finding the video on social media and not all of a sudden, you know, I've got everything I need to make a great dish. I may not taste the same as the person who did it, but you know, I can learn how to do pretty much anything. I can Google, you know, how to You know change out my doorbell, which is one thing I did over the holidays You know like that's the kind of thing that there's a full video showing exactly it step-by-step Here's how to do everything and and I think that you know for Us a scrum masters. There's there are some skills. I think that are gonna be More and more relevant more and more needed and I think you just have to put yourself in the frame of reference of what would AI do a good job of? this is such a answer because if my job as a scrum master is to just schedule meetings, well, then yeah, I'm in trouble because an AI can do that really easily. And you don't even need AI for that. All you just need is to have people enter when they're available. There's dozens of websites where you can do that. do that. My D &D group does that to try to find the nights we can play. It's easy to do that, and you don't need any AI for it. So if you reduce what a scrum master is down to something as simplistic as let's schedule meetings, well, then yeah, you're in danger. I think what's going to happen is that more and more, it's going to be the soft skill kind of things that are going to differentiate the Scrum Master profession. I think that AI is going to have a hard time with managing interpersonal relationships. It's going to have a hard time helping the team navigate through conflict. It's going to have a hard time picking up on details, how safe does the team feel, how well are they working together. AI can do certain things really well, but there's a reasoning that's not there now. I don't know if that's coming. I don't know if that's tomorrow, if that's 10 years from now, or a year from now, or six months. But I know that now, even though they say thinking or other things like that, it's not really thinking. It's just digging up more data. And it can process a large amount of data and give you some insights from it. That is something that it does well. but it can't intuit, you know? It doesn't have emotional intelligence. And yeah. Cort (18:47) Yeah. Yeah, think one spot or one really good definition of where AI is fantastic that I read recently is AI is absolutely incredible when there is a set of very clear specific rules. So the book that was reading that said that they use chess, example, right? Where chess has a very, as a set of very specific rules. and AI can beat any grandmaster easy. Really just like chess.com can beat any grandmaster at this point, right? Because it's able to analyze potential outcomes based on a set of rules and a scenario that it's given in. Whereas a lot of humans, we think, or a lot of human chess grandmasters, they think in a way of like, here's one specific strategy that has worked in this scenario. I'm going to go that down that route. So AI can inference, so to speak, they're going to go down this route because that's what has happened in the past. And based on that set of rules that has happened in the past, here we go. So I think you're entirely right with those softer skills where you're interacting in a space that has some guidelines, but not necessarily a set of clearly defined rules is where AI is going to struggle right now. Absolutely. Yeah, totally. Brian Milner (20:07) Yeah, I'll tell you, Cort, too, one of the things that I'm really interested in, and I've talked to you about this and some other people, I'm really interested to see how AI, especially for coding, because more and more coders are taking advantage of coding assistants. And there are some stories out there and some companies that are more and more reducing the reliance on a person to code and using more AI to do coding. Some claim that they can do it all with AI. I would be really suspicious if there's no human involved at all. But what I'm really curious about is how does it change the process? If you are using an AI coding assistant, Does that change any other part of your process? How do you verify that the code that the AI has produced is correct? Is there a pairing? Is there a peer review of that that the team does? I suspect that there's practices and things like that that are popping up all over the place that just haven't been codified yet. There hasn't been a white paper that says, here's what you do. to try to ensure that it matches well with the rest of the code or here's how you know that it matches your standards or other things. I suspect that there's plenty of those kind of things out there and I'm just kind of waiting to hear those reports. Cort (21:25) Right? Yeah. Yeah, think, gosh, was, was Mark Zuckerberg was on the Joe Rogan podcast not too long ago. and he was saying like, yeah, by the end of 2025, Facebook is already doing it or Metta is already doing this. Sorry. Metta is already doing this where they're starting to replace their mid-level programmers, their mid-level developers with AI. And Zuckerberg was saying like, it's expensive right out of the gate. Brian Milner (21:54) Yeah. Cort (21:59) Right. It's going to be a lot of time, but we see the value in this long-term. so I wonder if, if that white paper is going to come from either meta or alphabet or one of those ones, right. Brian Milner (22:09) Yeah. Well, the domino effect of this is also going to be fascinating to watch because you said that they're talking about mid-level. I've heard a lot more about junior level being replaced, Like the entry level kind of stuff. And so, okay, let's say you do that, right? And you're hanging on to your senior people who have the experience. What happens when they move on? Right? When those senior people are gone, you haven't had anyone coming up the pipeline because you replaced it with AI for the junior stuff. And you're depending on more senior, more skilled advanced people to verify, to go through and fix the issues that AI is producing. They're going to be gone. They're going to retire. You know? So I don't know how that, that will be my first question to someone like Zuckerberg about that. Cort (22:54) Right? Yeah. Yeah. Brian Milner (23:02) when they said something like that is, what's your continuity plan for moving up programmers into more senior skill level? How are you going to build that into your long-term process if you're going to replace junior and mid-level people with AI? That's going to be a train wreck that's going to happen at some point. Cort (23:27) I, cause a lot of times we talk about in courses or I've heard it a few times and I totally agree with this and subscribe to this idea that the goal of a scrub master is to work themselves out of a job. So I wonder if it's that kind of same kind of mentality that these bigger tech companies have with AI of, know, AI is going to work a developer out of a job or a developer is going to work themselves out of a job through AI being able to. code better than them, faster than them, be more precise, stuff like that. However, caveat to that, Mike was the one that said the goal of a scrum master or a good scrum master should be to work themselves out of a job, comma, I've never seen that happen. So Mike has never seen that happen, right? I don't think you've ever seen that happen. I've never seen that happen. I don't think anyone's really ever seen that happen. I don't think any scrum master has successfully done that. Brian Milner (24:10) Right. Cort (24:20) so I wonder if it's going to get to that, that kind of same point where it's like a developer will never work them themselves out of a job. It's just the cost of entry to a good developer job or to a developer job as a human. Just got up a little bit more, right? Where, where those senior positions are the only ones open. So you gotta create whatever experiences you can. Right. Brian Milner (24:42) mean, should, in reality, it should be like any other tool that people use to do a job. And it should be the kind of thing where, hey, now we have calculators, and I don't have to manually do the computations on my own. Does that mean that I don't need the reasoning and logic of knowing which computations to make? No. Someone still needs to know how to do that kind of thing. And I think that's how it shifts a little bit is. I don't know that it ever, I shouldn't say that ever. think it's, my, I'm not an AI expert, but my experience dabbling with this kind of stuff and reading articles and talking to people in the industry is that it's not there yet. It's, it's, it's good. It does a good job at, you know, being an assistant level, co-pilot level, that kind of thing, but it's not. Cort (25:29) Mm-hmm. Brian Milner (25:32) hey, let's fire our 10 developers because now we've got an AI that will do exactly what they did. It still takes reasoning and logic to know which path to go down, to ask it what to do. And I think that's just how it shifts a little bit is now there's a tool that does the more mundane part of that, but we still need the information, the logic, the reasoning to design it. Cort (25:44) Right. Right. Right. Yeah, totally. This this reminds me a lot of your conversation that you had with Lance. It's the first episode of twenty twenty five. You and Lance sat down and talked about AI and hyper hyper personalization. AI being used as a tool, which you and Lance discussed fairly thoroughly. You guys went into a little bit of depth about that. It's a tool that delivers value, but where do you think it's delivering value to, or who do you think it's delivering value to? Is it developers, the company as a whole, customers? Where do you see that value stream starting? And do you think it could eventually get to somewhere else, deliver value elsewhere? Brian Milner (26:17) Yeah. I mean, it's kind of like to me asking like, how do you, where do you see streets and roads and highways deliver value? know, like it's, there's a million places they deliver value. There's a million industries. There's a million different things that they do. And I kind of see AI, you know, as a much, much, much more advanced version of that. But just to say, they're, Does it deliver value to customers? Yes, it delivers value to customers. It might make their lives easier or make it more simple to get to what they need. Does it deliver value to the organization? Sure, it delivers to the companies because it's going to help reduce time to market and speed and maybe cost as well. Although cost, we'll see. That's kind of an interesting thing because, you know, Cort (27:26) huh. Brian Milner (27:33) You read lot of articles about how OpenAI is not profitable yet. And it's taking a huge amount of data, a huge amount of data centers, a huge amount of energy. So that runway runs out at some point. And even charging $200 a pop for their pro model a month, it's not profitable. I mean, they say that membership level is not profitable right now. Cort (27:46) Right. Right. Yeah. Right. Right. Brian Milner (27:59) So that doesn't continue forever. At some point, that money runs out. And when that does, how does it get paid for? So will it reduce costs by that point when that runway runs out and the consumers of the AI product have to pay the real cost of what it takes to run it? I don't know. Hopefully, it goes down by then. Cort (28:18) Yeah. Yeah. In that same episode with you and Lance, you talk a lot about AI as a tool, right? And it's not something that you are scared of personally because it is a tool and you view it as a tool and an aid to you being more productive. I'm just curious your thoughts on, let's take it back over to our scrum masters, right? So. someone starting out as a Scrum Master role or recently got put into a Scrum Master role, how do you think that AI can be used as a tool to aid Scrum Masters? Do you think it should take over kind of backlog prioritization so that Scrum Masters can focus a little more on those interpersonal connections? Do you think it should take over managing meetings or running meeting ceremonies so that Scrum Masters can focus on more important things? Brian Milner (29:10) I kind of, the hair on the back of my neck goes up a little bit or I cringe a little bit about the words take over. Because I'm not sure there's anything I would say that it should take over right now. I think that there are some things that it can assist with and do a better job. Like it can, you can offload the manual portion of doing that to the AI. But you know, yeah. We've talked about scheduling meetings. That's an easy thing for something like AI to do. And it does a good job. One of my favorite things that I've learned is you can dump a bunch of data into it and then ask a big open-ended question like, what are maybe some insights from this data that I'm missing? What are some key? Cort (29:37) Right. Brian Milner (29:54) takeaways that I should have from this mass of data that you sort through. And that's a really good job of interpreting that kind of thing for us. So I think it's those kind of things that, from a Scrum Master perspective, I think you can probably use it to do a lot of things like charting out velocity and tracking other trends in our velocity. Cort (30:00) Right. Brian Milner (30:15) or the trends in other data maybe that I collect for my team that I'm not aware of. I think it starts to fail a lot in the creative areas. I'll just give you a practical example from my standpoint. I spoke at couple of conferences. I try to speak at conferences on occasion. And when you do that, you have to submit papers of saying, here's what I want to talk about. I cannot use AI and go to it right now and say, hey, Cort (30:34) No, Brian Milner (30:37) I want to speak at conferences next year about AI or about Agile and Scrum kind of topics. What are some ideas? What are some things I can talk about? It's not going to give me anything that's worth anything if I ask that question. But if I already have the idea, it can help me flesh out the idea. It can help me kind of with the way I present the idea. But the idea is mine, right? Cort (30:49) Right. Brian Milner (31:03) And I kind of think that's the thing is from a Scrum Master perspective, use it for the things that would take a lot of manual time to do. But you have to know your stuff to know that you need that thing. Cort (31:12) huh. OK, so yeah, just speaking out loud here, use an AI as like, hey, I'm noodling on this idea to get a little more engagement in our daily standups. Walk me through how this would go, or something like that. Brian Milner (31:34) Yeah, I mean, there's some particulars there. you probably want to prompt it to say, you know, I want you to act as an agile expert. Ask me all the questions that you need to ask me about why my daily scrums are failing and help me figure out, you know, three next steps I could take to try to improve the daily scrum of my team. That would be the kind of prompt I would enter. and kind of hear what the question, let it ask you questions, let it refine it a little bit, and it'll give you some things to try. Now, maybe only one of those things is worthwhile, but if you have one of them that's worthwhile, it's worthwhile. Cort (32:10) Yeah, yeah, absolutely. Right, totally. Cool. Let's step away from AI real quick. I got one more question for you. And this can be like a, yep, we'll wrap it up after this one. One more question for you. And this was actually from the last episode with Scott, where the whole idea of it was you need to be nice by being honest, realistic, and I put in quotation marks, mean. Just being nice by being Brian Milner (32:16) All right, then we got to wrap up. Cort (32:35) Brutally honest, I guess in a good way of putting it when So again as the younger guy in this conversation as the one who doesn't quite have as much experience in having potentially career altering conversations as I like to call them When should I bring those up when should I be that kind of mean nice guy? Is it any time that I have my my foot in the door of? the CEO or someone who has a little more pull? Is it, should I only do it when I'm prompted or is there some other time that I should be bringing up these topics that are probably important, but you know, not the nice guy way of bringing them up. Brian Milner (33:13) Yeah, we were talking about the thing that I mentioned about the scenario where the guy found himself in the elevator with the CEO. And yeah, I do think there's an important kind of thing to keep in mind there where, you know, businesses are gonna expect you to kind of follow the chain of command a little bit. so, you know, I think you've got to balance that in with this. I'm not saying that you should... hey, everything that you think might be wrong in the company, go schedule a meeting with your CEO and go run and tell them. Like that's gonna make everyone between you and the CEO really mad and your CEO really mad, right? You gotta follow your chain of command a little bit. If I have a manager, I wanna be always kind of frank and honest with my manager so that they know they can trust me, that I'm gonna tell them. Cort (33:49) Yeah, yeah. Brian Milner (34:02) the reality and there it's just how blunt are you? How much do you soften when you say those things and try to say it in a polite way rather than saying, this sucks. You have to be able to play that game a little bit. But I I think you should always be honest with the people in your immediate chain of command. Cort (34:13) Right, right. Brian Milner (34:24) you, there's no, you know, definitive line about when you overstep that and go above and beyond. You kind of have to interpret that yourself. You can't do it too often, but if there are times when you feel like something is vital and it could actually have a real negative impact on your business, then, know, occasionally maybe it is okay to then go out of your chain of command and say, I just think this is really vital. And I think the company needs to know this. So I've kind of gone out of the normal chain of command. You're going to make the chain of command mad when you do that. So you have to weigh that and say, is it worth it? Do I feel like I can defend that I went outside the chain of command in this instance? that people won't see it as I'm always going outside the chain of command, but this was important enough to do it. Cort (35:10) Sure. Right. Okay. Awesome. Well, thanks, Brian. Thanks for getting that last one in there. Yeah. Brian Milner (35:18) Yeah. Yeah. Yeah, yeah, no, this has been fun. And we'll do this more often. We'll have some check-ins and try some more experience experiments. All right. Cort (35:30) Awesome. Well, thanks for having me on. Thanks for letting me ask these questions. thanks for a great conversation. I appreciate it. Yeah. Brian Milner (35:33) Yeah. Yeah. Thanks, Cort.
    --------  
    37:09
  • #132: Can Nice Guys Finish First? with Scott Dunn
    Can being "nice" at work actually hold you back? Join Brian and Scott Dunn as they unravel the myths around workplace "niceness," explore the balance between kindness and assertiveness, and reveal how honest communication can earn you respect—and maybe even that long-overdue promotion. Overview In this episode of the Agile Mentors Podcast, Brian and Scott dig deep into the question: Do nice guys (or gals) really finish last at work? They discuss the critical balance between being accommodating and assertive, why conflict can be a tool for growth, and how emotional intelligence plays into team dynamics. With stories, tips, and the psychological truths behind professional success, this episode is a must-listen for anyone looking to navigate workplace interactions while staying true to themselves. References and resources mentioned in the show: Scott Dunn Bill of Assertive Rights Elements of Agile Radical Candor Advanced Certified ScrumMaster® 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back and we're here for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today we have friend of the show, buddy of the show, Scott Dunn is back with us. Welcome in Scott. Scott (00:13) Hey Brian, great to be back as always. Love it. Brian (00:17) Love to have Scott on as always and if you've listened to some of the past episodes with him then you know why. If not, I encourage you to check it out after this episode. We wanted to have Scott on earlier this year just to talk about some things that might be percolating in a few people's heads with the turn of the year and kind of as you start to prepare and look forward and maybe even look back a little bit in things. And particularly deal with an issue around how people show up at work and Scott was saying to me earlier, kind of this phrase about, nice guys finish last? Do they finish first? Do they finish last? Can you be nice? Can you be nice at work and be promoted? Can you be nice at work and move upwards? Or do you have to not be nice? Scott (01:03) you Brian (01:11) in order to do that. So tell me a little bit about kind of the genesis of the idea from you, Scott. What have you been hearing or what's been crossing your path? Scott (01:17) Yeah, and I'm so glad we had a chance to talk about this because it's recent. So the first thing that sparked my thought on this, so granted in the leadership class, we talk about being a balance of accommodative and assertive, and I'll usually refer to a... a document called the Bill of Assertive Rights. And I was reading another book this week and actually it referenced the same thing. I thought, switching fast forward a few days and I'm doing an assessment with a company that's asked for help because they're not, they're struggling with quality, they're struggling with predictability. And I know what the leaders goals are for the efforts. And so now I'm meeting with all the team members to do an actual formal assessment for baseline. Now, and this assessment, you're going to go through, I don't know, 30, 40 questions. So it's not lightweight. It's trying to be tactical, like, Is the team well formed? Is the backlog in good shape? Do you have a roadmap? Are the leaders supporting the change? I mean, whether company level, product level, team level, and we even added some advanced questions. And the fascinating thing is over a course of all these questions, the answer was essentially, we're okay at that, right? If you ask them, are they doing this practice or not, they'd say, somewhat. And it didn't matter if it was the most basic thing at the team level or the most advanced thing at the corporate level, everything was okay. So when you look at the dashboard at the end, in our normal red, yellow, the whole thing was yellow. And so I just paused and said, you know, I've never seen this before. I said, yeah, I joke with them a little bit about that, but I said, you know, my friends kind of think about it. It actually doesn't make sense that you would be okay at the fundamental beginning things and also okay at advanced high level things. So it's usually progressive, right? You get the basics down like the satiric change curve. That's kind of what we're following. So now... And then what came out later in the conversations is that someone said basically, we're afraid to say things that are hard to hear. He used the word judgment. Like we don't want to kind of stand in judgment of others, but essentially saying something that someone's not going to hear, whether it's true or not, because they had nothing green, nothing red. So not doing well. And then the last thing that really got me triggered, you know, really start diving into this is this new year and people are getting this promotions and things going on at some of the companies. And there was a story of this one guy, like, I've worked here eight years and never been promoted. And yet everyone loves this person. Everyone likes this person. And I'm hopping on social media and someone asked that question, literally, like, give me an example of when nice guys finish last. And the guy said the same thing. He said, I am the one everyone goes to for help. I'm always ready to help. I'll do anything anyone needs. Everyone likes me. They all praise me. And I haven't been promoted in like 13 years. So partly for our own careers, partly for, you know, being a change agent, et cetera, I thought it'd be worth, you know, just having to... It's a great conversation topic, Brian (03:51) Yeah, well, I'll confirm part of that, or at least a couple of crossovers there with what you said, because there's an assessment kind of thing that we do at Mountain Good as well called Elements of Agile. And one of the things we learned early on in doing that was you would pull the data from the survey, from actually asking them. But then before we present it back, we always have a coach who kind of does interviews as well, and then manually can shift and adjust things. And one of the things I've learned as being one of those coaches who does that is if there's something that's negative that's said, if there's, you know, we give like a five point scale, you know, five is really great, one is terrible, and you know, what number is it? If it's a little bit over into the negative side, you never get anything that's like all the way over at one, right? Nobody ever comes back to you and says, that's terrible. Scott (04:44) you Brian (04:46) but they will say, that's a three or that's a two. If it's a two, that's severe. That's kind of what I've learned is two is severe, three is bad. And you kind of have to shift those things over one notch to say, people are, their niceness are entering into this and they don't want it to be, they don't want it to look too bad. They don't know how it's gonna reflect on them. They don't know how it's gonna reflect on others. And so they don't want it to look Scott (04:50) Yeah. Okay. Yes. Brian (05:15) too bad, so they tend to like skew it a little bit towards the positive. Yeah. Scott (05:20) Yes, and the thing I think is good from that so one I keep coming back to you know self preservation this world kind of wired for this and someone was mentioning recently It's you know, shouldn't say people are selfish. We should say they have self in the center So if I'm gonna I'm just with you like if I'm gonna give feedback I'm honestly just pass facts or for those listening. I think it's totally fine say well Is it really worth it for me to say something that I'm going to have to end up explaining if a manager figures out that was me that said it because I'm the only one working on that project or whatever, right? In some ways, you're like, no, it's not worth it. I'll just kind of gently say it's not going great. Like you said, it's almost like that bell curve you got shifted over because, the professor's like, there's only, I'll only give out two A's each semester because that's truly exceptional. And so it moves it. It's a little like that. But then when you and I were talking earlier, you mentioned that conflict quadrants. And I thought that was really great because I think that's a clear structure that people could refer to as well. It's kind think about how they have interactions not just at work, but seriously in our other relationships. thought I was looking at like, man, this is so fitting. So I just thought that was a good tool to share as well. Brian (06:18) Yeah, it's interesting to see how that kind of affects people and how that affects their answers and how it affects how they're reporting. And there's a crossover here as well, because I know if you've listened to this podcast for a while, last year I did a talk on conflict management and kind of how to navigate that a little bit from a team lead or a Scrum Master kind of perspective. And it's a very sticky area that I think there's not enough training and there's not enough kind of education in. And one of the kind of interesting things that comes out from that, or came out from that conversation was, well, a couple things. One is that conflict, oftentimes we attempt to avoid it entirely, but that's a big mistake. Conflict is actually necessary for growth and if there's not any conflict then you get the kind of bad situation of we never question each other, we never challenge each other. There's a story about how that was actually something that happened at Chernobyl. A lot of the research kind of pointed to that's actually part of the root cause of why that happened is that they were all experts in their field and so they had such respect for each other that they didn't question each other when something was gonna go wrong. And so they miss this kind of basic tenet of, no, if I see something that's not, doesn't look right, I should speak up. And it may cause conflict, but it's necessary. It's necessary for us to be better. Scott (07:44) Right. Absolutely. And that quadrant that the Thomas Kilman model is so great because, for me, well, two things was one, I love it that they can say, hi, be highly assertive. You can still be highly cooperative. And that's that collaborative environment. So if we're really trying to create solutions, whether that's at work or in our relationships, then you're gonna have to assert, you be assertive and not that I'm gonna raise my voice, but I should share what I think or my opinion or if I disagree. And I think some of that when I was coming back down to it is there's still a tendency for people to feel like I need to be in the goodwill of others, right? So from the, you know, the 10, the bill of assertive rights, the 10 assertive rights, that's one of them. Like I need to be independent of the goodwill of others so I can be honest. I'm not trying to be, we can do this respectfully and winsomely and not be a jerk. But you have to let go of, if I say something I don't like, that would be bad. Or if I say something that makes someone happy, right? And I used to struggle with that. I don't want them to be sad. I don't want them to be upset, right? So now back to that quadrant, I'm not asserting myself and I'm obviously not helping them, so I'm just avoiding. And I'm avoiding the situation. It's the elephant in the room in these meetings. And now everyone's almost like, as a culture, we're kind of in cahoots. We all agree we're not gonna say anything, which makes it even tougher for anyone else not to kind of stand up and do just what you're saying, which I think is absolutely true. Speaking of that, so. Brian (09:07) Yeah, well, and just to clarify, too, I mean, you're talking about the Thomas Killen model. If people aren't familiar with that, basically, it's five different responses that people typically have to conflict in one way, form. When they encounter conflict, it's competing, collaborating, avoiding, compromising, or accommodating. those are kind of the, there are variances between anything like that. There's going to be some gray levels between them. Those are kind of the basic points. And I was telling Scott earlier, one of the things we talk about in our ACSM is when we present this information is that you kind of have to get out of your head the idea that any of these are bad. For example, the competing approach to things, the competing approach says, my relationship with the person is not as important as my stance on whatever this issue is. I cannot budge from my position. And I will jeopardize the relationship if that's what's required. That's a competing approach. And you initially read that and think, that's wrong. Nobody should take that kind of approach to a conflict. And in general, that should be our default kind of approach to conflict. But there are times when that's the right approach. When someone says something that's completely out of bounds, completely out of line, I'm going to take a competing approach. And there are times when people need to Scott (10:08) Mm-hmm. you Okay. Brian (10:30) to be presented with that for their own good. That they kind of recognize, wow, this is so important that he's willing to kind of not have a relationship with me anymore if this continues. And that's important, I think. Yeah. Scott (10:41) Yes. yeah, and I think that those examples of the people that get promoted, someone else had referenced and said essentially, it's you telling the, you know, I won't say the ugly truth, but. The thing that no one else is saying, your ability to say what no one else is saying to someone in leadership or management earns their trust. So at some level, whoever is the leadership whisperer, telling the truth on some of these things, and there was only one slot that's gonna influence and lead us to be promoted into, right? I've gotta know, if I'm wise as a senior exec, I gotta have the wisdom to know that I know lots of people probably just tell me what I wanna hear. I'm looking for the person who tells me maybe what I don't wanna hear. Brian (10:58) Ha Scott (11:24) It does it in nice way again though. From that standpoint, I can see why some of those people get promoted and some don't because you're so nice they actually don't trust you. Because you're not, to your point, I'm not willing to have conflict. I'm not willing to gamble what you might think of me for the sake of the betterment of everyone else. So there's some part where I think it's good. My takeaway looking at some of this is come back around to say, all right, check yourself when you have these conversations, just do that mental pause and say, Are you truly acting independent of what they might think? You know, do you have their best sensors or harder? Are you okay if they might respond a certain way? But it's almost like check that I'm outcome independent. So I'm being straight up and honest with them. Cause in this case, doing this assessment, try to work with the team, like, well, how hard is it to help the team or help anyone else who's actually not being honest about where things are? I don't have anything to work with now, right? Or like, yeah, I got to just take what they say is not great and then slide it down. So I recognize. And honestly, it's actually bad, but for all of us and the change, not just for our careers, but as change leaders anyways, checking that we're comfortable doing that. think growing that comfort, know, comfortability we can do. And I think it's just great for the career. And I see people getting promoted in these opportunities. Absolutely worth it. Brian (12:37) Well, there's one other story I want to share here that kind of is, this is a story from my past, one of the jobs I worked at. There was a project that we worked on that a lot of people probably will identify with this. The managers in the organization had set a deadline for it without talking to the people who actually were going to do it. from the, yeah, right. And from the very start, my developers that, Scott (12:56) No. Brian (13:01) that worked with me there on it were saying, this is impossible. It's not just that this is a little bit off, it's completely impossible. There's no way that we're going to do this. But the managers were like, well, you'll get it done. You'll get it done. And so they went forward and publicized the schedule and went all the way up to the top of the company. And the CEO knew that that was the timeline. And well, the CEO found himself in an elevator with one of my developers at one point. Scott (13:17) Board. Brian (13:30) just to ask him, hey, how's that project going? And my developer kind of sighed a little bit and said, well, you do you want the truth? Do you want the picture that everyone's painting? And he was like, well, obviously, I always want the truth. And so he told him, and he had a phrase that he used there that has stuck with me to this day. And that is, he said, bad news is not like wine. It doesn't get better with age. Scott (13:40) Wow. Yeah. Brian (13:57) And I think that's an important thing to keep in mind is that when there's something wrong, when there's something that's not right, the sooner we can identify it and shed light on it, the faster we can do something about it, the more options we have to do something about it. And the closer it is to when it's due or when we're supposed to have that thing happen or whatever, the less that we can do about it. So I'll even give a shout out. know. I can't imagine he's listening, but. Scott (13:58) Ooh. Yeah. Mm-hmm. Yeah. Brian (14:25) But that was a guy named Dave Ellet. So Dave, if you're listening, it's still stuck with me to this day. But that's a great phrase. And I think it's really apparent here. mean, being a nice guy, it's nicer, I think, to make sure that people understand the truth than it is to let the deception go on. Scott (14:29) Ha ha. Yeah, so two things on that Brian is one totally agree with you It might be hard to deliver some of this news But if you fast forward how much harder it will be for them when they have no time to make adjustments for the customer or the DNA Right and I'll tell them that right especially the product owner class You do me no favors by giving me like a week or two to tell the customer actually No, tell me now six months out that there might be some concerns, right? That's a lot easier. It's not easy, but man. It gets a lot worse That's one. I love way there's the example does not get better with age. The other thing is I think on a personal level, those who are not maybe saying what should be said or needs to be said or giving people that kind of, you know, honest feedback, you know, would you rather know now or in your performance review that there's a problem to not tell them that is in some ways what I was feeling for me is I'm actually now trying to control the optics I've seen. So it's actually a weird, it can be seen as a weird way of like, I'm just being selfish. So I'm actually not a nice guy. I'm a guy with these covert contracts about I want you to think this of me, so therefore I'm actually telling you the truth as your own coworker or peer about something that's really important you should know about, or my manager. I'm actually making sure that I, you know, take me first and take care of myself, but actually in a very short-term way out of fear versus a good worker would tell the truth and as I'm saying, probably he has more career opportunities by being one of the few people that. is a truth-telling organization like your developer and with the elevator to CEO because think about what CEO thinks of him now as well as what CEO now thinks about all the other one else is saying like, no, we're on track, we're on track, right? Those just probably reversed opinion in his ideas in his head about who he can trust to tell the truth about where things are going in these critical projects. So great example, great example. Brian (16:29) Yeah. Yeah. Well, and I think that gets to kind of the heart of this topic too. mean, you think you're talking about, you know, can you be nice? And if you're nice, is it possible to be recognized and still move ahead? And to me, think there's, this is where it starts to get really deeply psychological because I think you have to question what is your definition of nice? You know? Scott (16:47) Hmm. Brian (16:53) Because I think some people have a misaligned definition of what it means to be nice. I don't think it's nice to allow the deception to go on. I think that's not nice. I think that's something that, you know what I mean? You don't appreciate, like you said, as a product owner, as the leader in the organization, that's not nice to them to let that go on. And we might sit back and say, I'm not going to... Scott (17:14) No. Brian (17:20) I'm not going to raise red flags. I'm not going to be the squeaky wheel. I'm going to be the guy who just gets by because I'm a nice guy. We're using guy, but please understand. It's just a term. It's just a phrase that applies to women as much as it does men. So I'm not saying the gender specific thing here. Please, please forgive us for that. But just that that's kind of the concept behind it is I don't want to make waves. I want to be the nice person in this organization. I want to be seen as nice. Scott (17:40) Yeah. Yeah. Brian (17:45) your definition of nice might need to be readjusted. Scott (17:48) Yeah, huge point. think that kind of those words matter. And I think if someone would look at what they like, re-evaluate what you think is going to get you where you want to go, as well as what you would want from others as a teammate. then, and then for me, what I have to do is I have to backtrack and say, so why did you not say anything in the meeting? There's a time way back when I was working with the manager in the meeting that he was very supportive of what his colleague was sharing and the idea of someone she's presenting it to the other peers and the VP, everyone liked it except for one person who spoke out. because that one person, you know, the VP put the whole thing on hold afterwards. just asked that manager said, I thought you liked her idea. He said, yeah, no, I liked her idea a lot. So when the other person says something, why, why didn't you say something back? Right. And said, you stand up for what you thought was a good idea. What she was saying. But was the same idea of like, don't want to make any waves. But he said later, goes, that was the most important question I had to be asked about. I do need to speak out. I do need to be assertive in these meetings and say what my view is too, not just what they say, go along to get along. Like, and now we're just letting, you know, projects and this should go off track, right? No one's calling it for what it is. Brian (18:52) Ha Right. Yeah. So I think it's possible. Scott (18:57) So I think, yeah, that part. Brian (18:59) Sorry, I was just gonna say, I think it's perfectly possible to be assertive at certain points and take strong stances on certain things, but not compromise your niceness. I don't think that makes you a mean person. It may not make you everyone's favorite person every moment of the day, but it's nicer. People respect people who are honest. Scott (19:25) That's a good word, respect. Right. Right. Yeah. I wish there was a secondary word and we can be friendly in these other things. and I love what you said. Like it may be nice to not tell the, you know, you think it's nice, but people should know those things that they're not hearing. And that part's not nice. I think that aspect of maybe self-preservation to the detriment of others and then re-examining why, why do I feel like I need to do that? You know, for me, that was probably at work as well. Right. Is it, what was one person said? Harm versus hurt. This might hurt them in the moment, but it doesn't harm. So the shot to the dentist, the needle, that does hurt, but it's not harming them. Sugar tastes great, doesn't hurt at all, but it harms you. So kind of maybe reflect back on what does it mean to have your peers, your colleagues, your company's best interest at heart, and then what keeps us from that, right? And what are we looking out for? Are we that risk anyways? Yeah. In any case, I like that tool. I'm glad you brought that up. Brian (20:19) Yeah, I think there's also, I think it's important to say, know, like this with a lot of things, there's a balance. And we probably, know Scott, you probably have had this as well, but I've had a couple of people I've worked with throughout my career who just, they weren't concerned about being the nice person. They were much more of the outspoken and they would say things very bluntly when something was not going. Scott (20:25) Mm-hmm. You Brian (20:43) in a good direction. I think that's where NICE enters the equation, right? NICE is not letting it go, but NICE is being able to cushion a little bit what it is you're saying so that it's not just a slap across the face, but it's more of just maybe we want to reconsider that. Maybe we want to think about that, or have we thought of, or have we considered what the implication might be in this area. That's a much more digestible way of taking in that kind of news than it is to just say, well, that sucks, or that's going to be terrible, or you're going to fail miserably at that. And I've had people I've worked with who that's the kind of way that they respond. Scott (21:14) Yeah, right. Yeah, almost like a judgmental view of that. It comes across and I think some people maybe miss that. I know there's a big, you know, space on emotional IQ or EQ. I think that that's really valid and kind of checking yourself on that. I think some people don't read those. signals or they'll say like, well, someone needs to say it. Well, you didn't have to say it like that though, because we, I think we all want to be effective. So if we're not careful, then you, might be true, but they're not hearing you now. So you're still not effective in what you want to do, which is communicate that concern. So there is some part and that's what I like about radical candor. We do want empathy and we do want to care. So what you're kind of touching on, which I think is really great. If you take it that away, then we're just going to, we could actually make things even worse. So it's not a license. partly I see happen a lot and maybe you've been in these meetings and my friends listening, you know, you probably have too, where something said that you can tell there's a lot more underneath that, like that person's just mad, right? You can just tell bitterness or resentment or something's coming out. And again, other people can read that and it's not helpful. One, probably doesn't help you get your idea across, but two, it's just not helpful for you or to carry that around. So for me, I'm always trying to catch it like, is there emotion underneath this, if so? You gotta deal with that. Like you might need to wait to say this until there's not, you don't feel that emotion coming across. Cause then those things get said like you'd said under the guise of, I'm just trying to be honest with them. But look, that was a lot more that wasn't necessary and there's emotion. We've all sometimes worked at places with people that maybe wrote us the wrong way, or you've been a certain job for a long time and it can kind of bubble out in those meetings. So again, a great opportunity to kind of check and say, Where's my emotional bandwidth as I go and have this conversation? And I think also, what do you want? What do you want from the outcome of these things? Some we can control, some we can't. I might want to raise, but I'm not in control of that. But I'm in control of what time I show up, what I'm reading for work, being ready for meetings. I'm in control of that, and hopefully those things could come. So also, I know it's near the beginning of the year, get opportunity on goals and being clear about what you want. Because I think if we don't have a true north for ourself, it's easy to be what everyone else wants at the workplace. We don't actually have a sense of self anyway. So yeah, sure. I'll do whatever you want for me. And it's not even maybe, you know, maybe helping me move forward as well or maybe I'm sacrificing. So that's good timing for that as well for folks who are into doing goals or you have your, you know, 2025 roadmap in front of you. It might be a personal growth area. think it's good for everyone to take a look at at least. Brian (23:44) Yeah, and I think it's good to we propose this kind of can you get ahead? And so there is kind of the the weird marriage here a little bit of of how leadership plays into this. And, know, there is a view of management or leadership sometimes that is one that is much more authoritarian. And so I've known people who feel like, well, if I'm going to get to that level, then I need to. Scott (23:48) Yeah. Mm-hmm. Brian (24:09) be able to demonstrate that a little bit more. And I think there's a misunderstanding there as well. I don't think that's really what's required or is what's helpful in a leadership kind of position. It's kind of that whole paradigm of, do you feel your job as the leader is to push everyone towards the goal? Or do you feel like the... Scott (24:12) Mm. Brian (24:31) the job is to clear everything out in front of them so that they can easily reach the goal. That's a big difference in management style that I think can be really reflective in whether they're seen as nice or not nice. Scott (24:37) Yeah. Yeah, right. It's funny you say that because I was just hearing this from someone else as well. Like, the amount of leaders out there who don't have clarity on their goals and vision. So to your point, now you made it doubly hard for my people to try to aim themselves towards these goals. You know, of essentially self-organized, self-leadership, work on themselves to get there. It's lot easier if we have the vision, the goals in front of us. That's one thing I like, I was talking to my team earlier today about OKRs can be pushed down or rolled out from the top, of course, because they're the ones with the goals and the vision, but boy, it's an enablement for people then to figure out how to do the things they need to do to get there. And without that, we're rid of a struggle. So... whether I'm showing up as a kind of leader. So now what I'm left with, there's not a vision to motivate and guide my people and support them as a servant leader to get there. Now we're just back down to tasks. And I think those tasks can come down to like authoritarian, I just need you to do this, take out, take care of that problem, fix this, put out that fire. And that's one, you gotta make sure they do it and do it right. Cause it's at that level, there's not a lot of space for creativity and freedom. And we're not building anything big or necessarily. And projects can even kind of break down into that. So I'm glad you're bringing that up on the leadership styles. We don't have to always show up and be domineering. I think I want to be the kind of leader that is more about we than I and you. pulling something together and coaching up, but without the vision guidance, that might be an opportunity. Whatever department people are in, you can always have that conversation. Or even for the people themselves, again, you can always work on that. But those leadership styles, I think, fold in really nicely, say, do we have a vision and goal to catalyze people towards? Or am I just left with, you know, compliance, task type, manager, I just got to make sure people doing the right thing and complete things when I told them they need to all that, like the old school way. I think there's still probably a lot of that. Brian (26:35) Yeah. Yeah. And don't get me wrong, I completely understand from a leader, from a manager perspective, there are some basic kind of things that I think we have responsibility for. If you have an employee, let's say, that's stealing from the company or something, you're not going to just approach that as, hey, well, I'm not going to push them about stealing. I'm just going to try to clear the obstacles from Scott (26:58) Ask them how they feel about the stealing. Brian (27:00) Right, right, right. mean, don't anyone listen to this and think that we're saying that there's not that basic responsibility. I think that that is still part of being that leader and being a manager in some way, or form. I used to have a manager and for a while I sold shirts outside of Phantom of the Opera as part of the merchandise career there for that. And my boss there had this philosophy style of just, hey, you do your job. And, we're friends. We're the time in between, we just hang out and have fun. But if you're not doing your job, then we have to have a conversation. And I think that's kind of the basis there is like, don't, don't put me in that position as the manager. It's not, you know, you're not respectful of me when that's the case. and sometimes that, that, that occurs and you know, sometimes people have to be fired and all those other kinds of things. I get that. but that's, I think you can. You know, I remember one specific person that I had to fire at one point that, you know, it was, I felt after the, the event that it was actually the kindest thing I could have done to that person because they needed that, that to happen to them. Believe me, I know it's not good to get fired. I understand that, but this person had enough going on in their life that they needed that kick to do something else because they were not going into a good place. And, I just think that sometimes that's. Scott (28:03) you Brian (28:16) That's the kindest thing to do. Scott (28:18) my goodness, my first boss that pulled me into his office to say my performance wasn't adequate. He was just, and he, promise you, he probably said it just the way I'm saying it to you. I thought I was gonna die. But it was, I really did. just like, my heart's, you my throat and mouth totally dry. But it was the best thing I did, because I went back and like. Brian (28:27) Yeah. Scott (28:37) Yeah, why the heck am I not getting as much done as everyone else? Because I literally was just like an office clerk typing in stuff and word. There's no real complexity to that. But it was what I would, because then I started paying attention. I never had to get talked to again like that. Thank goodness. But boy, was like you said, kind of thing you could have done. And again, I thought I was going to die. I didn't die. I needed to hear that feedback and then fix it. You mentioned something that also makes you think of what Google's research had found about that you need to know their best teams are ones that include the they know they have dependable team members. So the managers gotta say, look, if there's an issue on someone your team is not delivering when you need them to, then yeah, I need to step and help. That should be to be fixed. Google's saying the team members need that, but they also need meaning and impact, that their work makes a difference. Their work is bigger than it just has. So I think that's that nice combination of, I will step aside and address this assertively until that's not okay. that we got to perform this way. At the same time, I'm casting a vision about how this has impact bigger than just this team and you're part of something bigger than you show up in your code or your test or whatever. So I like that situational leadership that's going across. It's kind of reflected in their research as well. I'm glad you brought up that story. Thank you for management. Brian (29:46) Yeah, so I So I think I think it's uh, you know if I were to try to sum that I just I think You know when I'm asked a question, can you be nice or do nice guys finish last? I I don't think so. I mean, I don't think that you're gonna finish last just because you're being nice Depending on how you define nice You know, you can't you you have to be honest you have to be you know, entering those relationships in a healthy way. But that's not being not nice. That's that's just showing up and and giving your best to the job, I think. And if you do that in a respectful way and in a kind way, I think that makes you a nice person. And I don't think that person necessarily is going to finish last for those reasons. At least that's my opinion. Scott (30:25) Yeah. Well, I like that. And again, on your chart, I like the fact that main thing is be assertive. You have an opinion. Reminds you of the JavaScript, right? Assert. You're just saying it. Just saying it needs to be said. And some people might edit themselves to say, well, who am I? And I remember reading somewhere about, look, you have value in what you say because you exist. It doesn't have to be that you worked there for five years and you've got Brian (30:54) Yeah. Scott (30:57) you've written books, technical books, it could be that you're a thinking human being who is smart and knows stuff and has opinions. That's why we share what we share and not to edit ourselves out of that saying I shouldn't assert myself because of X or Y. anyways, a good conversation for the beginning of the year. And I like what you're rounding out that nice guys don't finish last. Maybe there's another word and maybe also there's a balance for these guys and girls as well. Brian (31:23) Yeah, I agree. Well, Scott, thanks for coming on. I appreciate you making the time and it's always great to have you on the show. Scott (31:30) My pleasure. lot of fun. Thanks, Brian.
    --------  
    33:21
  • #131: Lessons from Modern Agile with Joshua Kerievsky
    Is Agile still relevant in today’s fast-paced world? Brian and Joshua Kerievsky reveal the four game-changing principles of Modern Agile that prioritize safety, empowerment, and continuous value delivery. Overview In this episode, Brian Milner sits down with Joshua Kerievsky, a pioneer in the Agile community and the creator of Modern Agile. They discuss how Agile practices have evolved, the critical role of safety and empowerment, and how to deliver value continuously in today’s fast-paced world. Don’t miss these insights into creating better teams, products, and results through simplicity and experimentation. References and resources mentioned in the show: Joshua Kerievsky Industrial Logic Joy of Agility by Joshua Kerievsky Modern Agile #33 Mob Programming with Woody Zuill #51: The Secrets of Team Safety with Julie Chickering Badass: Making Users Awesome by Kathy Sierra The Power of Habit by Charles Duhigg The Lean Startup by Eric Ries Experimentation Matter: Unlocking the Potential of New Technologies for Innovation by Stefan H. Thomke Agile For Leaders Mike Cohn’s Better User Stories Course Accurate Agile Planning Course Join the Agile Mentors Community 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. Joshua Kerievsky is the founder and CEO of Industrial Logic and author of Joy of Agility. An early pioneer of Extreme Programming, Lean Software Development, and Lean Startup, Joshua is passionate about helping people achieve genuine agility through principle-based approaches like Modern Agile. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back. And this is another episode of the Agile Mentors podcast. I'm here as I always am. I am Brian Milner and today I am joined by Joshua Kerievsky and really excited to have Joshua here with us. Welcome in Joshua. Joshua Kerievsky (00:16) Thank you so much, Brian. Happy to be here. Brian (00:19) Very excited for Joshua to be here. Joshua's been around for a while. He's been doing this for a long time. He said, you know, when we were talking before, and he's been involved with Agile before, it was called Agile. And, you know, that probably tells you all you need to know there. But a couple other things here about him, just so that you kind of can place him a little bit. His company is Industrial Logic, Inc. and he's the CEO and founder of that company. He has a book called Joy of Agility that's out there that I highly recommend. It's a really great book. And he's also closely associated with something that maybe you've been aware of, maybe you've heard of, maybe you haven't, but something called Modern Agile. And that's what I thought we'd focus on here for our discussion is really to try to understand a little bit about it. especially for those of you, maybe you haven't heard of it, haven't been around it before. So... Why don't we start there, Joshua? Tell us a little bit about what was the need that was trying to be filled with something like modern Agile. Joshua Kerievsky (01:19) Well, it goes back to a conference I attended in Prague back in around 2015. And I was giving a speech, a keynote speech there, and that ended. And then I went and said, well, I'm going to go join the OpenSpace. And I was just looking at what people were talking about at the OpenSpace. And at that point in time, I had already been experimenting with a ton of stuff that just kind of different from what we had been doing 10 years earlier or even later than that. I mean, just this was new things that we were doing, whether it was continuous deployment or ideas from lean startup or ideas from the Poppendiecks and lean concepts applied to agility or just a lot of things that were just different. And none of the sessions I was seeing in the open space seemed to be talking about any of that stuff, like giving up story points or moving away from sprints until continuous flow. just nothing was being talked about. So I just said, well, I'm going to host a session, and I'll call it, I don't know, a modern Agile. And so that's as far as I got in terms of thinking about the name. I just wanted to run a session where we could talk about, there's a lot of new things we're doing that kind of display some of the older ideas. And they're very useful, I found. So the session ended up getting a lot of attention. 60, 70 people showed up there. So we had a big group. And it was well received. People were fascinated by the stuff that they weren't aware of. And so I then repeated this open space event in Berkeley. Like a month later, was Agile Open Door Cal in Berkeley was running and did it again. And again, there was tremendous interest. in this, so much so that I decided to write a blog and wrote the blog and started getting more conversations happening. And that sort of began the movement of describing this thing called Modern Agile. And it took a few twists and turns in the beginning, but it wasn't sort of, I guess, if anything, I felt like Agile needed to be a little more simple. in terms of what we were explaining, because it was starting to get very complex with frameworks, enterprise frameworks coming along like safe and just too many moving parts. And so what ended up happening is I wrote some things and people started to notice, there's kind of like four things there that are really valuable. One of them was The names changed a little bit over time. But anyway, what ended up was four principles emerged. And that really became modern Agile. Brian (03:58) That's awesome. just for listeners here, I've pitched attending conferences in the past. If you've listened to this podcast, you've heard me say that, and I'll create things come out of that. And here's an example, right? This is something that was open space discussion. Open space, if you're not familiar with that, at conferences, can, if there's an open space day or a couple of days, then anyone can present any topic they want. And whoever shows up is who shows up. And this one got a lot of attention. And a movement grew from this open space topic, which is awesome. So let's talk. You mentioned there's four principles here. And I like the distinction here we're making also between the frameworks and the practices versus the cultural aspects or the philosophy behind it. And returning to those roots a little bit more from what Agile originally was. So you mentioned there's kind of four areas of this. Let's walk our way through those. I know the first one, or one of the first ones here is make people awesome. So help us understand, what do you mean by make people awesome? Joshua Kerievsky (04:59) Probably the most controversial of principles, because you'll get people coming along saying, wait a minute, people are already awesome. What are you talking about? And it comes from my, I'm a big fan of Kathy Sierra. And her blog was incredible. And her book, she wrote a book called Badass, Making Users Awesome. And in her book, she was really wonderfully clear about Brian (05:07) You Joshua Kerievsky (05:24) that teams that build products ought to focus on the user of the products more than the product itself. In other words, she would say, don't try to create the world's best camera. Try to create the world's best photographers. Big subtle difference there. Like that is focusing so much on empowering the users, making them awesome at their work or whatever they're doing, whether it's art or accounting or whatever, whatever your product does, how can you give them something that elevates their skills, that gets them to a point of awesomeness faster? And that's what she was talking about. So I thought, what a wonderful message. And initially, I used language like make users awesome. you know, having been an entrepreneur myself and created products and sold them and You learn a heck of a lot when you make your own product. And we've made several products over the years at Industrial Logic, probably the most successful of which was our e-learning software. And that has taught me so many, so many lessons. One of them is you have to serve an ecosystem of people. You can't just make your main user awesome. What about the person who's buying the software? How do you make them awesome in terms of helping them buy something that's going to get used? If they buy your e-learning and they never use it, they've wasted a lot of money. So we've got to make sure that their reputation is intact because they made an excellent investment and it got used and it got into valuable, it created value in the company. So how do I make the buyer awesome? How do I make the person that like rolls out the licenses to people awesome? How do I make their experience awesome? How do I make my colleagues awesome so that we love what we're doing and really enjoy working together? So it kind of morphed from make users awesome to make people awesome. And it's so expanded. If anything, we set the bar higher. And all of the principles of modern agile are like unachievable. They're all kind of high bars, right? But they're the goal that we go towards. So that really is it. It's about creating Brian (07:23) Ha Joshua Kerievsky (07:35) you know, wonderful, you know, the in Great Britain, they use awesome kind of sarcastically sometimes, right? They'll say, well, that's awesome. You know, and so for them, it would be brilliant. You know, I thought of making an English version. We have many translations of modern agile, and I thought of making an English version, which would be a proper British English version, make people brilliant. But it's meant to be to empower folks to give them something. And it's so it is. Brian (07:43) Ha You Joshua Kerievsky (08:04) It does have a product focus in the sense of we're typically building a system or a product that someone's going to use and it's going to give them skills they didn't have before or abilities they didn't have before that are going to be very valuable. Brian (08:18) Yeah, I love that. And there's a sort of a servant nature to that servant leaders, not servant leadership as much, but servant nature of I'm serving these people and how do I, how do I serve them in a way that really empowers them? Kind of reminds me of like, you know, the, the great principle with, with dev ops of just, know, if I can, if I can empower the developers to be able to do these things on their own. And so they don't need someone else to come and check the box and do everything for them. You're making them awesome. You're empowering them to be more than they were otherwise. Joshua Kerievsky (08:54) Yes, yes, absolutely. I I think we've seen a history in the software field of a lot of tools coming along and helping. It's not just tools, it's also methods as well. I mean, I'm entirely grateful to the Agile software development movement because it helped nudge everything towards a far better way of working and to make us more awesome at our craft. yeah, you have to have a North Star though. If you're going to build something, You have to know, what are we going for here? What are we shooting for? And with Cathy's influence, again, it's not so much make the greatest product in the world. It's, that focus on the users, the people who are going to be using the work, using the product. Brian (09:34) That's really good. Let's talk about the second one then on my list here, the make safety a prerequisite. What was the point here behind this principle? Joshua Kerievsky (09:40) Yes. So starting probably around 2011 or so, I could not stand going to the Agile Conference anymore. It had just become too commercial and too filled with just people hocking stuff. And it just was bothering me too much. I couldn't go. So I ended up going to South by Southwest, which is an Brian (09:54) You Joshua Kerievsky (10:09) Enormous conference tens of thousands of people show up So it'd be 20,000 30,000 40,000 people showing up for these for this event, which is musical film technology just it's just wild and I came across this book by Charles Duhigg called the power of habit. He was there that year and In that book. Well, first of all that particular year was 2012 that I went my first year there it poured The rain, it was every day, it was unusual for that time, but it was just like pouring rain. So what could you do? I bought some books and I was sitting there in my room reading them. And I'm reading this book, The Power of Habit, and I come across this chapter called The Ballad of Paul O'Neill. Now who the heck's Paul O'Neill? Well, it turns out Paul O'Neill is this incredible guy, a complete business maverick. He ended up becoming the treasury secretary under Bush and not. in 2000 for a short period of time, but that's another story. And he ran Alcoa for about 13 or 14 years. And so the Ballot of Paul O'Neill is very much about what he did at Alcoa to turn the company around. And in essence, you could say he made safety a prerequisite. That safety was his guiding light in turning that company around, which meant left people empowered to do all kinds of things. So it went way beyond safety, but started there. And it's an incredible story. I've written about it in Joy of Agility. I got so into Paul O'Neill that I ended up interviewing his main lieutenant. And then I got a chance to interview him a couple of times. the man's a genius. He passed away a few years back. Absolute genius. this concept of safety started to really pull at me in the sense that I felt, first of all, extreme programming, and I'm a big practitioner of extreme programming, brings a tremendous amount of safety to software development. It may not be as explicit in saying safety, safety, safety. When you look at extreme programming, doesn't really talk about safety, but it's implicit. And these days, Kent Beck's much more vocal about, you One of his missions is to make software development safer for geeks. But safety to me is almost like I found my home. Like safety was something that, what I learned through Paul O'Neill was that it's a doorway to excellence. And he transformed a hundred year old company with safety. I would complain about companies we were working with that were 25 years old and had an embedded culture. Like, how are we gonna change this company? But safety started to be this thing that I hadn't really thought enough about, and making it explicit opened up a lot of doors, right? And I became very interested in the work of Amy Edmondson, who's extremely famous today, but back then she was not so famous. And huge fan of hers. I, you know, I can email her and she'll email me back and she wrote a nice thing about my book. So. She has done some incredible work there. And so when we talk about safety in modern agile, it's psychological safety. It's financial safety. It's any of the safeties. There are many safeties that we could talk about. And it looks at all of them, right? It's brand safety, software safety in terms of security. you know, of the software and on and on and on. So make safety prerequisite is vast and big in terms of what we're trying to do there. Making it a prerequisite means it's not an afterthought and it's not a priority that shifts with the winds. It is permanent. It is something that we know we have to have in place. And it's very, very hard to achieve. Just like make people awesome is hard to achieve. Boy, is make safety a prerequisite difficult. Brian (13:43) Hmm. Yeah, I love Amy Edmondson's work as well. I'm just kind of curious. does the safety kind of inclusive of things like quality as well? Do you intend that to be part of what you mean by safety? Joshua Kerievsky (14:11) Well, mean, to the extent that it makes it safer to do good software development. So if bugs are happening all the time, you can't make people awesome, typically if you don't have quality. If you have really poor quality, nobody's being made awesome. They're experiencing all kinds of problems with your product. So make people awesome and make safety a prerequisite are very much tied together. That is, there is no real excellence without safety. You could think you're having an excellent experience, so that all of a sudden there's a major problem, and boy, are you unhappy. So they really go hand in hand. You could have the most incredible restaurant, and then one day you've got food poisoning happening. Great, no one's come to your restaurant. So you will not make anyone awesome if you don't make safety a prerequisite, and quality is part of that. Brian (14:57) Awesome. Well, let's move on to the next one then, because the next category is one that just resonates with me a lot. Experiment and learn rapidly. What was kind of the thought behind this one? Joshua Kerievsky (15:06) Yeah, and this is one where it that's shorthand, if you will, because you can only fit so many words on a wheel there. But it's important to know that that really means experiment rapidly and learn rapidly. And that comes a lot out of it in the influences of something like Lean Startup. I'm a huge fan of that book and of Eric's work, Eric Reese's work. Brian (15:13) Ha Joshua Kerievsky (15:29) And the fact that we can experiment rapidly and learn rapidly rather than just building everything and then learning slowly. Right? How can we do cheap experiments quickly to decide what's important to work on and what isn't? Let's not build stuff nobody wants. Let's find more time with our customers and understand their needs better so we can build the right things that make them awesome. In other words, and a lot of these are interconnected. In many respects, modern Agile is a Venn diagram. ideally want all four principles to be overlapping. And right there in that middle is where you really want to be. Not easy. But experimenting, learning rapidly, yeah. So challenge yourself to find ways to do quick, cheap, useful experiments. You can do lot of unuseful experiments. Amazon experienced that. There's a story in my book about how Amazon had to start just shepherding the experiments a little more and having some better criteria. Because you could do an endless array of experiments and not get anywhere. There's a wonderful book called Experimentation Matters by a Harvard business professor. Wonderful book as well. But I love experimentation and learning. And I see it as critical to building great products. So that's that principle there. Brian (16:46) Yeah, there's a real difference, I think, in organizations that put value on that learning process. if you see it as a valuable thing, that we invest time to gain knowledge, then that really can truly make an impact when you go forward. I know I've talked about this in classes sometimes where people will say, isn't it a little bit selfish from the organization to try to always just figure out what's going to sell the best? or what's going to work the best in advance of putting something out. My response is always, well, yes, there is a benefit to the business, but there's a benefit to the customer as well because they would rather you work on things that they care more about. Joshua Kerievsky (17:24) That's right. Yeah. I mean, we once put out an experimental product to a large automotive company. And we were really excited about it. We had a whole list of features we wanted to add to it. But we were like, you know what? Let's just get this primitive version kind of in their hands just to see what happens. it turned out that we learned very rapidly that they couldn't run the software at all. There was some proxy. that was preventing communication with our servers from their environment. So it was like, excellent. We learned really quickly that instead of those fancy new features we want to add to this thing, we're going to fix the proxy problem. And to me, that's the nature of evolutionary design is that we create something, get it out there quickly, and learn from it rapidly and evolve it. So it goes hand in hand with that as well. Brian (18:11) That's awesome. Well, there's one category left then, and that is deliver value continuously. So what was the genesis of that? Thinking about delivering value continuously. Joshua Kerievsky (18:19) So that was heavily influenced by my own journey into continuous delivery and continuous deployment and that whole world. We got into that very early. I was lucky enough to catch a video by Timothy Fritz, who he worked with Eric at IMBU. And he coined the term continuous deployment. And that video is actually no longer on the Brian (18:43) Ha Joshua Kerievsky (18:44) But this was something that I became enamored of was doing continuous deployment. And we started doing it at Industrial Logic with our own e-learning software back in about 2010. And by the time you get to like 2015, it's like, hey folks, there's this thing where you can do a little bit of work and ship it immediately to production in a very safe way, a safe deployment pipeline. It's friggin' awesome. But the principle doesn't just apply to that because this modern agile is not just about software development. It's how can I work in a way that gets value in front of people as fast as possible? So for example, if I'm working on a proposal, great, I'm not going to work for two weeks and then show you something. I'm going to put something together, a skeleton, I'm going to show it to you and say, what do you think? Does this add value? Where would we improve this? Blah, blah, Again, going hand in hand with evolutionary design. continuous delivery of value is something that is a way of working. With artists that I work with, they'll do a quick sketch or two or three sketches of something first before we start settling in on which one do we like the best and how do we want to craft and refine that. So there's a way of working in which you're delivering value much more finely grained and approaching continuously instead of in bigger batches. Brian (20:05) Yeah. I love the connection there between artists as well, because I've got a background in music, and I'm thinking about how when you go to write a song or create a new work like that, you start off with the roughest of demo tapes, and you move from there to increasingly more sophisticated versions of it until you finally have the finished product. But no one thinks that's strange or thinks that's weird in any way. But you're right. Sometimes there's this attitude or kind of I think in some organizations of, we can't let anyone see that until it's absolutely finished, until it's done. Joshua Kerievsky (20:39) Yeah, yeah, and that maybe that's that there's some fear there, you know, because they don't want to be thought of as, you know, being lesser because they put something rough in front of someone. Whereas I view it as a, you know, to me, it's a sign of weakness when you when you only send something polished because you haven't had the courage or the sense of safety to put something rough where we can make better decisions together early on. So. There's a lot of learning, I think, around that. But it's a challenging principle of its own, deliver value continuously. And people would say, well, what does value mean? Value is one of those words where it's unclear, because you could improve the internal design of a software system. Is that value? It probably is. But you've got to be able to quantify it or prove that it's going to help make things more graceful in terms of flowing features out. yeah, quantifying, communicating what the value is. is important. I'm also a big fan of maximizing the amount of work not done, as it says in the manifesto. So how can we do less and deliver more sooner? Our motto in industrial logic now is better software sooner. And a lot of these principles go straight into that. that drives it. Brian (21:38) Yeah. That's really great. Yeah, I love these four principles and I think that they really represent a lot. There's a lot that's baked into each one of these things. And I'm sure as you kind of put this together with the community and started to talk more about it, I'm sure there were some challenges. I'm sure people came up to you and said, well, what about and how about this? Is there anything now looking back on this that you'd say, gosh, we really... really didn't quite cover this or, know, this is maybe I could fudge it and squeeze it in this area, but you know, there's this other thing that I really think would be important to kind of mention here as well. Joshua Kerievsky (22:28) Well, you know, it's funny, because I thought I was going to write a book. I started collecting stories. I love telling stories, and I find stories to be a great way to help educate people. Not the only way, right? But as part of some of the workshops I give, you tell a story. Hopefully it's a story that's sticky, that sticks in the person's brain. And over the years, I collected stories like that, stories of agility. I thought I'd be writing a book about modern agile when I started writing Joy of Agility. Gradually, as I wrote more and more stories, they didn't quite fit into all those four principles. And I think the lesson I learned there was that I was starting to talk about what pure Agile means, the word Agile. What does it really mean to be Agile? Whereas modern Agile is really almost in the context of product development, of building services or products for people. Whereas Agile itself is even more pure. And so the... the book itself got into the difference between quickness and hurrying, which you can relate to this. You could say experiment and learn rapidly. Well, OK, maybe we shouldn't rush it. Don't rush. Be quick, but don't hurry is one of the mantras in Joy of Agility. So adapting, right? Adapting, we talk about adapting all the time. So to be agile, you need to be able to adapt quickly. These four principles in modern agile don't say anything about adapting. Brian (23:46) Ha Joshua Kerievsky (23:48) So that's kind of implied, but it's not there. So it's a different lens on agility. If anything, I'd say the make people awesome principles are not meant to. It created some dislike, I'd say, from some people. It could have been called empower people, potentially, although a lot of people really love make people awesome. I don't know so much what I'd change there. I'd say we have a .org. So it's a modernagile.org is a website. There's a pretty large Slack community, which, know, four or 5,000 people on that. We don't certify anyone in modern agile, so there's no certifications, but it's something that is neutral in the sense that whether you practice Scrum or Kanban or Safe or whatever, these principles can influence you. And, you know, but again, this all came out of like, when I went to that open space conference in Prague, I had no idea I was going to talk about modern agile. You know, it was not like a predetermined thing. It was just like, my God, they're not talking about the modern ways we're doing stuff. So, and I always encourage people to, you know, keep pushing the limits and keep modernizing. I said to my own company the other day, our wonderful ways of working that we've been doing now for years that have evolved, they're probably antiquated as of today. You know, with generative AI, what would we do differently? Let's have a perspective on our own work as it needs to be modernized constantly. So the term modern in modern agile means always be modernizing, always be looking. Okay, I've had people say, well, Josh, some things don't need to be modernized. There's things that are just evergreen. They're classic. I'm like, absolutely. I'm not changing evolutionary design anytime soon. I find it to be quite useful in so many contexts. So yes, there's the evergreen stuff. And then there's the stuff where you can, indeed, discover a better way. The manifesto itself says, we are discovering better ways of working. Great. Keep that going. Keep modernizing and looking for easier, simpler, quick, easy grace. as the dictionary definition of Agile says, how can we work with quick, easy grace? That's always going to be improving, hopefully. Brian (26:12) Love that, yeah. And you're right, I mean, think there's some, to some people I think that there's, I guess at times an attitude of, you this is all new stuff or this is a brand new concept and something they don't really see the connection backwards in time to how these things are all built on other ideas that have been progressive over the years. So the idea of, yeah, this is, you know, we're, we're not saying that certain ideas are bad because now we're trying to modernize them. We're just saying we're trying to apply that same principle forward into kind of the context of today, which I don't see anyone should have a problem with that. Joshua Kerievsky (26:48) That's right. That's right. Well, and if you are experimenting and learning rapidly with your own process, which I highly encourage, chances are the way you work today will be different than it was yesterday. You will be exploring, like we use discovery trees today. We didn't use them before. Years ago, no one knew what a story map was. There wasn't such a thing as a story map. Now we have story maps. There's constant improvement happening. And you've got to be open-minded and willing to try new things and drop old stuff. We thought sprints and iterations and extreme programming was absolutely fundamentally part of the way to work. Then we started experimenting with dropping them and turned out, wow, this is pretty cool. We like this. It works pretty darn well for our purposes. That came through experimentation. some of our experiments were terrible, just terrible. It's not an experiment if you already know the outcome. keep pushing the limits of what can make you happier and more joyful at work in terms of producing great stuff. Brian (27:46) Awesome. That's great stuff. Well, I can't thank you enough for coming on, Joshua. This is great stuff. just, you know, we'll put all the links to the books mentioned and everything else in our show notes for everybody. But as Joshua said, you can go to modernagile.org and find out more about this if you'd like to. You'll find information there about Joshua himself or his company again is Industrial Logic, Inc. And, you know, his book again, just to mention that, Joy of Agility. We were talking how some people get that title a little mixed up or whatever, but it's just the three words, joy of agility. So just look out for that book. I think you'll find it a rich resource for you. Joshua, thanks so much for coming on. Joshua Kerievsky (28:25) Thank you, Brian. Thanks to you. Thanks to Mountain Goat and the folks there. And I really appreciate chatting with you. It was really wonderful.
    --------  
    32:09
  • #130: Be the Change: How to Drive Impact Without Authority with April K. Mills
    Ready to spark real change in your organization? In this episode, Brian Milner sits down with April K. Mills, founder of Engine for Change, to reveal how anyone can become a powerful change agent—without waiting for permission. Learn how to drive meaningful change, navigate resistance, and reignite Agile practices with strategies that actually work. Overview In this inspiring episode of the Agile Mentors Podcast, Brian Milner talks with April K. Mills, CEO of Engine for Change and author of Everyone is a Change Agent, about what it truly means to lead change. April explains how effective change agents focus on clearing obstacles rather than forcing compliance, and why fostering curiosity, empowerment, and collaboration is key to sustainable change. From navigating corporate roadblocks to revitalizing Agile practices, April shares actionable insights and tactics to help you take control and make a lasting impact—whether you're in a small startup or a global enterprise. References and resources mentioned in the show: April K. Mills Everyone is a Change Agent: A Guide to the Change Agent Essentials by April K. Mills Change Tactics: 50 Ways Change Agents Boldly Escape the Status Quo by April K. Mills Certified ScrumMaster® Training and Scrum Certification Mountain Goat Software Certified Scrum and Agile Training Schedule 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and 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. April K. Mills is an engineer-turned-change-evangelist and author of Everyone is a Change Agent and Change Tactics, empowers individuals and organizations to thrive through change using her proven Change Agent Essentials. With a passion for turning ideas into action, April helps people drive meaningful change with the time, title, and budget they already have. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have April K. Mills with us. Welcome in April. April K. Mills (00:11) Thanks for having me. Brian (00:13) Very happy to have April with us. April is the founder and CEO of an organization called Engine for Change. That's engine-for-change.com. That's her website. She's also an author. There's a book that she put out called, Everyone is a Change Agent, a Guide to the Change Agent Essentials. And that's what we wanted to have her on to talk about today with a little bit about being a change agent. Now I shouldn't say from the outset, April is a request. We had a listener request for April to come on. And I always love that. I always try to push those people to the top of our list and get them on as soon as possible. And it was such an interesting topic. I thought this would be just a really great way to have a great topic to have early in 2025. So April, let's start with just trying to understand when we say change agent, how do you define that? What do you mean by change agent? April K. Mills (01:09) Yeah, a change agent is someone who takes action to bring about the change they want to see in the world. So rather than waiting for a boss or a corporate program or somebody from HR to come in and say, hey, let's improve this process, the change agent sees the need for a change and takes action. And the big thing I talk about in my books and my work is the difference between what typically happens when somebody sees a need for a change in an organization where they decide, I'm gonna go get a boss to go make everybody do my idea. I call that driving people. And I draw the contrast with that and driving change where you choose the change for yourself and you clear the obstacles for others to choose it too. And I love talking about that with Agile audiences especially because Agile is a change agent movement. of folks who want to drive change. I see a better way to create this product and I want to be part of it. And that's always what's drawn me into the agile space. Brian (02:13) Yeah, that's awesome. Yeah. And it is a big change, right? To think about the dynamics of someone kind of sitting back and saying, yeah, I see something that needs to be done. I see something that should be a different way, but you know, who am I to say anything about this? Who am I to do anything about versus the person who actually takes action and does things. So that kind of leads to a question about change agents. What kind of skills or traits do you think are really helpful or beneficial to someone to be a better change agent. April K. Mills (02:46) Well, the key is that difference between driving people and driving change. It's not what degree do you have, it's not how long have you been in the industry, it's not are you a people person, are you more focused on the data or some of those factors that we usually like to talk about. It really is, are you willing to take the step yourself first and clear those obstacles and encourage and invite people to join you? Or do you want somebody to make them obey you? And that choice is really the key for anybody to be a change agent. Because so many times we've seen people who might be able to convince the boss, hey, our team should be agile. And what happens, right? It goes on for about three months. The team gets frustrated. The boss gets angry. And then everybody starts to have a reaction when you bring it up, right? I'm sure plenty of the listeners have gone into an organization. If you're passionate about agile and you go, hey, have you guys heard about agile? And they go, ooh. And they make like a face. That's because they've encountered somebody who is driving people. And so that's the big focus I always try and talk with people about is can you show up with that willingness to let people join you and understand what their obstacles are to doing it. Brian (03:57) What are some kind of warning signs or signals you'd look for to kind of recognize whether I'm actually approaching this from a driving people perspective versus driving the change? April K. Mills (04:08) So a lot of times the key is how are you thinking about or talking about in your own head about the people around you or even yourself? We have a tendency to drive ourselves as well. So you can hear it in the language, right? I'm frustrated because so-and-so won't listen. I wish I could get more attention. It's all this sort of vague or... putting the action onto someone else and then complain the action isn't happening fast enough. You can hear it in the language. And so when someone's driving change, you don't hear that. hear, you know, I'm working on, I'm doing, the next thing is my action is I'm going to go talk with this person. I want to understand. I'm going to be curious. And you get this agency, this power coming back into your body almost, and then taking taking the next step from there. And so it's almost easy. You can almost say, well, how far outside your body would you put the power to make this change happen is a useful question to ask people. And if they say, well, it's in the CEO of the company, it's in the industry, it's in my tech lead, but it's certainly not me, well, then you're not a change agent. Brian (05:20) So that brings up a good point because I think I can try to channel what the listeners might be thinking here. I know that in times I've been in organizations where, yeah, you have the ideal, you have the thing that you think is the best thing to do. But because the power dynamics in the organization, you don't really have the power to make that change and you depend a little bit on others that have the power to to help affect it. And so there is a sort of an aspect of, I don't really have the capability or the power to cause this change to happen. How can I still stay with that mindset of driving change versus driving people when I know I need someone else's help? April K. Mills (06:03) Right. So that's a great conversation. And I've started to call it phase one Agile versus phase two Agile. I'm old enough in this space where when I first joined, a lot of Agile was team-based. Somebody on the team or several people on the team said, yeah, I want better. And these are the things that we can do as a team to deliver better. And let's do them together. And then the problem was the teams could do it, but they couldn't scale it. And they were like, if only we could get the senior leaders to pay attention to us, that would solve all our problems. And then you get phase two agile, which was executives buying agile implementations and forcing it down on people. There is one right way and we will do exactly this and you must conform and no other versions are allowed. And then we got the fractures and all of the fights about all of the different aspects. And so we tried it both ways, right? We tried it with the team effort and then we tried it with this thou shalt effort. And I think the key to actually making Agile work across organizations and deeper into organizations is to keep that energy from the team-based Agile to say, we're choosing something better, but it's that piece of driving change. What are the obstacles for others to choose it to? We didn't do that step. We went from my team does it, now the boss should make everybody else do what my team does. And I think that's where we got off track. in really scaling Agile into something that was sustainable and brought that joy and commitment and everyday wanting to show up and be better across the organization. So that's what I would encourage folks to do is not try to cheat that step of getting your fellow teams and larger systems to join you by finding somebody with the power to make them be like you. Brian (07:50) That's fascinating. I know that in some of these changes I've been involved with as well, there can be things that happen that kind of find yourself stalled a little bit, right? The initiative or the changes you're trying to affect just doesn't feel like it's going where it needs to go. What advice do you have for people who feel like they're in that place where they feel like they're kind of stalled out? in the change. April K. Mills (08:16) Yeah, so a lot of the things I talk about in that book you mentioned everyone is a change agent are different tactics you can use to overcome that. One of the key things that I talk about is what I call a change buffer, which is how can you make the rules where you're at different than those rules across the organization? I mean, let's take a simple example. Let's say there's five software teams in a business. Very simple example, right? And one is doing some practices and they'd love for those practices to spread. but they're not spreading as fast as they would hope. One of the ways to protect your change is to say, on our team, we will behave this way, declare it, make it what I call a policy buffer. So when one of those other four teams says, well, why are you doing it that way? You can point to the piece of paper and say, we've agreed to behave this way. Now, if you'd love to join us, we'd love to share that with you, but this team behaves this way. So then it's not every developer having to defend in effect the practices, which can get exhausting. But then you can start to ask them, what's your policy on your team? How do you do this? And get curious. Not in a, I'm trying to lure them in and trap them into my way of behaving, but in a, really want to understand, do they have a different measure that they're being exposed to? How can we help maybe get that measure off of them? Do they have a boss who's got a different standard for what quality looks like? Well, should we have a corporate conversation around, quality across the five teams should be the same. We don't tend to have those because we want to skip the step of coming into that alignment together and just have a policy somehow drop from the stars that aligns with my values. yeah, policy buffers are really big to protect a change and help it spread and have those curious conversations at the edges. Think of it like system integration, right? You can't just dictate, you have to understand and merge. Brian (10:11) Let's say we put in place a policy buffer like that on our team and our whole team agrees to doing something and we think this is the right way of doing things. And someone higher in the organization, some manager or leader finds out about this and says, no, I don't want that to happen. We've been trying to affect the change, right? And not push the individual. But now we do have the individual who's saying, you shall not do this. How do you overcome that when you're the change engine? April K. Mills (10:38) Yeah, so a lot of times you have to understand what are the assumptions that that leader is making and again get curious, right? Because if we focus not on the method but on the outcome, we should be able to get alignment faster. So rather than going into a boss and saying, method A is my choice, method B is yours, you know, it's a cage match, two will enter, one will leave. You instead want to show up and say, Well, I think we both agree we want to deliver quality products on time that customers love at the lowest possible production costs. Are we aligned on that or not? And if they say yes, then you say, okay, now let's just understand what are you asking for? And from my perspective as a person who has to implement that, here's how I think that impacts our ability to deliver quality products that customers love at the lowest possible production costs. And these methods that I'm using are doing this and here's my data or evidence. And so you in effect want to shift it where it's not me looking at you, but as people are probably going to see on this podcast, it's us next to each other. So if we instead frame it as me and the leader looking at the issue together, because we want to win together, we're not in competition. So again, it's about seeking to understand, removing those obstacles so that we can be aligned together to go there together. Brian (11:57) I love the idea of backtracking a little bit and finding that common ground and going from that space. I think that's a great approach. I know I've had success with that in my career too, of being able to find, well, we agree on this, right? And if we agree on this, now we're just talking about the best way of getting from where we are to there. And then it's less personal, then it's less about the person, it's more about the best strategy. And we're a little bit less... personally invested that we think it's a you know a personal affront or challenge if it's if it's more about the idea So I agree. I think that's a that's a great kind of approach to doing that How about the differences in just the the context of this if I'm a change I know you know I've been in some small organizations. I've been in some medium large-sized organizations and You know I think anyone who's been in large organizations would say Well, yeah, that's nice and easy when it's in a startup, right? If I'm in a startup, then yeah, everyone's wearing a lot of different hats and it's really easy to make change, but you know, the institutional kind of inertia that can take place in larger organizations, how do you overcome that as a change agent? April K. Mills (13:00) Yeah, well, I can speak to that from deep experience because my background started as a civilian nuclear engineer for the US Navy in a hundred year old shipyard. And I started six weeks before September 11th. So I came into a nuclear shipyard, a hundred years old, very staid in the way they did things, optimized for the shipyard and the world changed. Brian (13:03) Ha ha ha ha. April K. Mills (13:25) And I watched as that organization struggled to deal with the rate of change that was being imposed upon them. And a lot of the things that I talk about in everyone is a change agent came out of that experience of understanding what tactics worked, what didn't, what philosophy worked, what didn't to be able to empower people to make changes happen. And we made amazing changes happen in the shipyard. And then I went on and did 10 years with Intel Corporation, right? The chip maker and taught these things globally and saw people do amazing things within the company. Now it's true, if you don't get the main rudder of the company, you're not gonna steer it. But there's a lot of change you can make in an organization from where you're at. And I think that's the powerful, powerful thing. And so these tactics work at scale. They work for an individual, right? If you stop talking to yourself like, you know what you need to do? You have to do this or so and so is gonna get mad at you and you instead say, What's our obstacle for getting up early and going to the gym? And how can I clear that? And how can I choose to do that every day all the way up to a team, all the way up to an organization? I've seen these things work all the way through that scale. So I've used it in community projects to deliver an accessible playground in three and a half years when everybody said it would take five or 10. And these tactics have also been proven, although they weren't listed this way, in historical successes. If you think about when Admiral Rickover founded the nuclear Navy back in 1950, they went from approval to use nuclear power to USS Nautilus underway in five years. We can't deliver anything in five years anymore because we constantly are looking for who's going to make people, how are we going to force them? Can we keep them forced to do it? And with employee turnover, with system turnover, with the rate of change, I would argue this era of driving people has to end because it wasn't ever really effective, but it's getting less and less effective. And that's the name of my second book, which is Change Tactics, which is both you should change tactics and here are some change tactics to help people accelerate their results. Brian (15:36) That's awesome. Yeah, I mean, it gets really deep really quickly here too, because you start to think about even the way we manage our projects and the fact that a lot of more traditional project management is sort of, when we talk about this change agent approach, is sort of managing the people and trying to push and drive the people towards deadlines, some, not even an outcome, but a timeline. versus trying to affect the outcomes that we're trying to achieve as an end result instead. So it really is interconnected, isn't it, through even the way we set up our projects? April K. Mills (16:13) Yes, it totally is. And I have that in the book and in the classes I teach is where is the force? So I'm an engineer by training, right? So I'm constantly looking and thinking about where's the force in the system if it was a pump or a reactor plant or whatever. And you can see it to your point with the program management is your, are you spending most of your time trying to push people to do something? Or are you moving the form, fit and function of whatever the product is? If that's delivering code and integrating code, if that's a physical product, are you clearing the obstacle so that product moves forward faster? And you hear this and see this in stories of what's going on at SpaceX, right? When they're confronting something about, can't get a part for six months or I can't get a part for a year and it's gonna cost me $50,000, they're saying. Isn't it just sheet metal? How could we make that in two weeks with what we've got? Because they're not talking about you should be able to shrink that timeline. What are you doing? Why aren't you talking to the vendor enough? aren't you pushing on the vendor hard enough? They're saying, what is the physical thing we need and how fast can we get it? And it's allowing them to shrink product costs. It's allowing them to shrink durations. It's what Rickover did in the 50s. It's what Andy Grove did with Intel back when it was Intel delivers in the 80s and 90s. Focus on the product, focus on the physics, focus on the engineering, the mechanics to support the engineering, the operations to support the mechanics, and you'll deliver products faster. And at the heart of all of that is change agents because they're not trying to get somebody to obey. They want to get something amazing done. Brian (17:50) One of the things I found kind of in when I've worked with organizations and talked with organizations about kind of moving from point A to point B is the fact that you kind of need help. kind of need, know, a lot of times people will try to make these changes all on their own and they sort of take the weight of the world on their shoulders. I can't figure out why it's not working. How do you kind of co-opt others into your strategy? April K. Mills (18:14) Yeah, well, the best way is to share with them what you've learned about being a change agent. I've had countless folks who, know, one person will read my book or come to a class and they'll go back and try it and people will get curious because you show up differently. So a simple example that I give in the book is rather than sending a mandatory meeting, which we're all guilty of, right, we get an assignment. and we go into the global outlook calendar and we pick people and we make them mandatory and we order them to come to our meeting. We say, Brian gave me this assignment. You have to come. Brian said this is really important. Come to my meeting or else. And we do that. That's the default. And I encourage folks from a driving change perspective to instead, maybe Brian, you gave me that assignment, but my meeting notice would say, I've been asked by Brian to lead this. I'm excited to do that. Here's why I've chosen this as the thing I'm going to focus on. I've marked you all optional. I think you have the skills and capabilities that would be amazing on this team. And if you're as passionate as I am, I'd love you to partner with me. We're going to start meeting on Tuesday. If you're not the right one, feel free to tell me. But I'm moving forward on Tuesday with whoever's there. And I'm really grateful that I get to work in an organization with you. Now. Who's gonna come to, which meeting are you gonna come to? The April says Brian's gonna be mad at you if you don't, or the one where April's gonna go off and do something amazing, I don't wanna miss out. And anybody can do that because everybody send in meeting notices out to people. So the simplest actions have the most powerful results. Brian (19:31) Ha It really is a cultural change too, right? mean, that's a very different cultural kind of approach to it to say, hey, it's optional, but, you know, get on board with this idea. If this is something that you're excited about, I want you to be a part of this versus, hey, you've got to, that's your job. you know, I've been given the authority to, to demand that you be here and, and, and, you know, really want. So, so how do you. You know culture changes is obviously one of the hardest things to do in an organization. How do you start to if you're a change agent? How do you start to? Change the culture in the organization to be more in line with that April K. Mills (20:25) So my focus is always on the culture starts with one. So people will treat you the way you show up. And so show up as a change agent and the world will bend around you in reaction to it. Now I do have a chapter in the book where I talk about my son who's got special needs and he took a long time for him to walk. He had to walk with forearm crutches. And the first time we were really out in public, he was walking with his forearm crutches. And you could tell that people were really confused and concerned, right? It's different. He's a small child. He looks very fragile. And you had all these reactions from people about, well, you know, where's his mother? Cause I was watching him from a little ways away. I always joke, no one ever asked where's his father if a child is wandering off. But you know, they're watching him and you could tell there were people that wanted to either pick him up and do it for him. Take him someplace because he looks so fragile, let me help you. Or they were mad that he was off on his own and I wasn't hovering. And I use that story for the same thing here. Because when you go off and you say, let's make this optional, I'm passionate about it, I'm committed, and even if I'm alone in this room, I'm going to move this forward, people are going to look at you funny. Like my son with his forearm crutches because they're used to somebody walking off strong, demanding, creating space. But it doesn't mean that that's necessarily the best way to do it. And so you have to be comfortable being different. And I use the concept of change buffers to help people with that. A personal buffer might be like Richard Feynman, the noted physicist. I don't care what other people think. I'm going to be me, their concerns to the wind. A friendship buffer. I'm going to go off and do this. when somebody goes, April's crazy. I call my friend Brian and you go, you're not crazy. You're doing the right thing. Keep it up. Let's go for coffee, let's go for the beer, whatever. A leadership buffer, maybe you're my boss and you believe in this, you've seen it. I go off and do it, people give me a hard time. I go, hey, take it up with Brian, my boss. We do things this way in his group. Or back to that policy buffer. In my group, we drive change, not people. So when somebody shows up differently, folks go, you know, why are you doing that? it's just the way we work. And that's what I've built in organizations over the years. The people that were in The groups with me that were doing this, depending on how comfortable and how strong they felt, could either say, I'm different, live with it. Or they could say, we're different. Or the policy is different. Whatever they needed to feel strong enough to show up differently. Because when you show up differently, you get amazing results. Brian (22:58) Yeah. That's so, that's so awesome. I completely agree. What if people are listening to this and hearing all this and getting excited about it and thinking, yeah, this is, this sounds like something I want to participate in. is, it sounds like something I want to start to do. if someone feels inspired by this conversation and wants to be, become more of a change agent, uh, but they really just don't know where to start. What are some practical things that you would give them to say, here's, here's a good way to start to, to move down this path. April K. Mills (23:27) Yeah, well, the simplest one is that's why you write books, right? So my book is available. I self-published it on purpose to make it very affordable. So it's, think, $9.99. Everyone is a change agent. It's $14.99 for change tactics because I accidentally wrote a longer book than I intended. sorry. When I got the first copy, I'm like, oh, that's more than I thought it was. OK. But so both of those. So for, you know, the price of a meal. Brian (23:44) You April K. Mills (23:54) for one person these days with inflation, right? You can get two books that help you not only have the basis, but have some just simple tactics, almost like a recipe book you can use. And then later this spring, I'm rolling out with my Engine for Change Company, this Change Agent Essentials class, which is based on that content. I've been teaching it now for 10 years in corporations. As we were talking before we started, right, I'm a recovering hider in corporations, I guess. Now I'm coming out into the world. And so it's going to be available for folks if they want to take the class to get that more immersive experience. So I'm really excited to bring it to the world because it works. And I'm especially passionate about agile people using it because there's too much conversation around agile dying and we need better products delivered faster that customers love at the lowest possible costs. And I don't know a better way to get there. So we got to reclaim agile from the driving people. Brian (24:47) Yeah, I completely agree. you know, anyone who's been involved in Agile in any significant, you know, way I'm sure would probably agree that it's not that the core concepts in any way are, are less, valid or, or, or no longer practical or anything like that. It's just people have seen so much bad versions of things that now that that definition has been marred a little bit, I would say. And so now we, we, we have to kind of take Like you said, take back control of that a little bit and say, now here's what it really is, and here's why we do things this way. And I like your approach there. Find the common ground and say, here's, you know, we both believe in this. Well, what's the best way of doing that? You know, here's what we think. April K. Mills (25:28) Yeah. Yeah. Yeah. And I think it's going to be a really exciting time as we go into 2025. There's so much change happening, but so much of it is at that default of driving people. So there's a huge opportunity to show up differently, to create a ripple. That one person can create that ripple. You three people can support each other while they try these new things. By the time you get to five, you almost have critical mass, right? At least two of you will always be online at any one time to support each other. And you can grow it from there. And I've seen great, great things happen. And it really is an unleashing of energy. If people can remember the first feeling they had when they found Agile and it was like, yeah, that feels more like what a professional does. And that excitement and that energy, you can get back to that and you can get back to that by driving change. Brian (26:24) Love it, love it, this is awesome. Well, this has been a great conversation. I really appreciate you coming on. We're gonna put links to everything in our show notes for everyone so you can get to April's company and find out more about her classes and also find out more about her books there as well. So April, thank you so much for coming on. April K. Mills (26:40) Thanks for having me. It was an honor to be recommended. Brian (26:43) Well, and our honor to have you on as well. So thank you for our listeners and recommending people and thank you April for making the time for us.
    --------  
    30:26

More Technology podcasts

About Agile Mentors Podcast

The Agile Mentors podcast is for agilists of all levels. Whether you’re new to agile and Scrum or have years of experience, listen in to find answers to your questions and new ways to succeed with agile.
Podcast website

Listen to Agile Mentors Podcast, FT Tech Tonic and many other podcasts from around the world with the radio.net app

Get the free radio.net app

  • Stations and podcasts to bookmark
  • Stream via Wi-Fi or Bluetooth
  • Supports Carplay & Android Auto
  • Many other app features
Social
v7.7.0 | © 2007-2025 radio.de GmbH
Generated: 2/12/2025 - 1:07:25 PM