Podcasts about agile manifesto

In this thought-provoking episode, we sit down with Tobias Mayer—author, coach, and longtime voice in the Agile world—to explore the journey from his early discovery of XP (Extreme Programming) in 1997 all the way to today's debate around the death of Scrum. Tobias shares his personal transformation from developer to Scrum Master, his resistance to early XP, and how he learned great practices from developers he managed. We unpack his reflections on Agile's semantic drift, the role of Scrum Masters as change agents vs. bean counters, and what happens when teams do Agile without even knowing the Agile Manifesto.

Jeff is the co-creator of Scrum and a leading expert on how the Scrum framework has evolved to meet the needs of today's business. The framework he developed in 1993 and formalized in 1995 with Ken Schwaber has since been adopted by the vast majority of software development companies around the world. However, Jeff realized that the benefits of Scrum are not limited to software and product development. He has adapted this successful strategy for several other industries, including finance, healthcare, higher education, and telecom.   As the CEO of Scrum Inc. Jeff sets the vision for success with Scrum. He continues to share best practices with organizations around the globe and has written extensively on Scrum rules and methods. With a deep understanding of business process — gleaned from years as CTO/CEO of eleven different software companies — Jeff is able to describe the high-level organizational benefits of Scrum and what it takes to create hyperproductive teams.   Topics of Discussion: [:35] Introduction of Jeff Sutherland, co-creator of Scrum. [3:47] Jeff Sutherland's background: His experience at West Point and lessons in making work visible. [5:19] Fighter pilot experiences that influenced the operational side of Scrum. [6:02] Transition to the Air Force Academy and work in AI at Stanford. [7:38] Learning complex adaptive systems and the origin of Agile from complex systems theory. [8:30] How complex systems theory impacts Scrum and Agile teams today. [9:25] Jeff's first experiences applying Scrum in the banking industry. [11:25] The development of Scrum and the 2001 Agile Manifesto. [12:57] Making work visible and organizing teams, from West Point to Toyota to the Agile Manifesto. [13:23] Fast forward to 2024: Issues in Scrum and Agile practices, including sprint lengths and backlog grooming. [14:34] Jeff's new book: First Principles in Scrum and its relation to Scrum technology stacks. [16:23] Building autonomous systems: Lessons from radiation physics, AI, and complex adaptive systems. [19:16] The influence of autonomous robots on the creation of Scrum. [21:14] Discussion of Scrum and AI, leading to “Extreme Agile.” [22:47] Predictions for the future of Scrum and Agile: Teams becoming 30 to 100 times faster by 2030. [23:37] Example of AI in action: Developing a system to handle expense reports using Scrum principles. [29:37] Challenges with AI-generated code and the need for strong software architecture knowledge. [33:24] The importance of following Scrum “by the book” to achieve hyperproductivity. [35:30] Jeff's closing advice on adapting to extreme agile to stay competitive by 2030.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo “How the Agile Manifesto Came To Be” Become a beta tester for Jeff Sutherland's AI software project for expense reports: support@quickaireports.com   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Are you ready to conquer the PMP exam and elevate your career? In this video, we break down a proven 4-week study plan designed to help you master the PMP exam with confidence. Whether you're navigating Agile and Hybrid methodologies, tackling knowledge gaps, or honing your strategic approach, this transformative journey will equip you with the mindset for success as a project management professional.FREE PLAN: https://projectmanagementdoctor.com/3...ELITE PMP: http://elitepmpQUIZZES ON 35 TASKS: http://pmpdoctor.comIMMERSION BOOK: https://www.amazon.com/PMP-Exam-Immer...Learn how to streamline your study process by focusing on the three critical domains—People, Process, and Business. Discover practical advice on mastering Agile principles, Hybrid techniques, and predictive project management while understanding the key components like the Agile Manifesto, Scrum Guide, and PMI standards. With insights into leadership styles, conflict resolution, and team dynamics, this guide empowers you to lead with influence and drive results.By following this structured plan, you'll target knowledge gaps, practice with mock exams, and build the confidence needed to excel. Don't miss out on expert tips and tools, including resources like the PMP Exam Immersion book and quizzes at pmpdoctor.com, to reinforce your learning and close the gaps.Start your transformative journey today! Bookmark this video, dive into the study plan, and take actionable steps toward PMP success. Visit pmpdoctor.com or check out the PMP Exam Immersion book on Amazon to boost your preparation. Let's get you certified and thriving in project management. Smash the like button, and let's make your PMP dream a reality!#projectmanagementtools #kanban #hybridprojectmanagement #projectmanagement #agileprojectmanagementvstraditionalprojectmanagementCHAPTERS:00:00 - Introduction00:50 - PMP Exam Study Strategies04:56 - People Domain in PMP07:39 - Process Domain Overview10:42 - Business Environment Insights11:15 - Conclusion and Key TakeawaysPodcast:https://open.spotify.com/show/46uJBml...Online Agile Training for PMP Exam: https://vimeo.com/ondemand/agilepmpMAIN SITE: www.praizion.comPraizion Media specializes in project management education and professional development. Please visit: www.praizion.com for project management and PMP Exam training materials.

"When people say Agile is dead, most of them have never seen it really working."In this insightful episode, Sander sits down with Arie van Bennekum, one of the co-authors of the Agile Manifesto, to discuss the current state of Agile, common misconceptions, and the evolving nature of agile practices in modern organizations. Arie shares his thoughts on why Agile is far from dead and how many organizations still struggle to truly implement it. They also discuss the importance of leadership in agile transformations and how to anchor agile practices for long-term success.Connect with Arie:Arie van Bennekum Check out our sponsor:www.xebia.comwww.scrummatch.comwww.wiserbees.comwww.masteringagility.orgHosted by Ausha. See ausha.co/privacy-policy for more information.

This is a special episode, where I introduce the "Big Agile Questions" survey and review some of the questions that you've already submitted! Thank you all who did! You can find the submission form here. Submit your questions, as we will be reviewing these in future episodes! To join 25,341 other Agilists on our Newsletter (˜1 post/week), visit this page, and join. The Power of Asking Better Questions At every major turning point in history, from the Renaissance to the Industrial Revolution, progress has begun with asking better questions. The Agile movement itself started with the authors of the Agile Manifesto questioning traditional software development methods. Now, in 2025, with significant changes in the industry including PMI's acquisition of the Agile Alliance, the community faces a crucial moment to shape its future direction through thoughtful inquiry and reflection. "Throughout history, the biggest leaps forward have come from people willing to ask difficult, sometimes even quite challenging, questions." The Future Beyond Agile

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 podcast@mountaingoatsoftware.com 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.

Scott Ambler helps people and teams adopt new ways of working (WoW) and evolve their ways of thinking (WoT), particularly around data warehousing and data quality. He is the creator of the Agile Modeling (AM) (AgileModeling.com) method and Agile Data (AD) (AgileData.org) methods. With Mark Lines, he co-created PMI's Disciplined Agile (DA) toolkit. As a conference keynote speaker, he speaks about continuous data warehousing (DW)/business intelligence (BI), how to address enterprise data debt, how to succeed at corporate AI, and agile architecture. He has also (co-)authored several books, including Choose Your WoW!, An Executive's Guide to Disciplined Agile, Refactoring Databases, and Agile Modeling. For a full list of his books, visit Scottambler.com/my-books/.   Topics of Discussion: [4:29] Scott talks about his career journey. [6:53] Scott's early involvement in Agile. [8:34] Needing to up our game in the Agile space. [8:55] Agile2025 Conference this summer in Denver, CO. [11:20] Challenges and evolution within the Agile community. [20:01] Are we going to have a new Agile gold rush? [21:47] Keeping an eye out for inappropriate processes. [25:38] How we can do better. [28:17] The Agile Manifesto. [35:03] Importance of database refactoring and continuous data operations. [36:46] What best practices does Scott recommend?   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! Scott Ambler Scott Ambler LinkedIn The Future of Agile Isn't Shit   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Today's guest is Martin Fowler! Martin is chief scientist at ThoughtWorks. He is one of the original signatories of the Agile Manifesto and author of several legendary books, among which there is Refactoring, which shares the name with this podcast and this newsletter. With Martin, we talked about the impact of AI on software development, from the development process to how human learning and understanding changes up to the future of software engineering jobs. Then we explored the technical debt metaphor, why it has been so successful, and Martin's own advice on dealing with it. And finally, we talked about the state of Agile, the resistance that still exists today towards many Agile practices and how to measure engineering effectiveness. (03:29) Introduction (05:20) Development cycle with AI (08:36) Less control and reduced learning (13:11) Splitting task between Human and AI (14:48) The skills shift (20:17) Betting on new technologies (27:22) Martin's Refactoring and technical debt (29:24) Accumulating "cruft" (33:14) Dealing with "cruft" (37:24) The financial value of refactoring (42:04) Measuring performances (46:19) Why the "forest" didn't spread (56:11) Make the forest appealing — This episode is brought to you by https://workos.com — You can also find this at: -

Xmas Special: Investing in Software: Alternatives To Project Management For Software Businesses With Vasco Duarte In the grand finale of the “5 Wishes for 2025” series, Vasco Duarte tackles the chaotic nature of software development and why traditional project management just doesn't cut it. Drawing on lessons from weather models, butterflies, and Agile practices, Vasco presents a bold manifesto for how we can thrive in uncertainty. Chaos Theory and Software Development “Project management is like trying to predict where a butterfly will land after flying through a hurricane – good luck with that!” Vasco begins with the story of Edward Lorenz, the MIT meteorologist who discovered what was later called the “butterfly effect.” This concept illuminates and explains the unpredictability of software development, where tiny changes can lead to massive, unexpected consequences – like a simple tweak spiraling into a full system refactor. Why Traditional Project Management Falls Short “Planning your year's meals in January? That's about as realistic as predicting October's sushi cravings!” Vasco humorously dismantles the premise of project management, which assumes stability, predictability, and complete information upfront. While Agile provides a more flexible approach, it's often misused as “project management in disguise,” failing to unlock the true potential of adaptability. The 2025 Manifesto: A New Way to Invest in Software “Loving Gantt charts is like loving fax machines – there's a better way!” Vasco outlines his four-point manifesto for how organizations can thrive in uncertainty: Fund Software Incrementally: Treat funding like stock market investing – small, regular investments over time. Think Like an Investor: Focus on maximizing returns, not rigidly executing plans. Experiment by Default: Acknowledge that the best ideas come from testing and iterating. Give Teams End-to-End Ownership: Empower teams to own their work from idea to delivery, eliminating micromanagement. The Need for Agility at All Levels “Scrum teams in a project management organization are like race car drivers stuck in traffic jams – all that potential, nowhere to go!” Vasco emphasizes that agility must extend beyond individual teams. Organizations need to embrace Agile principles at every level to avoid stifling innovation and potential. And his approach to funding and managing software investments does exactly that: bring agility to the decision making forums in the organization, instead of keeping it at the team level. A Wish for 2025: Embrace the Chaos “Butterflies don't follow project plans, and neither does software development!” Vasco's final wish for 2025 is for organizations to stop forcing software into rigid project management frameworks. Instead, they should embrace the unpredictable nature of development, leveraging incremental funding, iterative experimentation, and team empowerment to thrive in uncertainty. See It in Action: Global Agile Summit 2025 “Want to see how real organizations are thriving in chaos? Join us in Tallinn!” Vasco invites listeners to the Global Agile Summit 2025 in Tallinn, Estonia, where forward-thinking organizations will share their stories of breaking free from traditional project management. Holiday listeners can grab a 75% discounted Super Early Bird ticket at GlobalAgileSummit.com. About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

Agile has become a cornerstone of modern development, yet the essence of its value often gets overshadowed by procedural or tool-based interpretations. In the recent Building Better Developers podcast, Rob Broadhead and Michael Meloche delve into the foundational principles of Agile and its relevance to building better developer habits, emphasizing adaptability and continuous improvement. Here's a summary of their key insights and practical takeaways for cultivating an Agile mindset. Understanding Agile: A Framework, Not a Formula Agile isn't a fixed set of tools or methodologies but a mindset underpinned by the Agile Manifesto's four core values: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. These values encourage focusing on people and outcomes, not rigid structures. Agile allows flexibility in navigating challenges, fostering collaboration, and driving solutions that truly matter. Key Takeaways from the Episode 1. Pivoting Is a Strength, Not a Weakness The hosts highlighted the importance of pivoting when a project encounters hurdles. Unlike the waterfall model, Agile embraces flexibility. For example, Michael shared a 16-hour development detour that required re-evaluating the approach when the original solution proved untenable. This adaptability, while frustrating in the moment, prevented further wasted effort and allowed the team to refocus. 2. Breaking Down Goals: The Ruler vs. Yardstick Approach Agile replaces the traditional “yardstick” of fixed, linear progress with “six-inch rulers” of iterative development. This analogy underscores the value of short-term planning and regular evaluation to ensure the project remains aligned with goals, even if adjustments are needed. 3. Tools Are Helpers, Not the Rulebook While tools like Jira and Trello are helpful for visualizing progress, Rob emphasized that developers should avoid becoming slaves to their tools. Instead, use them to enhance collaboration and accountability, ensuring they serve the project rather than dictate it. 4. Collaboration Over Negotiation A major Agile tenet discussed was fostering collaboration with customers rather than fixating on rigid contract details. The hosts illustrated this with scenarios where understanding the “why” behind a customer's request—like insisting on a purple button—can reveal insights that shape better solutions. Instead of challenging requests outright, developers should explore the reasoning, aligning efforts with true business needs. Practical Agile Developer Habits 1. Revisit the Agile Manifesto Regularly Even seasoned developers benefit from revisiting Agile's principles to maintain focus on its core values. The manifesto and its 12 principles can serve as a moral compass, helping developers navigate project complexities. 2. Leverage Daily Sanity Checks Inspired by tools like the Pomodoro technique, developers should periodically assess whether they are being productive or merely busy. This could involve reflecting on progress mid-day or after completing a sprint. 3. Plan Weekly and Adapt Daily Rob proposed an excellent challenge: set weekly goals and adjust daily plans as needed. This builds the habit of agility while maintaining forward momentum. 4. Simplify Where Possible Michael recommended automating repetitive tasks, such as server setups, to save time and reduce cognitive load. Iteration and simplicity go hand-in-hand with Agile values. Agile Developer Habits in Action Agile isn't just for project managers or scrum masters—it's a way of thinking that benefits individual developers and entire teams. By focusing on collaboration, adaptability, and meaningful progress, Agile fosters an environment where everyone can thrive. If you're new to Agile, start small. Explore tools like Trello or Jira to organize tasks, or dive into the Agile Manifesto for inspiration. Remember, building better habits begins with understanding the principles that drive meaningful change. As the podcast hosts reminded listeners, Agile is about progress, not perfection. Whether you're automating workflows, tackling blockers in a sprint, or refining your daily routine, embracing Agile values can elevate your development practice and help you build not just better software, but a better version of yourself. Listener Challenge: Weekly Planning, Daily Adapting 1. Set Weekly Goals At the start of the week, identify a few larger goals or tasks that you aim to complete within seven days. These should be substantial enough that they cannot be completed in a single day, requiring consistent progress. 2. Plan Daily Tasks Each day, determine smaller tasks or steps that contribute to those larger goals. These tasks should be adaptable, meaning they can evolve based on progress or changing priorities. 3. Monitor Your Process Pay attention to whether sticking to a fixed schedule (working on the same task at the same time daily) or adapting your workflow dynamically works better for you. Evaluate if adjustments improve productivity and align with the Agile principle of responding to change over following a rigid plan. The goal of this challenge was to instill habits of flexibility and iterative progress, mimicking Agile's core values while fostering personal and professional growth. Stay Connected: Join the Develpreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Agile Principles Summary – Our Next Steps Patterns For Agile – Templates for Success Scrum Ceremonies – Running An Effective Sprint VIDEO: Coaching Tips to Stop Teams Equating Points to Hours Building Better Habits Videos – With Bonus Content

What does it take to be an effective Scrum Master? In this episode, Brian Milner and Gary K. Evans, author of The Effective Scrum Master, explore the nuanced role of Scrum Masters, the importance of people skills, and the shift from efficiency to effectiveness. Overview Join Brian Milner as he chats with Agile coach and author Gary K. Evans about the essential qualities of an effective Scrum Master. From fostering self-organizing teams to balancing proactive leadership with people-centered strategies, this conversation unpacks the skills and mindsets needed to thrive in the role. Whether you’re new to Scrum or a seasoned pro, this episode offers fresh perspectives and practical advice for taking your Agile expertise to the next level. References and resources mentioned in the show: Gary K. Evans The Effective Scrum Master: Advancing Your Craft by Gary K Evans Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Certified ScrumMaster® Training and Scrum Certification 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 podcast@mountaingoatsoftware.com 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. Gary K. Evans is a seasoned Agile Coach and author of The Effective Scrum Master, with over 30 years of experience transforming Fortune 100 and 500 companies through Lean-Agile practices. Known for his expertise in building high-performing teams and training over 15,000 professionals, Gary brings a unique focus on people-centered solutions to complex organizational challenges. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are back and it's another episode of the Agile Mentors podcast. We're getting towards the end of the year. I am here with you, as always, Brian Milner. And today I have a very special guest with me, Mr. Gary K. Evans is with us. Welcome in, Gary. Gary (00:17) Thank you, Brian. It's great to be here. Brian (00:19) Very glad to have Gary with us. Gary is an agile coach. He's a lean consultant. He owns his own company called Evanetics, but he is also the author of a newly published book that came out this summer. It's called The Effective Scrum Master. And it really is a comprehensive guide. It's a really interesting read. So I thought we'd have him on to talk to us about. what that means, an effective scrum master. So scrum master is this episode, I think it's gonna be really a special one for you. So Gary, let's start with that question. When you say an effective scrum master, what is an effective scrum master? Gary (00:56) In my experience, I've worked with a lot of Scrum Masters who go through the motions, they understand the events, they focus on how to run these Scrum events. But the teams flounder and they struggle with what should I do next? How do I anticipate things? And the Scrum Masters themselves often get very frustrated. One of the complaints that I hear, especially from early to mid-career Scrum Masters is I have this anxiety. How do I know that my team is operating as efficient, as efficiently and effectively as they can because they focus so much on efficiency. So this idea of effectiveness really is much more important. In fact, John Kern, one of the co-authors of the Agile Manifesto, who wrote the foreword for my book, he focused in on that word effective because we spend so much of our energies trying to be efficient. that we aren't accomplishing what we need to do, which is to build self-organizing, mature teams. And that's really the focus of my book. Brian (02:01) That's an awesome distinction, I think, because I like that a lot. There's a conversation that I will have sometimes in class about how that drive or search for trying to be not effective, sorry, what was the other word that you used? Efficient, sorry, sorry, just slipped my mind, ADHD. But the efficient kind of quotient there I think is... Gary (02:18) Efficient. Brian (02:27) something that in business in the business world today is a highly visible term. It's something that everyone seems to think is needed. But, you know, that really dates back to sort of the assembly line and efficiency experts that would stand behind you with a stop clock and try to get you to do something, you know, point two seconds faster so that it would total up to, you know, more productivity over the course of the day. But that's not the kind of work we do. Gary (02:56) I love the fact that you've mentioned that that was really the Frederick Winslow Taylor scientific management approach. And it was very much based on this idea of efficiency. But I have seen so many teams and as an agile coach, I've had multiple experiences of teams that are very, very efficient at going in the wrong direction entirely. They've lost their focus on true north. They don't understand what it is they're actually supposed to do. They think that the Scrum Guide, 14 pages in the Scrum Guide, is their Bible. And that's all that they need to know. And nothing could be further from the truth. Brian (03:37) Yeah. Yeah. And to me that, you're talking about efficiency versus effectiveness. You know, if we were a company that was trying to create a new drug to cure some disease, you know, I want effective. I don't want efficient. I don't want someone, I don't want to produce a million pills that don't work. I want to produce, you I'd rather produce one that works, you know. Gary (03:59) Exactly. Brian (04:05) And that seems to be kind of something that I think a lot of teams are missing today. Gary (04:09) It does indeed. Brian (04:10) Well, good. I like that distinction. I think that's a good distinction and that's a good place for us to start to think about this role as being kind of more effective. I think that they're sort of, I don't know, I'm kind of curious what your take is on this. Is it a marketing problem? Is it an education problem? Why is there so much confusion, I think, about what a scrum master, what a good scrum master is? Gary (04:41) That's a really deep and broad question. Part of it is that in the beginning, when Scrum was introduced into the community and was just beginning to become known, there were two attributes of Scrum Masters that were repeated again and again and again. That was you became a servant leader for the team and you removed impediments. Brian (04:44) Just a light casual one here. Gary (05:09) Unfortunately, most people stopped at that point. And they didn't realize that this, the Scrum Master role, and I'll admit, I take a very expansive view of the Scrum Master role because I've been doing this since 1993, basically, 1994. And I've learned through making lots and lots of mistakes. And the idea that All we have to do is be a servant. Well, what does that mean to be a servant leader? Nobody ever really defined it. I actually wrote an essay a number of years ago on what it meant to not be a servant leader so that I could understand by contradiction what it was that I should be doing. I called it the top 10 scrum master crimes. And really, a lot of them really had to do with crimes because it's very easy for a scrum master to start to merge into making decisions for the team that the scrum master should not be making. Now, there are times when a scrum master should direct the team, should make decisions for the team if the team is not qualified to make certain decisions because they're just too new. But this idea of being a certain leader There's so much more to that. In my expansive view of the Scrum Master role, it is not a process role first. It's a people role. And to be an effective Scrum Master, you have to be an effective people person. I've worked with so many teams and coached Scrum Masters. Scrum Masters just did not like people. They weren't people persons. And the teams responded accordingly. So. A lot of the coaching that I do with my Scrum Masters is you've got to reach deep. You've got to be able to get into people's lives rather than hold them off, you know. And so a lot of it has to do with that. Brian (07:10) I love that. I wholeheartedly concur with that. I've talked on this podcast a little bit about how it seems like we've lost the focus of that first line of the Agile Manifesto, individuals and interactions over process and tools. And I mentioned when I go to Agile conferences sometimes, I feel like the majority of the talks that I see and hear are process and tools talks rather than know, individuals and interactions talks. And I can't agree more. I think that's really a focus for us as Scrum Masters is the individuals and interactions portion, the people portion. You know, our teams are made up of people and if we're not good with helping understand how people work together, we're kind of really missing the value of what it is we deliver to the teams, I think. Gary (08:04) And Brian, the people are all different. And to have a one size fits all because the scrum guy says do X, and Z. Well, that'll work for some people, but it will not work for others. And it may even build resentment within the team because they feel that they're being treated unfairly. The focus, the theme of my book and the reason I wrote the book. Brian (08:06) Right, exactly. Gary (08:30) is that I had seen so many teams that were floundering under Scrum Masters who really didn't understand their own role. And I came up from my experience, I defined four different categories that helped to elaborate what the Scrum Master should be if they want to be effective. And I labeled those as Sherpa, Shepherd, Sheepdog, and Diagnostician. I couldn't really think of a word. I started with an S for diagnosticians. But I have a strong medical background, so diagnostician really helped because the sherpa is the expert. And to be an effective scrum master, you have to be an expert, not at scrum, but at agile. We really want, I want my scrum masters to be agile masters. And as a coach, I'm constantly pushing them. How are you improving your craft? And what is involved in that craft? So you've got to be an expert. Brian (08:58) Hahaha. Gary (09:26) Now for a new scrum master, that's a contradiction in terms. You can't be an expert if you are just at the beginning of the journey. But there are things that you can do. And I discussed this. In order to from exposure, you can gain experience. And from experience, you can generate expertise. And so that's the first one. If ultimately you need to be a master of Agile. Secondly, a Sherpa and then a... a Sherpa and then a Shepherd, you have to be able to guide the team. And you can't guide somebody if you haven't been through that path before. So this is where the issue of longevity, education, and just exposure and experience with different teams on different projects. This is where the maturity comes and you start to develop a depth of understanding. But then there's the hardest part, the hardest persona of the scrum master is the sheepdog. This is where you are the protector of the team. And so many scrum masters fold in this area because a threat will come either from management or from within the team or somebody outside the team like a product owner. And the scrum master doesn't understand how to protect his or her own team. I'll share a little war story with you that is in the book. I had a product owner who one morning came in and just started ripping through several of my team members. I don't know what happened at that point. I stepped between him and the team and I said, do not take another step forward. I was ready to defend my team physically. It didn't come to that. And later I learned the reason for why he was so upset. But if you're going to be a sheepdog and protect your team, it may require personal sacrifice. It may require professional sacrifice. And this is the area where so many scrum masters, they can't deal with that part because they don't have that confidence. So you've got the Sherpa who's the expert, the shepherd who is the guide. The sheepdog who's the protector and finally the diagnostician who is the healer. Things are going to go awry and you have to have a way of diagnosing what the root cause of the problem is. And this is where the issue of metrics and understanding your team members, building a rapport with your team members that quite often is extremely intimate. I have had team members, I have a series of questions I ask all my team members so that I understand their background and such and also things that I need to be aware of. And I will ask them, do you have any medical issues or other accommodations that we might need to consider for you? This is an issue of respect so that we don't put somebody in an uncomfortable situation. It's a strictly private conversation. I've had people share with me that they have a drug problem. that they're caring for an ailing parent, that they're going through a divorce, all kinds of different issues that come out. And we work out special signals so that if they're having an episode someday, they just give me that signal. And I know that I need to either give them space or give them some special consideration. This is what I mean by the people issue. You've got to get to the point where you allow people's lives to splash onto you and you get wet with their issues. And yet you still have to maintain your autonomy and separation in order to work with the whole team together. The Scrum Master role is extremely complex from my perspective because it involves people, as you say, individuals and their interactions. That's where we have to start. Brian (13:33) I agree. And that's a great call out to say, to talk about there, just the idea that, you these are, these are individuals, not, they're not robots, you know, like they're not AIs yet. These are human beings and they have lives outside of work. They have things that affect them. And if they're going through a divorce, like you said, then you think that might affect their work life? Well, of course it will. Cause they're a human, right? And that's gonna... Gary (13:43) Right. Yes. Brian (13:57) that's going to affect their, their mood that day. That's going to affect, you know, how productive they are. It's going to affect lots of things. And, and, you know, we, we've talked here on the podcast a little bit about making accommodations for people with different, neurodivergent traits like ADHD or, autism or other things like that. And, know, I've always loved the idea of, know, putting people in the best position to be successful, you know, trying to understand what is. unique about them, strengths and weaknesses, so that you can help them to be put in a position that they can shine, right? They can really contribute in their own unique way. And we have to allow for both those strengths and weaknesses. We have to help them with the weaknesses. We have to put them in a position to share their strengths. Gary (14:49) And this leads to a slightly different topic if I can move up a little bit. The scrum master role is an endangered species right now. And there's a reason for that. There's several reasons for that. One of which is what we've been talking about. So many scrum masters are not people persons. And as a result, the teams are not accomplishing what the organization needs. And therefore the scrum master is regarded as overhead. Brian (14:52) Yeah, please, please, please. Hmm, yeah. Gary (15:19) as ineffective. And frankly, that's correct. There are currently, if you look at the Scrum Alliance and Scrum.org, I got the figures from these companies as of the beginning of this year, there are about two million Scrum Masters in the world right They're not all equally effective, Many of them are PSN1s from Scrum.org and there are like 625,000 of those, that type of thing. And then you get 39,000 PSN2s and then you get a thousand or so PSN3s. You can see the drop off there, just huge drop off. And the certification issues lead people to think that they're a Scrum master. Scrum two days or? An online examination doesn't prepare you. It simply doesn't. We've not done a good job of helping people understand through these major certification roles. that this is a starting point, but it's not going to make you effective. And part of it is it's become commoditized. And so we have this issue of lots and lots of scrummasters, most of whom really are not people persons and most of whom don't understand how to deal with a team and build a team rather than just an assembly of individuals. I've taken over teams that have been floundering. I've done this multiple times. And on day one, it's a series of isolated individuals. That's the best that they could have. Because there was no cohesion that could be found. And that always takes me a lot of effort and a lot of time to figure out how can I find cohesion within the team. So it's exhausting. The Scrum Master rule is really exhausting at times. And if someone's not tired at the end of the day, they're not doing it right. Brian (17:22) Yeah, I really am in alignment with what you're saying here. And I've thought about this issue a lot as well, and just the idea that we seem to find ourselves in a situation where, as you said, there's a lot of people who have that certification. And as someone who gives people certifications, I have to take my own part in that. I have to accept my own role and what that plays in it. But I think that you're right to... The training is necessary, right? You have to understand the basics. You have to understand these things before you can do anything else. However, I think that the disservice that the industry has done is to make this proclamation that if someone is certified, that they are ready to lead. And that really is what a Scrum Master is, is a leader in the organization. They're a leader for the Scrum process in the organization. And that's just... Gary (17:55) Yes. Yes. Brian (18:23) not true, right? It just takes more ongoing mentoring and coaching for that person to get to a place where they are really a, you know, what we would call a change agent, right? They are there to, you I always like to use the term infect the organization. They're there to spread and infect this mindset, this philosophy. And if we don't understand it ourselves, if we're not really living that philosophy, If we want our team to be experimentation based and we don't experiment ourself and we don't kind of demonstrate to them what it looks like to experiment, to try things, to fail, to figure out why that didn't work and then apply a new change and say, let's try something different. If we don't demonstrate that, not just tell them, but demonstrate it, they're never going to get that. They're going to stay, as you said, a collection of individuals. And I think that's, to me, that seems to be one of the big issues today with Scrum Masters and with Scrum in general is just that we have, you know, in opposition to your book, ineffective Scrum Masters that aren't really helping people see what Scrum should be. Gary (19:41) Exactly. And you've touched on what I call the four E's, which are exposure, experience, expertise, all built through experimentation. And you use that word to experiment. We need to experiment. But experimentation takes courage. Now that is one of the Scrum values. But when you get a young person or a new Scrum master who's in a role in an organization that may have certain, let's say, unsafe environment and cultural factors. It's very difficult for most people to build that courage to say, we've got to change this and become agents of change. Now, obviously they can, they should be diplomatic. They should be respectful, but they should also be persistent. But being able to see that requires a vision. You have to be able to be able to look around and see where are the big problems that we have? Why should I rearrange the deck chairs on the Titanic if the ship is sinking? Brian (20:41) you Gary (20:45) And so having that vision, again, comes from maturity. And the Scrum Masters that I work with, I push them pretty hard because I want them to grow. And every one of them has thanked me. But they didn't thank me during while it was happening. Brian (21:06) Ha Yeah. Yeah, I can understand that. mean, we, you know, one of the analogies I'll use there is like, we, a lot of us that have gone through the process and become a trainer will say it was hell while we went through it, but we look back on it and think that was necessary. We needed to go through that. now that we've gone through it we're on the other side, that was a necessary component of becoming an effective trainer was really seeing it up close and personal and seeing how other people do it. So I completely get that. Gary (21:31) Exactly. Brian (21:36) I want to ask you a question here that I know this is a loaded question. I get this question all the time. But I thought it might be interesting to hear your perspective on this from the effective Scrum Master perspective. People constantly ask, well, what does a Scrum Master do all day? Because when you look at the Scrum Guide and you look at the things that we have as responsibilities, You know, the two main responsibilities we have that are ongoing is to make sure events happen and make sure that the time boxes are kept according to the Scrum Guide. But I try to tell people there's a lot that goes on between those events. It's not just about the events, right? There's a lot that we do. just help our audience. For those people who are listening and don't really have a clear picture of what a Scrum Master does, just give us some samples of what you see as activity that effective Scrum Masters would take on a regular basis. Gary (22:30) What an interesting qualitative question. Brian (22:33) Ha ha ha. Gary (22:34) And I say qualitative on purpose. What does a scrum master do? What a scrum master should do is listen, listen a lot, observe, even if you're remote and virtual. You should be monitoring the Slack channel. You should be having video sessions. You should be attending team discussions whenever you can, but not only to listen, but to be the last one to speak. This is a big issue. So a scrum master often is considered to be doing nothing. But what the scrum master is doing is listening, watching, being the last to speak so that he or she does not taint the conversation among the team members. And it's very easy for that to happen. They should be compiling. team metrics. And I have a very lengthy section in the book on metrics, not only velocity and burn down charts and that type of thing, but a number of other other metrics that I've developed over the years for my own teams. So that the Scrum Master and the team can understand their own performance. They should be training, obviously, as a Sherpa, as an expert. They should be conveying knowledge to the team and they should be teaching every time they're talking to somebody, they should be teaching someone. So it's not a prescribed set of activities in my estimation of what a scrum master does. And I'm going to I'm going to use an analogy here. And it's going to it's going to offend some people because they're going to say, that's a terrible analogy. Well, it's actually a good analogy if you take it as that. The scrum master is like a parent. and needs to nurture the family. How does a parent, what does a parent do? They listen, they observe, they teach, they guide. Sometimes they have to protect, sometimes they have to discipline. And these are all skills that make for a good effective scrum master. So as I say, it's a qualitative issue. But a person who cannot parent well, I'm not saying the team are children, I'm saying they're your family. You need to parent your family. And you need to, as an experienced person who hopefully has a bit more experience and exposure and wisdom. and has better insight into how the world works, even the world of the organization, the Scrum Master has to be able to convey that on a day-to-day, hour-to-hour basis. It is not a part-time job. It is a full-time, exhausting, boots-on-the-ground position that many people just cannot fill. It's sad, but not everybody can do everything. Coming back to the certifications again, job ads always want to know you need to have a CSM or a PSM. You need to have an ACSM, type of thing, advanced certified Scrum Master. These are proxies that companies use because they don't know what a Scrum Master does. They don't know how to qualify it. So they try to quantify it through a certification. And what they have are two million Scrum Masters. who are certified in the world. How many of those are really good? Not all of Brian (26:06) Right. Gary (26:07) So the reason that I dwell on this a little bit, Brian, is my book is there to help people understand. not only the limits, but the expanse of what they should do. And there are limits to what a scrum master should do, but there's also an expansive view of they need to do more than just be a servant leader and remove impediments. Those are important. That's not the end of it. Brian (26:33) I agree. It's kind of interesting because it's a delicate balance, right? Because it's sort of like, you know, there's not a recipe. There's not a clear, hey, here's the 10 things that you do every day. And just when you come in the morning, check this list off and do these things, right? There's not that. But I think that the other mistake that I see some Scrum Masters make sometimes is that they treat it as being a purely reactive kind of position where I'm going to sit back and wait for things. And then when something happens, then I'll, then I'll jump in and I'll do something based on what someone else has done, which I think is a mistake as well. We we're proactive. We were very proactive to, to make an impact and make a difference. And when we recognize something's needed, we, got to jump in there. We got to get in there and do something about it when it's needed. you wouldn't want to have a coach of a team who set back and just, you know, Gary (27:26) It is. Brian (27:30) waited for someone to come to them and ask them for questions. There's no strategy. There's no paying attention to fundamentals. All those things would kind of go out the window if that coach isn't more proactive with his approach towards his or her approach toward the team. Gary (27:45) Exactly. That's a wonderful analogy because I was a soccer coach as well. I'm a soccer player as well. And when I'm coaching youth or that type of thing, I have to teach them how to use this sideline, the touch line in order as a virtual defender. need to have been on the field to know how to teach them how to operate on the field. And if I can't get involved with them, if I just wait until they make a mistake, they're going to make a lot of mistakes. Brian (27:48) Hmm. Gary (28:14) And you've touched on this idea of the passive scrum master. Scrum master is not a passive role. I had a product owner, one of the best that I've ever worked with in my career. We were having a very heated conversation one day, as we often did. And he said, Evans, you're an activist scrum master. And I had never heard that before. And I reflected on it a little bit and I said, Chuck, you're right, I am. But not everybody has that kind of personality. So each scrimmaster has to identify where they may need to improve, maybe some of their assertiveness, some others need to learn how to hold back. It's a learning curve. It's a learning 24-hour-a-day learning session. We're all different. teams are different, the Scrum Masters are different. And as we get more experience and develop more expertise, we handle things differently as a result of that growth. And my role as a coach is to grow the Scrum Masters, to grow the teams. And I've loved it because I love working with people. So you get to work with people, you get to solve problems and you get to see tangible results in people's careers. What more could you ask? Brian (29:36) Right, right. I'm with you. I'm right there with you. I can't agree more. Well, this has been a great discussion. just want to, you know, we mentioned already your book is called The Effective Scrum Master. We're to put links in our show notes to that if people want to go and find that and just, but you can find it on Amazon. Gary K. Evans, The Effective Scrum Master. Gary, how can people find out if they want to get in touch with you or find out more about your work, how can they get in touch with Gary (29:37) Thank Well, appreciate that. I am currently putting up, there is a, we have a website. It's called effectivescrummaster.com. I'll repeat that. Effectivescrummaster.com. There's a sign up link there. It's the page is just under construction at this point. It's live, but people can go up and they can enter an email to be notified when we start to make changes. There'll be some free information there, some resources that they can download. We've got a plan on how we're going to roll this out, but that's just beginning. And so I hope that people will go and visit that and hopefully we'll be able to develop a relationship and they'll be able to reach out to me through that website. Again, effectivescrummaster.com. Brian (30:51) Awesome. Well, thank you so much, Gary, for making the time. It's been a really great conversation and I really appreciate you making the time to come on the show. Gary (30:59) Brian, this has been my privilege and I really appreciate it. Thank you so much.

In this episode of Book Overflow, Carter and Nathan discuss The Agile Manifesto, a free-to-read document that has greatly defined the modern software engineering landscape. Join them as they discuss its legacy, how it persists in software engineering today, and whether it was ultimately a good or bad development! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- The Agile Manifesto https://agilemanifesto.org/ ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

Melissa Perri is the founder of Product Institute, author of Escaping the Build Trap, and host of the Product Thinking Podcast. She has worked with startups, Fortune 50 companies, and everything in between to help them build better products and level up their product teams. In our conversation, we discuss:• The history of the product owner role• The differences between product owners and product managers• How to transition from product owner to product manager• The evolution of and problems with the SAFe framework• How large non-tech companies can improve their product practices• Much more—Brought to you by:• Pendo—The only all-in-one product experience platform for any type of application• OneSchema—Import CSV data 10x faster• Coda—The all-in-one collaborative workspace—Find the transcript at: https://www.lennysnewsletter.com/p/product-owners-melissa-perri—Where to find Melissa Perri:• X: https://twitter.com/lissijean• LinkedIn: https://www.linkedin.com/in/melissajeanperri/• Website: https://melissaperri.com/• Product Institute: https://productinstitute.com/• Podcast: https://www.produxlabs.com/product-thinking—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Melissa's background(02:12) The rise of the product owner role(06:37) Understanding Agile and Scrum(08:27) Challenges in Agile transformations(10:41) The history of the product owner role(13:58) The Scrum Guide(15:43) Product owner responsibilities(21:01) Adopting Scrum in organizations(26:21) The origins and implementation of SAFe(35:20) Why Melissa doesn't recommend SAFe(40:33) Advice for implementing a digital transformation(49:12) An example of SAFe adoption(51:27) The value of experienced product leaders(56:53) Career paths for product owners(01:04:14) Transitioning from product owner to product manager(01:06:41) Be careful relying on certifications(01:11:43) Evaluating existing product owners(01:16:55) Final thoughts on Agile and product management—Referenced:• Escaping the Build Trap: How Effective Product Management Creates Real Value: https://www.amazon.com/Escaping-Build-Trap-Effective-Management/dp/149197379X• Lean UX: https://leanuxnyc.co/• Scrum: https://www.scrum.org/• What is Extreme Programming? https://www.agilealliance.org/glossary/xp/• Capital One: https://www.capitalone.com/• The Agile Manifesto: https://www.atlassian.com/agile/manifesto• Ken Schwaber on X: https://x.com/kschwaber• Jeff Sutherland on X: https://x.com/jeffsutherland• Kanban: https://www.atlassian.com/agile/kanban• What is a kanban board?: https://www.atlassian.com/agile/kanban/boards• Ron Jeffries's website: https://www.ronjeffries.com/• Jeff Patton on X: https://x.com/jeffpatton• The Scrum Guide: https://www.scrum.org/resources/scrum-guide• OpenSky: https://www.openskycc.com/• SAFe: https://scaledagileframework.com/• Dean Leffingwell on LinkedIn: https://www.linkedin.com/in/deanleffingwell/• Capital One scraps 1,100 tech positions: https://www.reuters.com/technology/capital-one-scraps-1100-tech-positions-source-2023-01-19/• Product management theater | Marty Cagan (Silicon Valley Product Group): https://www.lennysnewsletter.com/p/product-management-theater-marty• Marty Cagan on LinkedIn: https://www.linkedin.com/in/cagan/• Jeff Gothelf on X: https://x.com/jboogie• Shruti Patel on LinkedIn: https://www.linkedin.com/in/shruti-patel-32bb573a/• Product Thinking Podcast: Mastering Product Focus: Balancing Legacy and Innovation with Shruti Patel: https://www.produxlabs.com/product-thinking-blog/2024/9/25/episode-190-mastering-product-focus-balancing-legacy-and-innovation-with-shruti-patel• Melissa Douros on LinkedIn: https://www.linkedin.com/in/melissadouros/• Mind the Product: https://www.mindtheproduct.com/• Athenahealth: https://www.athenahealth.com/• McKinsey: https://www.mckinsey.com/—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

Edward Hieatt (@edwardhieatt, Chief Customer Officer @mech_orchard) talks about app modernization and the advancements and developments to increase progress.SHOW: 867Want to go to All Things Open in Raleigh for FREE? (Oct 27th-29th)We are offering 5 Free passes, first come, first serve for the Cloudcast CommunityRegistration Link - www.eventbrite.com/e/916649672847/?discount=Cloudcastfree  Instructions:Click reg linkClick “Get Tickets”Choose ticket optionProceed with registration (discount will automatically be applied, cost will be $0)SHOW TRANSCRIPT: The Cloudcast #867 TranscriptSHOW VIDEO: https://youtube.com/@TheCloudcastNET CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT OUR OTHER PODCAST - "CLOUDCAST BASICS" SHOW NOTES:Mechanical Orchard (homepage)Startup led by ex-Pivotal CEO lands $50M to modernize apps (TechCrunch)Topic 1 - Welcome to the show. Tell us about your background, and then give us a little bit of background on Mechanical Orchard.Topic 2 - Many of the MO team come from Pivotal (especially Pivotal Labs), as well as being involved with the Agile Manifesto, Extreme Programming, etc. How did the mission of the company get focus on modernizing existing applications?Topic 3 - Modernization projects have traditionally been really costly, with a low success rate. Why is now the right time to focus on this area?Topic 4 - I'm really interested in how MO technology works. It seems like a variation of a digital twin, mixed with some AI capabilities. Give us the big picture of how this is a different approach to modernization.Topic 5 - How much culture/process change is needed with MO to be successful? Topic 6 - What do the stages of success look like with your approach to application modernization?FEEDBACK?Email: show at the cloudcast dot netTwitter: @cloudcastpodInstagram: @cloudcastpodTikTok: @cloudcastpod

How Relevant Are The Agile Principles Today? 2001 is the official birth year of Agile. It took the world by storm. Millions of professionals have found new ways of creating software (and other products) using the values and principles of the Manifesto for Agile Software Development (or Agile Manifesto). At the height of Agile, people saw it as a panacea for all software-related, even all product-related problems. Nowadays, Agile is a commodity. “Everyone” works Agile these days. Some proclaim we are in the post-Agile era. Others say Agile is Dead. Is Agile Really Dead? How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

You can contact Al here: https://www.linkedin.com/in/alshalloway Al on the PMI: https://community.pmi.org/profile/alshaloway#_=_ Al and his company explains Amplio: https://successengineering.works/author/al-shallowayoutlook-com/ Al’s books on Amazon: https://www.amazon.com/stores/author/B001IXPWYW The post 281 Al Shalloway and why he didn't Sign the Agile Manifesto first appeared on Agile Noir.

Jeff is the co-creator of Scrum and a leading expert on how the framework has evolved to meet the needs of today's business. The framework he developed in 1993 and formalized in 1995 with Ken Schwaber has since been adopted by the vast majority of software development companies around the world. However, Jeff realized that the benefits of Scrum are not limited to software and product development. He has adapted this successful strategy for several other industries, including finance, healthcare, higher education, and telecom.   As the CEO of Scrum Inc., Jeff sets the vision for success with Scrum. He continues to share best practices with organizations around the globe and has written extensively on Scrum rules and methods. With a deep understanding of business processes — gleaned from years as CTO/CEO of eleven different software companies — Jeff is able to describe the high-level organizational benefits of Scrum and what it takes to create hyperproductive teams.   Topics of Discussion: [:35] Introduction of Jeff Sutherland, co-creator of Scrum. [3:47] Jeff Sutherland's background: His experience at West Point and lessons in making work visible. [5:19] Fighter pilot experiences that influenced the operational side of Scrum. [6:02] Transition to the Air Force Academy and work in AI at Stanford. [7:38] Learning complex adaptive systems and the origin of Agile from complex systems theory. [8:30] How complex systems theory impacts Scrum and Agile teams today. [9:25] Jeff's first experiences applying Scrum in the banking industry. [11:25] The development of Scrum and the 2001 Agile Manifesto. [12:57] Making work visible and organizing teams, from West Point to Toyota to the Agile Manifesto. [13:23] Fast forward to 2024: Issues in Scrum and Agile practices, including sprint lengths and backlog grooming. [14:34] Jeff's new book: First Principles in Scrum and its relation to Scrum technology stacks. [16:23] Building autonomous systems: Lessons from radiation physics, AI, and complex adaptive systems. [19:16] The influence of autonomous robots on the creation of Scrum. [21:14] Discussion of Scrum and AI, leading to “Extreme Agile.” [22:47] Predictions for the future of Scrum and Agile: Teams becoming 30 to 100 times faster by 2030. [23:37] Example of AI in action: Developing a system to handle expense reports using Scrum principles. [29:37] Challenges with AI-generated code and the need for strong software architecture knowledge. [33:24] The importance of following Scrum “by the book” to achieve hyperproductivity. [35:30] Jeff's closing advice on adapting to extreme agile to stay competitive by 2030.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! How the Agile Manifesto Came To Be   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Join us for Agile coaching for the PMP Exam at: http://agileaficionado.com Join us for an engaging and insightful webinar that brings the Agile Manifesto principles to life in a fresh and creative way. Through vibrant comic-style illustrations, we'll explore how Agile's core values and principles can transform your team's approach to delivering exceptional results. In this session, we'll dive deep into each Agile principle, using humor and dynamic visuals to showcase the practical application of Agile in real-world scenarios. From the importance of face-to-face communication to the art of simplicity, you'll gain valuable insights that will help you foster collaboration, improve efficiency, and enhance team motivation. The Agile values that drive successful teams. How principles like "Working Software is the Primary Measure of Progress" and "Continuous Attention to Technical Excellence" can boost your team's productivity. Why simplicity and self-organizing teams are key to Agile success. Practical tips on implementing Agile in your projects. Whether you're a project manager, developer, or Agile enthusiast, this webinar is perfect for anyone looking to enhance their understanding of Agile principles in a fun, visually engaging way. Don't miss out on this opportunity to see Agile like never before and leave with actionable strategies to improve your team's workflow! --- Support this podcast: https://podcasters.spotify.com/pod/show/pmpradio/support

AGILE Manifesto Explained http://pmanonymous.com for Project Management Coaching and Training --- Support this podcast: https://podcasters.spotify.com/pod/show/projectmanagement/support

Kent Beck is an original signer of the Agile Manifesto, author of the Extreme Programming book series, rediscoverer of Test-Driven Development, and an inspiring Keynote Speaker. I read his TDD book 20 years ago.   Topics of Discussion: [3:46] What led Kent to extreme programming? [7:52] What critical practices have stood the test of time? [10:58] The role of software design in Agile Development. [13:11] The inspiration behind Tidy First? [16:16] Why software design is both a critical skill and an exercise in human relationships. [22:05] What is “normalizing symmetry”? [25:04] Empirical design. [28:09] Design changes tend to be reversible. [30:41] Experimentation with the GPT phase of AI on publications. [35:13] Advice for young developers and programmers.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! KentBeck.com Tidy First? Test-Driven Development Extreme Programming Explained Implementation Patterns   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Is Agile really dead, or are we just doing it wrong? Tune in as Brian and Scott dive deep into the controversies and misconceptions surrounding Agile practices and what it really takes to make Agile work in today’s organizations. Overview In this episode, Brian and Agile Mentors Podcast regular, Scott Dunn, tackle the provocative question: "Is Agile Dead?" sparked by recent claims of Agile's high failure rates. They discuss the validity of these claims, the common pitfalls of bad Agile implementations, and the importance of continuous improvement and experimentation in Agile practices. The conversation explores the shortcomings of current training approaches, the crucial role of effective coaching and leadership support, and how to overcome the widespread misconceptions about Agile. Brian and Scott emphasize the need to focus on outcomes and ongoing learning rather than getting bogged down by methodology debates and rigid terminologies. References and resources mentioned in the show: Scott Dunn #93: The Rise of Human Skills and Agile Acumen with Evan Leybourn Are Agile and Scrum Dead? By Mike Cohn Join the Agile Mentors Community 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 podcast@mountaingoatsoftware.com 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. Welcome back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today, friend of the show, regular, you know him, you love him, Mr. Scott Dunn is with us. Welcome back, Scott. Scott (00:13) That's my new favorite intro ever. So thank you, Brian. Always glad to be and then glad to talk shop. So I appreciate you making me some space so that I get to work with you again. Brian (00:16) Ha ha ha. Yeah, we need like walkout music for you. know, like when the pitcher comes out to the mound, the relief pitcher or the wrestler comes out, you know, or whatever, they play the walkout music. We need walkout music. We wanted to have Scott back because there's a hot topic and this is your hot take alert because this show I'm sure is gonna be full of personal hot takes here on the subject. Scott (00:30) Yeah yeah, there you go. Brian (00:50) And that is, is Agile dead? There has been a lot of talk recently about this in the past few months. There's been a lot of blog posts written, a lot of armchair quarterbacks chiming in and trying to make sense of this. So before we dive in, Scott, I want to give a little bit of background to our listeners in case you're not aware of something that happened, where this came from, right? Because I think that there was In one sense, there's always an undercurrent. There's always people out there who are ready to say Agile's dead, right? And so they're waiting to pounce on anything that would back them up. And there was someone who was very happy to oblige about that. There was a company called Engprax, E -N -G -P -R -A -X. I couldn't find much out about them except they're a consulting company. And they put out an article that was announcing research they had done that said that 260 % higher failure rates for Agile software projects. That's what their study revealed. Yeah, 268%. So let's just start there, right? But the article is very thinly veiled in support. of another competing process, believe it or not, called Impact Engineering that is authored with a book that's just out, believe it or not, by a gentleman named Junade Ali. Now I have no idea, I have never crossed paths with this gentleman. I don't know his philosophy or his, much more about him. I did look him up on LinkedIn. He's been in the business for about 11 years. If I trace back to his first thing, it's about 11 years ago. He currently lists himself as the chief executive officer of a stealth startup. Well, I think I can remove the mask of what that stealth startup is because it is Ingeprax. So he is the head of that company. I found another article that did the research in support of his book. Scott (03:03) Hahaha Brian (03:12) announcing his new process that is a competitor, of course, to Agile. Now, there's been a lot of back and forth. He's tried to defend this and say, you know, the research is solid, but here's the thing I always say, without data, it didn't happen. If you're not showing me the actual methodology, if you're not showing me the scientific research paper behind it that says, here's the methodology of the research, here's how we conducted it, here's the... There are some details that are in the article, one of which is that the research was done over a period of about five days. So it was research over about five days. was interviewing a set of, I'm trying to scroll through and find the numbers. I think it was like 250 or so engineers from the UK and 350 from the US. It's something around those numbers. But it was interviews with engineers over a period of about five days. Scott (03:50) Wow. Brian (04:11) And so the numbers are based on these engineers' recall of what their idea of success was in projects, whether it was an Agile project or not an Agile project, by their definition of whether it was an Agile project or not. He doesn't really describe in the article what success is. So saying that it's 268 % failure, what is a failure? It doesn't really state that plainly. So again, where's the data, right? I'm not going to go on and on about the research and the fact, but I just want to give the background before we dive into it because that article is what now you will see quite a few blog posts and things crossing your desk on LinkedIn that say, wow, look, this new study says 268 % failure rate for agile projects. Well, anytime you see something like that, check the source. You have to check the source. I try to do this in any conference talk I do. I put the links to the sources. And I try to only list data that comes from scientific studies, where you can find the actual research paper and dive into it and get into the nitty gritty of it if you really want to. Otherwise, as I said, it didn't happen. He says in the article, hey, we had PhD people that looked over our work, unnamed PhD people. So you can't even question whether that person was someone legitimate who did it. Just trust him that they were legitimate. So I set that up because I don't mean to take so much time here at start of the episode, but I just wanted to set the foundation. If you weren't aware of that kind of thing or where that came from, you may not even been aware of the background of where that study came from. Scott (05:46) You Brian (06:04) And the fact that the person who kind of sponsored it is got an ulterior motive, right? They're trying to push their own methodology and they're publishing research that they collected, they are publishing, that just so happens to support their foregone conclusion that Agile's bad and their methodology is better. So, but Scott. Scott (06:31) I'm just trying. Brian (06:32) So let's get into the topic because what I really want to get into is, I'm sure you've seen people post things like this and there's been sort of this wave of things in the past year or so of people who are so quick and anxious to say Agile is dead. So what's your general impression there? What have you seen? What have you experienced and how do you respond if someone in class says, hey, is Agile dead? Scott (06:43) Mm Mm I great, great question. So for those listening, I want to just want to affirm that probably a lot of you had experiences like, well, certainly wasn't going great or we're not seeing what we thought and all those things. So part of this, Brian, is I think the ethos of why those things take off like that is I do think there's a general feeling of is this really working for us or not? That's that's fair. So I'm not going to pretend like, it's always goes great. It's, you know, be Pollyanna about that. I remember actually this year. of a CEO, a company saying, Agile absolutely does not work. We're going to go all the way back to just full waterfall. Right. That to me is kind of that harbinger of like, wow, it's built up enough for someone to say that. So a couple of thoughts I have, and I'm going to be pragmatic like you for my friends that are hearing this or maybe thinking this or people at your company are pushing back a bit, is I'm to go back and say, well, okay, let's just say that Agile is dead. So what are you going to do? Are you really going to go back to waterfall? Well, we already know that story. whole reason, for those listening, consider this, whole reason Agile took off was the option A wasn't working and very clearly wasn't working for complex projects like software. Now for this person to come and recommend XYZ, of course, not surprising for all the listeners out there. Obviously, there's a marketplace, there's business. I get it that people are going to pitch and recommend what they do my classic one in our space Brian would be because obviously you I Mike within Mountain Goat are teaching the CSM CSPO and I'll see like 350 page books of get ready for the CSM exam like right the scrum guide itself is I mean how many pages so come on Brian (08:38) You Scott (08:47) And they'll even be like, you know, misrepresentation. So clearly people are doing things in their own self interest. get that. as you as people out there, hear information, I love what you're saying is to just like look into it and really be mindful of what's their angle for some of that. But back to your question, is Agile dead? I would argue that Agile partly done or halfway is dead in the sense that that doesn't work or what I would kind of call Agile theater. Agile hand waving, spread the agile pace. So I've been doing this 18 years, I think, since becoming a Scrum Master. And I was on project delivery before that and managing IT people. So I've seen all the things that weren't working well as a developer, et cetera. And I saw the results of what I got. And I've seen plenty of stories beyond that. But what I see more and more is people who are further away from the beginnings and what they're kind of doing is implementing what's comfortable. And I would agree that doesn't work. in that sense, that Agile is dead. In a follow on the idea of and really kind of putting together realizing is for those out there that your company is the one implementing Agile, who usually gets that? Well, it's probably going to be the PMO. And I'm going to poke a little bit here, certainly for my PMO friends, but as a former PMP working within the PMO, what's the PMO responsible for? So if I go to your typical company, say, hey, we're going to go Agile. That's under the purview of who it's a, it's a, there's going to be a group that's responsible for watching over execution delivery. Who is that? It's a PMO. Think about this. The PMO is not responsible for like learning continuous improvement innovation. They're responsible primarily for, for status reporting, managing to a given date, managing resources, escalating issues, but not necessarily for improving. So they bring in Agile sense of, what do we need to do without maybe understanding it fully and really. How do we just manage this process and not, hey, we're starting off from point A, but we're going to learn and get better as we go across. It's going to stop where they feel like, I think we have a new process that implemented. Does it get the results? You know, I don't know and I don't understand how it works to fix that. So they may not be getting results is what I commonly see. I'm seeing a slew. I can tell you the last several companies just in these last few months we've worked with. We've got to fix our process is not working. Are you agile? Yes. But you look at it and they'd miss a lot of fundamentals. And so now we're kind of resetting a lot of people that are struggling with the same issues everyone's talking about. Visibility, predictability, can we deliver this by the date we gave senior management? And they're not by and large. For those who say agile is dead, one of the other options, people have put together agile manifesto had lots of ideas, lots of other approaches besides scrum, but even if just take scrum. Look, scrum is based on lean. Is lean dead? And scrum is an empirical process. Is empiricism dead? Does that not work? So I kind of come back like, what are your options? Just think about the results you're getting. Whose fault is that? And what are we even basing what we're looking at? The roots of it are all very solid. So yeah, I'm going to push back quite a bit on that, what I've seen. And maybe see some of those same. Results or lack of results for organizations Brian because I know that it doesn't always go great out there and in the marketplace is coming. Try to roll this out. Brian (12:07) Yeah, yeah, there's a, so I have a couple thoughts here. One is just in general, I think you're absolutely right that there's, know, well, just listeners, ask yourself, what percentage of Agile practices out there do you think are doing Agile the right way? Right? And I don't mean like a hundred percent. I just mean they are, they're all in on it. They're trying to do it the right way. I don't know what number you have in your head, I would say, don't know, Scott, what would you say? Scott (12:43) They're doing it right? Brian (12:45) Yeah, they're not perfect, right? But they're committed to doing it right. They're committed to doing it according to what the Agile Manifesto says, that sort of stuff. Scott (12:55) Fairly Fairly smart, right? I'm guessing, my first number that came to mind, you asked, I'd say 10%. That's my, maybe less than that. Brian (13:02) Okay. Yeah, I would bet it's a small thing, right? Now that right there, I think is something that we can talk about. Why is it that small? Right? Why is it that small? And I think that there's a discussion that's a legitimate discussion to be had about, well, maybe the structure that was put in place to spread this and train people up and get them, you know, situated to do this well. has failed. And if that's the case, that's the problem. It's not really that the methodology is bad. It's that we didn't do a good job of explaining it or training people for it. that's a separate discussion. But I think that there's a lot of bad agile out there. And I'll just put it to you this way. If you like to hike or camp or anything like that. If you are an aficionado of that stuff, right? If you occasionally go hiking or camping, I'm fairly certain that you've had some hikes or some camping trips that weren't that great, right? And you can probably recall them and think, wow, that was horrible. Well, imagine if that was your only experience, right? Imagine if that hike or that camping trip was your only experience. And you came back from that and someone said, you tried hiking or you tried camping. What did you think of hiking or camping? That sucked, it was horrible. I never wanna do that again. I don't know why these people are crazy, that do that stuff. I would never do that again. But if you really like it, you know that yeah, there could be some bad experiences, but there's some good experiences too. And if you plan a really nice hike and you've got good weather and everything else, it can be a really great experience. So to base someone's opinion on, well, my experience in one place was that it was terrible. Well, okay, come on, give it another shot, right? I mean, they're not all gonna be perfect. And if you see it in a couple of places, you'll probably understand, now I know what we were doing wrong in that other place because it's clear now, right? So that's one point here. And the other thing I wanted to say is one of the things that they talk about in their Scott (15:17) Right. Brian (15:26) 268 % failure rate article where they announced their research, is they focus a lot on that their methodology does a better job with really clearly documenting requirements before development starts. So Scott already knows where I'm going with this, right? I think there's a fundamental misunderstanding before we even begin this, because what they're saying is, Scott (15:42) boy. Brian (15:55) Yeah, one of the things Agile fails at is clearly documenting all the requirements up front. And my response as an Agile trainer is, duh. Yeah, of course, because we don't try to do that. We actually look at that from a different standpoint and say, you're fooling yourself that you can document all the requirements up front. The example I use in class is, well, We're not manufacturing, right? We don't do manufacturing work. We're not churning out the same thing over and over again. If I was doing that, I could document all the requirements upfront, because I've done it before and I know what it takes to do it. We're closer to research and development. So let me take an extreme research and development situation for you. Imagine I'm inventing the cure to a certain kind of cancer, right? And you come to me before that and say, great. Well, we funded the project to cure that certain kind of cancer. Here's the budget. you know, let's get all the requirements documented upfront before you start inventing that cure to cancer. You'd look at me, I'd look at you like you were crazy because I don't know what all the requirements are going to be before I invent this new way of solving the cancer problem, right? I have to experiment. have to try, I have leads, I have ideas about things I would try and that I think have promise, but I've got to go through trials. I've got to go through tests. And the results of those experiments will then guide where I go next. So I think there's a fundamental fallacy in just the idea of trying to judge whether Agile is successful or not about whether it can capture requirements. Scott (17:34) Yeah, right. And for those who've been around, I'm going to double down on that one, Brian, because I've seen this pushback to, hey, we've got to capture all the requirements up front. But every time I ask a company, things change. company priorities change all the time. If anything, we're suffering from just chaotic, inconsistent, random. I remember an executive once said, I love Agile. I can change my mind all the time now. He meant it. So, and even before Agile, there were statistics that showed that the majority of requirements never see the light of day or are to use. So we already know outside of Agile, it's a fool's game, the customer will know it when they see it. That's why it's complex. I think you're right. We're not doing something like manufacturing. We're trying to experiment and figure those things out. So the idea of bad Agile missing out on requirements, it feels good to say we've captured everything upfront. But I remember my first full Scrum project on my own with the whole company and the CEO saying, you know, I need to see this by October. I'm like, well, you'll see, you'll see something backed over, right? I wouldn't say that now, but this same CEO is so dead set, like, no, it needs to hit the state. He fully changed the look and feel of the whole website application we're building twice during that project. To me, it just tells me like, let's not play the game. Like I can still scope it, but let's accept it's going to change. The other part, when you say about just bad and sense of practices, there's a poll I put on my LinkedIn profile. Somebody might have seen this if you follow me on LinkedIn, but I asked. Brian (18:34) Ha Scott (19:00) You know, is the two day CSM enough to get you the results, your organization you want to see now for those who don't know CSM, obviously the standard, you know, training that people take to understand scrum from the scrum Alliance. there's certainly a lot of other courses, Brian, I know you do the advanced CSM CSP, advanced CSP. And there's more beyond that, but people by and large stop at the CSM. The percentage of it last time I checked was like 99 % of all people trained by the scrum Alliance. taking the CSM and it drops off. The percentage of people when I asked out there in the marketplace, is the CSM enough to get you the results? 95 % said no. So one, for my listeners, I'm to be a little bit of tough love on you. We ourselves might be the ones to blame for this. If we stopped our learning then, if we didn't encourage others at our org to learn and keep pressing in, you don't have the tools you need to be successful. The CSM was not all theirs. There's a slew of Equipping and training out there much less coaching and getting support. So I think there's also some miss on bad Agile. Like we never learned enough. Let's just take the basics of well, we have multiple teams. Well, but yes, the CSM doesn't cover multi team and scaling, so you got to figure that out and you're figuring out based on what you have. done it before you have valid experience and the number of companies who aren't getting coaching anymore. Now they end up just trying to figure out a methodology themselves and that's not their strength. The strength might be in -flight software for airlines. I don't know, it's not methodologies. And they're gonna take their best guess influenced by who? I'm gonna guess the PMO. And now you get this muddy version that yeah, doesn't get results. So I second that on the requirements issue and I second that just the fact that Bad Agile could be our own equipping. I do wanna add on the point about experimentation, encourage those. Brian (20:45) Yeah. Scott (20:48) The metaphor you give about camping is really great. I see a lot of out there in the world for those who are out in the scene, the whole dating scene, and you might be like, these dating apps are terrible. They don't work. Okay. I'm not going to argue they don't work depending on how you use them what's going on out there. But again, what are your options? The world's shifted and here's where we are right now. There's things we can do to do that better, but to simply throw that out, it's like, well, or dieting. Yeah, I tried that diet. It doesn't work. Dieting doesn't work. Well, Brian (20:59) You Scott (21:16) There's a mindset that goes with that. And did you follow up correctly? Did you look into the research underneath that? Even recently, I'm going through my own personal work around like sleep and health. I'm going through Peter Tia's Outlive, which is a fabulous read. But those are both like, here's some data and science, but you need to kind of hack everybody's different. Here's some ideas, try them out, see it works. Same with Scrum. Try these things out. It's not like, I did Scrum and we didn't get amazing results out of the gate. Well, you keep experimenting. It's simply empiricism. So those could be things for those listening, come back to that, look at your education level, look at options and keep learning and growing and try those things out. Cause could be, we didn't do our best to bring that or even on Mountain Good for their friends who listening who've gone through the Mountain Good courses and you have access to agile mentors. There's a community forum, there's a chance to interact, ask questions, there's lean coffee, bring your questions. How many of us actually go and take advantage of those resources? There's tons of knowledge, information, but most of us are just too busy. to get smarter and apply that. So that could be an action for people listening. What's your own next steps to grow and make sure you're doing the best agile out there that you can and you have case studies that you can reference. Could be an opportunity. Brian (22:24) Yeah, such great points. I'll build on your analogy there, or what you talked about with sleep a little bit, and thinking about how, you know, this is one of things I love about Agile, because, you know, if it was, this will maybe highlight the difference between Agile and Scrum a little bit for everyone, if you don't really understand this, right? If I were to say to you, make sure you go to bed at 10, and get up at, you know, six every day, right? You get eight hours, that's eight hours, right? You get hours of sleep, but you gotta be in bed by 10 up at six. Well, some people would hear that go, well, that's ridiculous. That doesn't fit my schedule. I work better at late at night and I'm not an early morning person. And you probably just say that's terrible. That's a terrible idea. But if I said to you, make sure you get enough sleep, right? Then you can apply that and think, okay, well, for me, enough sleep is this. And I know what that means. I know what it means when I get enough sleep. Scott (22:53) Thank you. Brian (23:23) And for me, that means I'm going to bed by 11 or 12 or whatever. Like I know when I need to be in bed and I know when I need to wake up in the morning and that's enough sleep for me. Maybe it's seven hours for me. Maybe it's nine hours for me. Right. That's the difference to me between Agile and Scrum is that Agile, and that's why I take such offense at anything that would say, it's a failure. Well, it's a principle. And if you're going to take exception to it, which one? Which principle or value are you going to call out and say, this is the one I disagree with, this is one I don't think is valid? Because it's not telling you exactly how to do it. It's not telling you what a sustainable pace is, for example. It's not saying only work 40 hours a week. It's saying everyone should work at a sustainable pace, a pace they can maintain indefinitely. And if you disagree with that, if you're going to say, well, that's a failure, Scott (24:05) Right? Mm -hmm. Brian (24:17) I don't think people should be working at a sustainable pace. They should be working at an insustainable pace. Well, I'm going to have an issue with you, right? And I'm going to say, where's your research on that? Like, where would you say that that's, you know, how could you back that up? So that's why I take, I think I'm welcome to people with different ideas, but I want to see the data. I want to see you back it up. And even, you know, something like this project, I want to say, what questions did you ask? You know, if you're just taking a poll of software engineers, how did you phrase the questions? Were they leading in how you phrase them? That kind of stuff can be very, very important and make a big impact on your numbers. So without the data, it didn't happen. Scott (25:01) Absolutely. I think that, well, and to that point, Brian, and I'm going to push a little bit. This word agile might be the most misunderstood word of the last decade or two. I guarantee you. You can ask 10 people and get 10 different versions of the answers. So like, what are we talking about? Let's take a step back and like, it's sense making to have a conversation around that. So for example, I remember this person who supposedly walked in, this is just this year, walked into the Brian (25:14) I agree. Scott (25:31) They're, you know, the head of the PMO, they've been doing agile. came from a large manufacturing company. Everyone recognized the name. Now there's other company that got brought in. Let's do this right. And, you know, has all this agile experience. And I'm actually having a conversation. We're talking about planning and predictability and how to get the teams where we need to. And I mentioned this about Velocity and she said, Velocity has nothing to do with planning. And for those who don't know, one, reach out and talk to us, because we can help you do that. The second thing is, in my mind, I didn't even know how to answer. That is the thing we use for planning is how much does your team get done, and we'll extrapolate what they're going to get done by the certain date. But I remember just feeling like, and you're saying you're walking out with all this Agile experience, and you're heading up the PMO on how we roll out Agile. Thank goodness that CTOs are like, Brian (25:56) Right. Scott (26:16) It has everything to do with planning. And I'm like, thank goodness you straightened that out because I didn't want to say anything. And I'm going to add to that at the leadership level and management level, because management statistically is going to be your biggest inhibitors to continued agility and growth. Management in terms of how we work around here, which is essentially a culture, how we do things around here. That's going to be seven of your 10 reasons you get stuck. When I've polled and asked numerous groups, how much does your leadership understand about Agile on a scale of one to 10? And the numbers I'm constantly getting back are right around 3 .5 to four on a scale of one to 10, right? Which is bad. But here's the flip side is I say, okay, how much does your leadership and management think they understand about Agile? Well, then it basically doubles, right? And even I've people say like on scale of one to 10, they think they're at 12, right? So we have groups who are large influences of how this is going and the stakeholders and what they're asking who. Brian (26:53) Yeah. Scott (27:13) not only don't understand it, but think that they do. So if you're listening to this out there and you're kind of like, yeah, I agree. Yeah, so what do we need to do about this? And again, you have a lot of options, but if you let that hang over us in terms of that's gonna be your constraints, the true agility here, what we're trying out. And we just kind of accept that, yeah, they don't know anymore. It's almost like this gallows humor, ha ha, they don't get it. Yeah, but they're the ones who are like. asking for fixed scope, fixed date, don't understand about iterating, don't understand MVP, don't understand, like show up to the demos and see what we've done to give us feedback. So those are things that undergird this problem that that lack of understanding can be pervasive and yet people think that they do. And I'll go back to another leader who said they understood Agile, but when we went through the survey feedback to help them and work through that, his comment was, I'm tired of this deadline optional culture. Deadline optional. I guarantee that people don't feel like it's optional. If anything, they're feeling a lot of pressure. But when we miss dates, how they interpret it several layers above is like, they just don't care. This is all deadline optional. So I think there's a disconnect from leadership and management side and the knowledge and even those heading up the project management office that we need to kind of check ourselves. Have they gone to training? Do they know? You'd be amazed what that can do when they get on board and really support this. It clears up a lot of stuff at the team level. Brian (28:26) Yeah. Scott (28:36) But back to what said earlier, if all you did was send a few people to the two day course and that's it, yeah, you're probably gonna struggle. Brian (28:44) Yeah, and I support what you were saying about, need to take responsibility as trainers and as the Agile community that maybe this way was not the right way of doing this. And if there's one thing I might take a little bit of exception to now from how it's described in Scrum is, we talk about Scrum Masters being change agents. And I think that may have gotten a little overblown, right? Because I think in a lot of organizations, people look at it as these people who take a two day class are ready to lead our whole company in how we're doing this. And that was never the intention, right? I think the two day class is actually okay for someone to get kicked off and plugged in and being a scrum master on a team with support, right? If that's the only person, you only have two or three scrum masters that have all taken just a two day course and... no one has really a lot of experience, then it's probably not going to do very well. But if you have some base layer scrum masters who are new, and they have some coach layers that are more experienced, even if it's just one, even if you have that one senior person who hasn't just, you wouldn't do that with anything else. There's nowhere else in your company where you'd say, let's just hire a bunch of people who have never done this before and hope that it works. Scott (30:07) you Brian (30:09) You wouldn't do that with programmers, you wouldn't do with testers. You would have some, you want to have some senior people that can help guide and mentor and make sure that it's done the right way. But for some reason, you know, companies just kind of look at it as saying, no, I'll just hire a couple of scrum masters that are brand new and that'll solve it. Scott (30:27) Woo, I mean, can you imagine getting on a plane like, by the way, everyone, welcome on board. Our pilot's never flown before. I could do that, course. And not only that, we're trying to save money around here. So he's actually going to be concurrently helping fly three other planes at the same time, like while they're doing this work. Brian (30:32) But I passed the two day class. Yeah, because most of the flight, you're not doing anything, right? You're just sitting there. So we want to make sure they're still productive so he can fly three planes at once. Scott (30:50) That's a hard one be, exactly. That's yeah, which it's, it's, people might be laughing, but it's similar. Like we're trying to get pointy to point people, things change on that flight. And I see these teams, know, scrum master spread around. I remember a company scrum master on seven teams. Nevermind organizational change agent. This poor soul can't even have the meetings run. and someone bested me like, no, I know someone's on 12 teams as the scrum master. So if management doesn't understand the value of this person, and I like what you're saying. It's a tall order organization changes. And I like the idea of like lead improvement, but we kind of cut it at the knees. had one company this year and sadly we'd helped them get started. When we came back, kind of had some back -channel conversations with people that were disgruntled on the team. So thank goodness they had a safe place to come and ask questions. But the person rolling out Agile, it was kind of knighted to help do this. And she had been through the two day training, I think, but literally as they're giving feedback on what's working, not working, she basically said like, Stop complaining. This is the way we're doing things around here. I'm here to just kind of write the playbook. I think you're the person that should be spearheading how to improve every single sprint. And you're saying, we're done talking. We're complaining. I'm trying to formalize our process here. But basically, booted them out of the working group committee that was how we implement Agile. Now, those are two of the key Agilists there. So think we missed some of that when those examples happened. So my friends are listening. expect that people don't get it, expect that they're optimizing for their own concerns. And that's fine, but we don't stop there. We have to kind of work top down bottoms up on that. And there's lots of options and case studies and stories you can see. And certainly I'll just point again to a resource. If you look at Agile Mentors, there's plenty of experts who gonna, they've been on the interviews, been recorded, take a listen to those and hear some stories, help champion this. As a side note, Brian, just gonna add this in real quick. When we talk about Agile being dead or not, I think if we lead this company, like, I totally agree with Brian Scott, especially Scott. He really is very articulate and well -spoken. I think he's probably one of the best podcast interviewees ever. And they might say something like that, but they might come back and say, I agree with Brian Scott. Agile's not dead. We're just not doing it right. So what can we do about that? We'll look back and say, how are we implementing it? Is there a plan? Are we nudging people along? Expect them to kind of play these things out, but keep in mind, It's most of this company's is a multi -year journey to get those kinds of results, but I'm not going to go back as a takeaway from listeners podcasts and tell my management or leadership, we're not doing Agile right. We should do Agile right. For those who don't already know, they don't care. They don't care that we're doing Agile right. They don't even know what it is. We already talked about their scores. They don't know anyways. I'm not going to pitch any kind of change to what we're doing in terms of Agile being right or wrong. That misses. almost every single time for me. What I will pitch is, hey, leadership, you're frustrated that we're not delivering predictably. You're frustrated we're not getting more innovation. You're frustrated our quality is not where it needs to be. Yes, and here's some things we can do to get it there. Under the covers, what we're doing is improving the way we're doing Agile for more visibility, more clarity, better tracking, all that stuff. Your Scrum Master, whoever's leading this, doggone it, they cannot be just glorified JIRA admins. That's not gonna get you there. So take it back as a thing and think about how you're taking it back to them in terms of what matters for them, what's in it for them in business value. Pitch it that way. And you'd be surprised when you're like, if that's tied to the results, I'm listening. But not this we're doing as a right or wrong. So that could be part of reason it falls on its face when we do try to address the agile being dead is how you're presenting and working with your stakeholders and leadership. Brian (34:37) Yeah, and quite frankly, I don't care what you call it. If we need to make up a new name and your company has had such a bad experience with Agile, make up a new name for it. I mean, say, no, it's this new project. It's the, I don't know, tangerine process. And it's, yeah, you haven't heard of it? Well, boy, it's great. It's this tangerine thing. Right, it's the latest thing. Tomorrow there will be a book on it. Scott (34:59) That's the way you were saying. Yes. Brian (35:07) Amazon, the tangerine process as invented by. And here's my research study showing how it's better than Agile. Right, right, exactly. But you know, it's oftentimes there is kind of a problem with a name. And so like I said, I don't care what it's called. You know, I'll give a shout out here because I had some conversations at the know, couple of conferences that took place over this year. And I was talking with one of my friends, Michael Sahota. Scott (35:14) We interviewed three people and yes, we got the data. Brian (35:37) So shout out Michael if you, if anyone kind of points out, I he's listening, but if he's listening, shout out to you for this. But we were talking about kind of the problem with the training courses and you know, how we fixed that and everything. And, one of the things we were talking about is, you know, if we could, if we could distill it down, if we could just have people lead with one thing, if they could walk away from those courses really embedded with the concept of I'm going to inspect and adapt. I'm going to inspect what I did. and adapt and when something doesn't go well, I'm not just gonna say, nah, I'll just keep doing it the wrong way. No, if it doesn't go the way it needs to, stop, figure out why and then change and try something new. If I could just get a team to do that without knowing all the practices, all the other, right, I don't care if you call each other, know, Scrum Masters or whatever, if you can just get that, then I think you will. naturally evolve into what you need to be for that company. But you got to have that underlying mentality, culture of it's not acceptable when something goes wrong. We have to figure out why and change. Scott (36:36) Mm Absolutely, and I'm with you. I don't care what's called anyways. My reference is a colleague in Southern California, Ben Rodolitz, and he's very big. I just don't use those words anymore. to be honest, it could be actually confusing for people. If they don't know what Agile means and you're using words from Agile, they're going to think they're mapping to what reality is. They're misunderstanding. So maybe we do start with terminology. I'm with you. I'll see my friends. I don't care if you use agile scrum, whatever. I would just say, Hey, we're to try to do something, see how that goes. Well, we're visiting two weeks and take a look at what we got and get, we'd love some feedback. I mean, it's all the same stuff, but we're expecting to not do things right. And learn along the way and not stop. That's the whole process of it. So for some of you that are doing this and feeling like, I think agile's X, we're not seeing results. would, I would take a look and are you breaking any of those fundamentals to begin with? And I think we are quick to say, yeah, but we can't do X, Y, Z Scott. can't have dedicated teams. Brian (37:37) Yeah, yeah. Scott (37:38) We can't actually get the stakeholders into the sprint review. We don't got time for the retro. Well, then we're one, you're not doing that stuff right. But even if you just call it something else in the end, do something, inspect and adapt, right? Learn by experience, try something out. I hear too much of, I don't think that'll work here. Well, do some, find out, do something and see what you get from that. Worst case, you're going to learn. But a lot of people are like, you know, we can't do that. They won't go for that. And we never actually even tried. But I love what you're saying. Maybe. for those out there listening, try a refreshing thing of different words and then, or move away from the language that they think they know and don't fight that fight. Pick the fights you think you can win in advanced stuff to get results and get noticed. And Brian, you might've seen this too. I've seen company after company, when they actually see results, the stakeholders see results, business are real, they don't care what you're doing, do more of that. I've watched them just pivot and like rush in. So maybe we do step away from all these. Brian (38:28) Yeah. Scott (38:34) methodology wars and language issues and just get back to what gets results. Do more of that. Learn as you go and keep them learning, right? Like the brass tax. Brian (38:44) Yeah, absolutely. Well, I'm not surprised we went a little over, but I appreciate everyone. I hope we didn't eat into anyone's, know, screw up your walking schedule or anything if you're listening to this while you're walking. But, you know, when Scott and I get on a soapbox, you can just guarantee we're gonna be a little bit over. That's just how it goes. Scott (38:49) Next. You would love it. Brian (39:09) Well, Scott, I really appreciate you coming on, because I think this is a great episode. I really appreciate your views on this, and thank you for making the time. Scott (39:17) Yeah, you bet. And for those listening, honestly, put some feedback. We'd love to see what you think in terms of Agile is dead and continue that conversation. I do think it's gonna be an ongoing conversation. But again, thank you, Brian. My pleasure. Always happy to jump on here. Great to work with you guys.

This week, we discuss Google possibly buying Wiz, why "meta work" leads to too many meetings, and why it took forty years to get spell check in Notepad. Plus, we share some thoughts on enjoying your vacation. Watch the YouTube Live Recording of Episode 476 (https://www.youtube.com/watch?v=xsf8ZV0y2cI) Runner-up Titles Enjoy the time Everyone can get a beef rib at this year's club. We also need to go over your summariztion prompt, because mine is dog shit right now. Make your own happiness Grand unified theory of food - every culture has a tortilla and an empanada. “Platform” is the new “Suite.” A robust NO Answer Writing a book report Failure by lack of airport ads. What is you five dollar chicken I write to figure out what I am thinking Rundown There's a lot of private cloud out there (https://newsletter.cote.io/p/theres-a-lot-of-private-cloud-out?utm_source=post-email-title&publication_id=50&post_id=146459324&utm_campaign=email-post-title&isFreemail=true&r=2l9&triedRedirect=true&utm_medium=email) Google near deal to acquire cybersecurity startup Wiz for $23 billion (https://www.investing.com/news/stock-market-news/google-near-deal-to-acquire-cybersecurity-startup-wiz-for-23-billion--wsj-3518269) Meta Work White-Collar Work Is Just Meetings Now (https://www.theatlantic.com/ideas/archive/2024/07/white-collar-meetings-more-frequent/678941/?gift=kZAb-CYAytdK21NICp8tcksr3ftg7NNiIjAvQD0GxRo&utm_source=copy-link&utm_medium=social&utm_campaign=share) Bullshit Jobs (https://web.archive.org/web/20180807024932/http://strikemag.org/bullshit-jobs/) Far Left Take (https://web.archive.org/web/20180807024932/http://strikemag.org/bullshit-jobs/) Vanguard's Die-Hard Customers Have a Message for New CEO: ‘The Service Is Abysmal' (https://www.wsj.com/personal-finance/vanguards-die-hard-customers-have-a-message-for-new-ceo-the-service-is-abysmal-c2da0491) Measuring the impact of Developer Relations on Revenue (https://jmeiss.me/posts/measuring-devrel-impact-on-revenue/) DevRel's Death as Zero Interest Rate Phenomenon (https://dx.tips/zirp) Microsoft's Notepad gets spellcheck and autocorrect 40 years after launch (https://www.theverge.com/2024/7/8/24194047/microsoft-notepad-spellcheck-autocorrect-features-available) Agile Manifesto co-author on making process 'beacon of hope' (https://www.theregister.com/2024/07/16/jon_kern/) Relevant to your Interests The Silent Crisis in Open Source: When Maintainers Walk Away (https://dev.to/opensauced/the-silent-crisis-in-open-source-when-maintainers-walk-away-1m81) Google's dark web monitoring service will soon be free for all users (https://www.theverge.com/2024/7/9/24194970/google-one-free-dark-web-monitoring) Software Development Job Postings on Indeed (https://fred.stlouisfed.org/series/IHLIDXUSTPSOFTDEVE) Samsung unveils its new Galaxy Ring, an AI-backed competitor to the Oura Ring (https://www.businessinsider.com/guides/tech/samsung-galaxy-ring-release-date-price-features-specs) Does Social Media Cause Anything? (https://crookedtimber.org/2024/07/03/does-social-media-cause-anything/) Redbox Owner to Shut Down Kiosk Business in Bankruptcy (https://www.wsj.com/articles/redbox-owner-to-shut-down-kiosk-business-in-bankruptcy-f0cada8d) Intuit to cut about 1,800 jobs as it looks to increase AI investments (https://www.cnbc.com/2024/07/10/intuit-to-cut-about-1800-jobs-plans-to-rehire-in-key-areas.html) Microsoft Exec Althoff: VMware Pricing Gave ‘The World The Greatest Gift Of All' (https://www.crn.com/news/ai/2024/microsoft-exec-althoff-vmware-pricing-gave-the-world-the-greatest-gift-of-all) Nearly all AT&T subscribers' call records stolen in Snowflake cloud hack (https://arstechnica.com/tech-policy/2024/07/nearly-all-att-subscribers-call-records-stolen-in-snowflake-cloud-hack/) OpenAI illegally barred staff from airing safety risks, whistleblowers say (https://www.washingtonpost.com/technology/2024/07/13/openai-safety-risks-whistleblower-sec/) I've Switched to Apple's Password Manager, and I'm Never Going Back (https://www.makeuseof.com/switch-to-apple-password-manager/) Ten years of Overcast: A new foundation (https://marco.org/2024/07/16/overcast-rewrite) Nonsense Costco hikes membership fee for the first time since 2017 (https://www.cnbc.com/2024/07/10/costco-hikes-membership-fee-for-the-first-time-since-2017.html) Costco plans to build 800-unit apartment complex in bid to ease housing crisis (https://nypost.com/2024/06/28/business/costco-teaming-up-with-developers-to-build-an-800-unit-apartment-complex-in-bid-to-ease-housing-crisis/) Here's why the original Buc-ee's went up in flames in Luling (https://www.expressnews.com/news/article/luling-bucees-fire-cause-19567134.php) If you miss defragmenting your C drive, there's a website that lets you recreate the experience complete with hard-drive chunking sounds (https://www.yahoo.com/tech/miss-defragmenting-c-drive-theres-002734202.html) The Morning After: Dune-inspired spacesuit recycles astronauts' urine into drinkable water (https://www.engadget.com/the-morning-after-dune-inspired-spacesuit-recycles-astronauts-urine-into-drinkable-water-111540921.html) OldMapsOnline (https://www.oldmapsonline.org/en) Sponsor Check out www.apilayer.com (https://apilayer.com/?utm_source=SoftwareDefinedTalkPodcast&utm_medium=Leads%20Acquisition&utm_campaign=PodcastDescription)! From scraping, finance to weather data, apilayer offers reliable and easy-to-integrate APIs for all your needs. Trusted by developers at companies worldwide. Use the code SDT2024 for an exclusive discount - 50% for 3 months on 100 API plans. Code is valid until Sep 30, 2024 Conferences Webinar on State of Cloud Native Survey (https://tanzu.vmware.com/content/webinars/jul-24-exploring-the-state-of-cloud-native-application-platforms-and-tanzu), July 24th, 2024, Coté speaking. DevOpsDays Birmingham (https://devopsdays.org/events/2024-birmingham-al/welcome/), August 19–21, 2024 DevOpsDays Antwerp (https://devopsdays.org/events/2024-antwerp/welcome/), 15th anniversary, Sep 4th–5th, 2024 SpringOne (https://springone.io/?utm_source=cote&utm_campaign=devrel&utm_medium=newsletter&utm_content=newsletterUpcoming)/VMware Explore US (https://blogs.vmware.com/explore/2024/04/23/want-to-attend-vmware-explore-convince-your-manager-with-these/?utm_source=cote&utm_campaign=devrel&utm_medium=newsletter&utm_content=newsletterUpcoming), August 26–29, 2024 SREday London 2024 (https://sreday.com/2024-london/), September 19th–20th, Coté speaking. 20% off with the code SRE20DAY (https://sreday.com/2024-london/#tickets) SDT News & Community Join our Slack community (https://softwaredefinedtalk.slack.com/join/shared_invite/zt-1hn55iv5d-UTfN7mVX1D9D5ExRt3ZJYQ#/shared-invite/email) Email the show: questions@softwaredefinedtalk.com (mailto:questions@softwaredefinedtalk.com) Free stickers: Email your address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) Follow us on social media: Twitter (https://twitter.com/softwaredeftalk), Threads (https://www.threads.net/@softwaredefinedtalk), Mastodon (https://hachyderm.io/@softwaredefinedtalk), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com) Watch us on: Twitch (https://www.twitch.tv/sdtpodcast), YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured), Instagram (https://www.instagram.com/softwaredefinedtalk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk) Buy Coté's Book: (https://leanpub.com/digitalwtf/c/sdt)Digital WTF (https://leanpub.com/digitalwtf/c/sdt) Sponsorship opportunities available (https://www.softwaredefinedtalk.com/ads) Recommendations Brandon: COTA Bike Night (https://circuitoftheamericas.com/bike-night/?gad_source=1&gbraid=0AAAAABXF-geXk7FxOT844q2nAxFPRq2W-&gclid=CjwKCAjw1920BhA3EiwAJT3lSeeD4WQEfQVJokUXc_KFhuoBpl1SgZzNoGluN4Rm5pPUNKdgI5dvshoC6TYQAvD_BwE) The Mid Year (2024) Mailbag (https://www.thecloudcast.net/2024/07/the-mid-year-2024-mailbag.html) Sharp Tech answers Brandon's question about F1 (https://overcast.fm/+8V7cdzZs0/58:52) Coté: Soulver (https://soulver.app). Photo Credits Header (https://unsplash.com/photos/people-on-sand-7_ZDmcq8x6A) Artwork (https://unsplash.com/photos/person-standing-near-the-stairs-MYbhN8KaaEc)

Join Brian and Bernie Maloney as they explore the transformative power of mental models, emphasizing the shift from a mechanistic to an organic mindset in Agile organizations. Overview In this episode, Brian and Bernie Maloney discuss the profound impact of mental models on organizational culture. Bernie delves into how our beliefs and assumptions shape our thinking and behavior, particularly within Agile environments. He discusses the importance of transitioning from a mechanistic to an organic mindset, focusing on problem-solving rather than merely delivering solutions. The conversation also highlights the role of psychological safety in fostering a culture of experimentation and learning. Bernie shares valuable resources, including Amy Edmondson's 'The Right Kind of Wrong,' to further explore these concepts. Tune in for insightful strategies for enhancing your organization's agility and effectiveness. Listen Now to Discover: [1:03] - Brian welcomes Certified Scrum Trainer® and Principal at Power By Teams, Bernie Maloney, to the show. [2:15] - Bernie delves into the concept of mental models, sharing the origins of his philosophy of "making new mistakes" developed during his time at Hewlett Packard. [5:55] - Bernie illustrates the power of mental models and belief by sharing a compelling example that brings these concepts to life. [13:46] - Join us for a Certified Scrum Product Owner® Training, where a year of coaching and development with Mike Cohn, Brian, and the Agile Mentors Community of Agile leaders is included with your training. [14:39] - Bernie discusses how applying mental models can enhance the effectiveness of Agile transformations, creating a naturally adaptive and innovative climate. [18:12] - Bernie offers language as a powerful tool to support the shift to a new Mental Model. [23:30] - Bernie demonstrates the use of mental models for product owners through the Mobius Loop, providing actionable guidance and examples [26:27] - Brian shares a big thank you to Bernie for joining him on the show. [26:59] - If you enjoyed this episode, share it with a friend, and like and subscribe to the Agile Mentors Podcast so you never miss a new episode. [27:27] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership to that site by taking any class with Mountain Goat Software, such as CSM, CSPO, or Mike Cohn’s Better User Stories Course. We'd love to see you in one of Mountain Goat Software's classes. You can find the schedule here. References and resources mentioned in the show: Bernie Maloney Power By Teams Mobius Loop The Right Kind of Wrong: The Science of Failing Well by Amy Edmondson Agile Teams Learn From Spikes: Time Boxed Research Activities by Mike Cohn Certified Scrum Product Owner® Training Certified ScrumMaster® Training and Scrum Certification Mike Cohn’s Better User Stories Course Mountain Goat Software Certified Scrum and Agile Training Schedule 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 podcast@mountaingoatsoftware.com 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. Bernie Maloney is an Agile leadership coach and international speaker, leverages his 25 years of engineering and leadership experience to help teams and organizations unlock their full potential. Known for his engaging workshops and impactful coaching, Bernie believes in making performance breakthroughs both achievable and enjoyable. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are back for another episode of the Agile Mentors Podcast. I am with you as always, Brian Milner. And today I have a very special guest with me. I have Mr. Bernie Maloney with me. Welcome in, Bernie. I am. Bernie Maloney (00:14) Thanks, Brian. Happy to be here. Brian (00:16) Great. I'm so excited to have Bernie here. Bernie and I have touched base for years over conferences. We've run into each other and had chats and shared our shared passion for Hawaii and other things. But Bernie was speaking at the recent conference and we've gotten into some conversations. I wanted him to come on because I wanted him to, first of all, if you're not familiar with Bernie, sorry, I see, I just want to jump right into it. If you're not familiar with Bernie, Bernie is a CST. He works at a company called Powered by Teams. He teaches classes, Scrum Master product owner classes and leadership classes and other things as well. But he is a principal at Powered by Teams. So just wanted to give you the basics there before we dive into anything. But the topic that we started to talk about that just as a jumping off place for us is a topic. the topic of mental models. So Bernie, why don't you explain to everyone how you define that, mental models. Bernie Maloney (01:23) So, Brian, this is a great topic. I find myself talking about it all the time. And y 'all, I warned Brian, like, he can press play on this, and it might be 15 minutes before he gets a word in edgewise here. It touches on mindset. It touches on a lot of topics. My talk that Brian was referencing at the recent Scrum gathering in New Orleans was make new mistakes, leadership lessons from an Agile success. which goes back to where I really kind of cut my teeth in Agile at Hewlett Packard. See, I'm a mechanical engineer by training. And I cut my teeth in Agile in the consumer PC division at HP about, this is scary to say y 'all, okay, about 27 years ago starting at this point. And some of the fun stuff, it was a bang up enterprise. It was the fastest business in HP's history to hit a billion dollars. And it was just... Brian (02:05) Yeah. Bernie Maloney (02:18) a great proving ground. We had hardware, we had software, we had distributed teams where volume manufacturing was in Asia, engineering was here where I am in Silicon Valley. Go -to -market for Europe was in Grenoble, France. We had high volume. Some of our products had 100 ,000 units in a single model run, with like 200 models in Europe on a quarterly basis at times. So high volume, high mix, tight margins from a business perspective. A lot of technology products want to have 20 % to 30 % gross margins. That's before you start taking off deductions like expenses and salaries and things like that. On a good day, we had 8 % gross margins for Christmas products, maybe 2 % gross margins. We used to refer to it as we were shipping rotting bananas. And like I said, I was there. When I started, we were shipping six products a quarter. We grew to 20. By the time I left after eight years, we were doing 200 products a quarter in Europe alone. Brian (03:04) Ha ha. Bernie Maloney (03:16) hardware, software, distributed teams, high volume, high mix. And we did all that with weekly iterations of a plan. At one point in my career, I was tactically responsible for the delivery of 2 % of HP's top line revenue with zero direct reports. And part of the secret sauce of success in that organization was really that mental model of make new mistakes. So that's where the talk title comes from. And in fact, makenewmistakes .com will point to poweredbyteams .com because I own that domain too. But that mental model really helped the organization thrive and not just survive. We went from like a number one to a number five share. Sorry, from a number five to a number one the other way around. Because the founding executives recognized that in that tide of a market, mistakes were probably going to happen. And so what they did is they established the psychological safety. Wow, look, there's another great topic. Make new mistakes. You knew that if it was an honest mistake, it would be forgiven. Just don't make it again. Get the lesson is one of the things that they said. I can even tell you the story about the weekend I blew a million dollars of HP's money and I was forgiven, but you'll have to come to a conference talk for that. So that was just like a great experience. And... Brian (04:32) Wow. Bernie Maloney (04:39) After that experience, I went on to TVs. Another part of my background is I shipped the very first internet connected TVs. Look it up, the Media Smart 3760 from HP. It shipped even before Apple TV. It bombed. Okay, it was way ahead of its time. But I recognized that that had been such a joyride. And then I recognized some other stuff that really gets into the psychological, the mental aspects of leadership, high performing teams. And I could, Brian, I could talk about that too, but okay. But that kind of got me to recognize that with those skills, the success that I had experienced at HP could probably be replicated. That's kind of been the path that I've been on for the past 15 years is really helping organizations go along that path. So mental models can be really big. Let me give everybody here an example. And so Brian, I'm going to speak to you as a way of illustrating mental models. So imagine you are physically where you are right now. Brian (05:24) Yeah. Bernie Maloney (05:37) but it is 150 years ago, okay? Imagine you're physically where you are right now, but it's 150 years ago. Now, Brian, let me ask you, can man fly? Brian (05:47) boy, you're testing my history knowledge. Bernie Maloney (05:52) Okay, make it 200 years ago, okay? That makes it easier. Okay, cool. Great, now fast forward to the present. Brian, let me ask you, can man fly? Brian (05:54) No, yeah, no. Yes. Bernie Maloney (06:02) What changed? Nothing about the laws of physical reality. It was just your mental model of what for man to fly means. That's the power of belief, okay? And belief limits a whole bunch of stuff in the way that people behave. So you'll hear Agilent talk all the time about, this is all about changing mindset. I'm probably, Brian, gonna give your listeners some ways of. Brian (06:06) invention. Bernie Maloney (06:30) changing mindset as we go through this, but that's going to illustrate the power of mental models. Now, a big one that I like to use that's specific to Agile comes from Gabby Benefield. She's an Agilist out of the UK, and it's called the Mobius Loop. And I think she's got the domain mobiusloop .com. So everybody can imagine a Mobius Loop. Okay. And what I really like about this model for her... Brian (06:32) Sure, yeah, please. Yeah. Bernie Maloney (06:56) i s the right -hand half is what a lot of organizations think Agile is. Build, measure, learn, build, measure, learn. The whole idea of the build trap that we talk about in Agile. It's all about the delivery of a solution. Okay? But the left -hand half is all about the discovery of the problem. Okay? And the discovery of the customer. And that's a part of Agile too that most organizations overlook. So you got to ask why. And it comes down to kind of mental models. So when I was at Persistent, if you go look me up on LinkedIn, you'll find some of my employment history. I was at Persistent for a while. They had a really good mental model. And it's something I still use when I go into a client. And they would talk about there's kind of three eras of a company culture. And so culture is really the environment that an organization lives within. And there's an era. where cultures were formed before the internet. So things like finance and government and mining and manufacturing and oil and gas field developed. I mean, I've had clients in all of these areas. And in that sort of an environment, okay, it was, well, an era. One of the things I'll ask, and Brian, I'll kind of like let you represent the audience. Would you say in general, the people that you work with, the markets that they serve, Are they moving faster and all up into a thumbs up, slower, thumbs down, or about the same, thumbs sideways? Are the markets moving faster, slower, or about the same as they were, say, five or 10 years ago? Brian (08:32) I think everything's moving faster, yeah. Bernie Maloney (08:34) Cool. Okay. Now, how about the technology that your clients use to solve problems for that market? You know, moving faster, thumbs up, slower, thumbs down, or about the same as it was, say, five or 10 years ago. Faster. Yeah, cool. Okay. Now, when things are moving faster, thumbs up for yes, thumbs down for no. Do they always move in a straight line? Brian (08:46) No, faster. No, not always. Bernie Maloney (08:56) Okay, cool. So now things are moving faster, but they're not moving in a straight line. So let me ask you, do most organizations try and plan and predict? Is it possible for you to plan and predict when things are moving faster and they're not moving in a straight line? Is it easier or harder to plan and predict? Brian (09:19) I think it's definitely harder. Bernie Maloney (09:21) Yeah, but organizations are trying to do that, aren't they? And it's because their mental model is as a machine. So organizations born before the internet have a mental model of the entire organizational system being a machine, the industrial age, which you can plan and predict. They treat people like cogs in a machine. In fact, the thing that us Agilists will say is, when you say resources, did you mean people? See, that's... Brian (09:35) Yeah. Bernie Maloney (09:50) That's kind of now we're starting to get into some of the culture aspects of this because language actually forms culture. And so you'll hear Angela say, did you mean people? Like when that whole word of resources comes up. But organizations born before the internet, they've got one culture. Okay, they were born in an era of plan and predict. They've got a mental model of the system being a machine. And your listeners would probably agree most of them struggle with Agile. Okay, now there's another era born in the internet but not the cloud. So some examples like here in Silicon Valley, Cisco, PayPal, okay, lots of us have had exposure to them and lots of us recognize they still struggle with agile because agile wasn't really fully formed and articulated. Then there are organizations that were born in the cloud and so places like Striper Square and I use payments because I've had... clients in finance across all three of these eras. So Stripe or Square, they were born in the cloud where things were almost natively agile because the Agile Manifesto had been published by that point. They just inherently get agile. So these mental models of your organizational system being a machine get reflected in the language. So things like people or resources, it turns them into objects. It enables something I've heard called pencil management. Wear them down to a nub, go get a new one. In fact, if you do the research on where the word resources was first applied to human beings, it might shock some people. So I don't talk about that openly. They'll have to find me privately. I'll be happy to point you out the reference. And once I do, it's like, ooh. But one of the jokes I'll crack. And this is one of the ways that you can start to shift the language. If people call you resources, because you know that turns you into an object, start calling them overhead. Brian (11:23) Yeah. Ha ha ha. Bernie Maloney (11:48) Okay, it can kind of make the difference there. Okay, so, but you know, if things are moving faster and they're harder to plan and predict, that mental model needs to shift. In fact, in agile, we talk about you need to move to sense and respond. When things are moving faster, it's kind of like Gretzky, skate to where the puck is going. You need to sense and respond to the situation. So a better mental model instead of a mechanism is an organism. Because think about organisms, like cut yourself, it heals, okay? It senses and responds. Or like a forest fire comes in, wipes things out, and nature always kind of fills things back in. Sense and respond. This gets reflected in the language. So Brian, do your clients talk about metrics? Brian (12:37) Of course, yes. Bernie Maloney (12:38) Okay, cool. So do they talk about efficiency? Brian (12:41) I would say a lot of businesses will talk about that. Yeah, sure. Bernie Maloney (12:44) Yeah, cool. That's the language of machines. Probably better language is diagnostics instead of metrics. That invokes some of the curiosity. And probably instead of efficiency is effectiveness. One of the things I'll say is scrum is not efficient. It's not about utilization of capacity. It's about the production of value, which is all about effectiveness. See, efficiency or effective. Do you go to your doctor for an efficient treatment? or ineffective treatment, Brian. Brian (13:16) Effective, hopefully. Bernie Maloney (13:17) Awesome. Do you go for blood metrics or blood diagnostics? Brian (13:21) Yeah, diagnostics for sure. Bernie Maloney (13:23) Yeah, so now you're starting to get some hints about how you can start to shift the mental model. What you're really doing with Agile, y 'all, is you're shifting the culture, and culture is hard because it's not visible. The tools, the processes, the practices that folks like Brian and I will teach and coach, they're super visible, they're super valuable, but they're often not enough to start to change things. So, Brian, would you say most of your listeners are familiar? familiar with the language of Tuchman of forming, storming, norming, and performing. Brian (13:56) I'd say there's probably a good percentage, yeah. Bernie Maloney (13:58) Cool. I actually like to draw a Satir curve. So Bruce Tuckman, Virginia Satir, they were contemporaries. They were both just researching human systems. So Virginia did a performance axis on the vertical and a time axis on the horizontal. And the way Virginia described it is you're kind of going along in a certain status quo. And so you're kind of along that baseline. And then a foreign element enters and some change. And then you descend into chaos. And you can't see it. like your performance goes down until you have a transformative idea and then through some practice and integration, you rise to a new status quo. This happens to people all the time when they introduce changes in their life like New Year's resolutions. I'm going to get fit and healthy this year. You know, it's a beach body time. And you start doing it and it's like, this is so hard. You're in chaos. And what human beings want to do is they want to go back to the way things were instead of moving through. OK, this happens when you introduce agile into your organization. You'll hear Agilist talk about this as the Agile antibodies. You introduce it, this is so hard, and people want to go back to the way things were instead of kind of moving through. So the tools, the processes, the practices, they're really good, but they're not powerful enough. You got to start changing the culture. Culture is like what we all swim in, but climate is something that you can start to affect. So climate is a little bit closer in to your team, and you can start talking about these mental models. Like when I was at TiVo, I was hired into TiVo to bring Agile in because I had shipped TVs, I knew about Agile. And I was hired in on, I think I can say this now because we're more than a decade past. Have you all ever streamed anything? Yeah, okay. So TiVo was working on that in like 2009, 2010. I got to see that stuff and I was like, really wish I had taken off for them. But that program... Brian (15:42) yeah. Bernie Maloney (15:54) disbanded, okay, and the culture kind of spread in the organization. And I knew that this was a possibility, so when I brought it in, I made sure I didn't just work with my team that was doing a Skunk Works project, where we were just kind of doing some internal development that we weren't, you know, or stealth is probably a better word these days. So a stealth program inside of TiVo that you couldn't talk about. I knew that... when Agile would spread, it would hit some of this resistance, these antibodies. And so I made a case for bringing in people from outside my team so that it was familiar. And when that program disbanded, it organically spread on the cloud side of TiVo because of some of this stuff. So within your own team, you can kind of create a climate. And then when you start to see results like that, that's going to start attracting kind of the rest of the culture that's there. But these mental models, like shifting from mechanism to organism can really help an organization recognize where their limiting beliefs are about how things go. And it's going to be reflected in language. So if you like dive into anthropology a little bit, you're going to recognize that it's really well established. You can change a culture by starting to change the language. And all of us, okay, if you're observing what's going on in Eastern Ukraine here in 2024, that's what's going on. with the Russian occupation, they're changing the language because that's going to change the culture. That's why they're doing stuff like that. So, and even language starts to shape the mental models that you've got. A good example of something like that was when European, you know, when European explorers is the language I'll use, came to the Americas, the natives didn't really have a language for ship. And so they saw these people coming in floating on the water. And that was the way that they could describe it. So even language kind of gets into a cultural sort of a thing. So these are techniques that you can put into your toolkit. Start shifting the language to start shifting the culture, which can kind of help with the mental models. When you got the mental models, that's where the language starts to come from. If you don't have the mental models, you're probably not going to have the language. And I encourage all the folks I work with, start shifting from the whole idea of mechanism to organism. Okay, Brian, was that 15 minutes? Did I go on for as long as I predicted I would? Brian (18:27) About 15 minutes. Yeah. No, but I think that's a good point. There's a thing that I'll talk about a lot of times in my classes where I would all say, you know, the waterfall paradigm is one that's based on manufacturing. And there's a false understanding of what we're doing as manufacturing and it's not. It's more research and development. So you have to kind of shift the process to be one that's more conducive. to research and development. So that's very much in line with what you're talking about here. I love that. Bernie Maloney (19:01) Yeah. Do you think people would appreciate some book references that can kind of like help you? Okay. So specifically on that whole ethos of experimentalism that you just touched on, Brian, I'm currently going through Amy Edmondson's The Right Kind of Wrong. Really good book. Now, Amy is well known because she helped establish psychological safety as a super important topic in organizations. Brian (19:07) absolutely. Absolutely. Bernie Maloney (19:30) So she was coupled, I think, with Project Aristotle at Google. And in this book, she unpacked some really interesting stuff. She talks about failure, and there's types of failures. There's basic, there's complex, and there's intelligent failures. OK, intelligent failures, they're just native to science. You know things are going to go wrong. You're going to have Thomas Edison, the I Found 1 ,000 Ways. to do a light bulb wrong, sort of. That's like intelligent failure. Basic failure, she breaks down into, let's see, neglect and inattention. And those are the things that you really want to start to squeeze out of a system. With that mental model of a mechanism, I would say a lot of, call it management, tends to think of a lot of failures as basic failures. And that's where blame starts to come into a system. Okay, so now we're back into psychological safety. Okay, where you want to establish, you know, that was an honest mistake. Hence the talk title of make new mistakes. Okay, so you can have processes and procedures that can kind of squeeze out some of those basic failures. Complex in the middle is really interesting to talk about. As I'm getting into the material, she unpacks... Now, complex failures are those chain of events, you know, Brian (20:30) Yeah. Yeah. Bernie Maloney (20:54) This thing and this thing and this thing all had to line up and go wrong at the same time for this catastrophic failure to go on. And in medicine, which is where her original research was, they talk about it as Swiss cheese. And she says, if you go into a lot of medical administrators' offices, you're going to find some model of Swiss cheese there. Because they talk about it's like all the holes have to line up for something to go sideways on you. So complex failures. It's a chain of events, a bunch of little things. And she points out that in the research, these often happen when you have an over -constrained system where there's no slack, where you're trying to operate with, get this, Brian, 100 % efficiency. You're trying to load everybody up. So that is just like, it's not just juice on psychological safety, but like, looking at the whole idea of intelligent failures that we want to encourage versus constraining out basic failures versus working to reduce those complex failures and not just thinking complex failures are basic failures, but they're systemic failures that then might be part of the system, might be part of the mental model that's going on that's there. So super juicy stuff. Brian (22:11) Yeah, yeah, that's really good stuff. I've always loved Amy's work and I feel, you know, silly calling her Amy. But Amy Edmondson's work has always been great. Yeah, Professor Edmondson. She, the work on psychological safety, I think was just amazing. And the examples she used in her research are amazing. And, you know, all the stuff with Project Aristotle. Bernie Maloney (22:20) Okay, Professor Edmondson, yeah. Brian (22:36) I love the concept of psychological. I mean, again, not to make this the topic of our podcast, but, you know, I love the idea that they, they, they found that psychological safety was, so foundational that nothing else mattered. That if you didn't have that, that not no matter what else you layered on top of it, it would not fix the problem that you didn't have psychological safety. Bernie Maloney (22:58) Yep. And that's one of the reasons why I say Agile is actually a social technology more than anything else. I mean, that's why it's people and people over processes and tools. This is really a social technology that we deal in. Brian (23:10) That's a great way to put it. I love that social technology. Awesome. I love that. Bernie Maloney (23:14) So kind of talking about Amy and psychological safety and kind of all these systems that we're talking about, another mental model that I like to give particularly my product owners, going back to that Mobius loop. and like on the right hand side is all about delivery, okay, that's where you give team solutions to build. That's what a lot of organizations do. Versus on the left hand side with discovery, it's all about problems to solve. So I like to encourage my clients to instead of just giving people solutions to build, give them problems to solve. Now, for product owners, if you imagine like an onion that's kind of stretched out left to right, so kind of an odd long little onion. Brian (23:41) Yeah. Bernie Maloney (23:58) and on the far right is your sprint. And then as you go to the left, you're at a release, and further out to the left, you're in roadmap, and way further out into the left, you're into these vague things like vision. So product owners kind of deal with this whole span of things. And in between, product and sprint goals start to make things a little bit more concrete. Okay, and... One of the things I'll do for my product owners is I'll take that Mobius loop and I'll overlay it on a planning onion like that and go, do you get to see how, like what we're talking about here, you're starting out way vague in discovery and you're getting way more concrete as you get into delivery and into the sprint. And really the job of Agile and Scrum is both. It's not just about turn the crank on the machine. In fact, I think it's unfortunate that there's a book title out there of twice. the work in half the time. I actually like to pitch this as more it's about twice the value with half the stress. Okay, now as you imagine that Mobius loop kind of overlaid, one of the things I'll unpack for folks is when you're way out in that vision area, there's a lot of uncertainty that's there, okay? And you're actually going to have to do discovery. You may have to run some experiments. Brian (24:58) Yeah. Bernie Maloney (25:24) Okay, and it's only as you get closer into delivery that you want to get closer to certainty. And really, that's kind of the job of a product owner is squeezing uncertainty out of the system. Initially through discovery of the problem to solve, who to solve it for, what the market is, but it's the job of the whole team in Agile to squeeze that uncertainty out of the system. Brian, I'm sure you've had folks like talk about spikes. You ever have people get wrapped around the axle about like including spikes in their product backlog? Brian (25:48) Yeah, for sure. yeah, for sure. Bernie Maloney (25:54) Cool, the way that I frame that up, okay, so here's a mental model. That's just technical uncertainty that you've uncovered. Great, okay, so now we've got to go squeeze that uncertainty out of the system. So stop getting wrapped around the axle on stuff like this. Just like stop trying to plan and predict things. Instead, kind of get into sense and respond on all of them. And there, I've kind of brought it around full circle for you, Brian, for where we started. Brian (26:09) Yeah, no. No, that's great. That's great stuff. And I love the fact that we can bring it back full circle. Well, this is fascinating. And like you said, we could press play and go on this for another half hour very easily. But we'll be respectful of people's time here and keep it to our normal time length. Bernie, I can't thank you enough for coming on. I really appreciate you sharing your experience with us. And... what you've learned over your years of working in this profession. Bernie Maloney (26:50) Thank you so much for asking me, Brian

Join Brian and John Barratt as they delve into the current state of the agile industry, exploring the impact of economic downturns on agile coaches and Scrum Masters, and discover innovative strategies to navigate these challenging times. Overview In this episode, Brian and John Barratt dissect the current state of the agile industry, focusing on the effects of economic downturns on agile coaches and scrum masters. They discuss the reasons behind organizational layoffs and cost-cutting measures, emphasizing the need for innovation to thrive during challenging periods. The conversation shifts to redefining the roles of scrum masters and agile coaches, highlighting the importance of delivering value and outcomes rather than merely facilitating meetings. John introduces two essential resources—the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics—to support agile practitioners in their professional development. The episode concludes with a discussion on the significance of mentorship and continuous improvement within the agile community. Tune in for invaluable insights and practical tools to enhance your agile journey. Listen Now to Discover: [1:08] - Brian welcomes Certified Scrum Trainer®, Certified Team Coach®, & Certified Enterprise Coach®, and host of the Clean At Work podcast, John Barratt. [4:42] - John reveals the core issues behind struggling organizations and shares how innovation can allow an organization to thrive during challenging times. [5:50] - Brian and John analyze the impact of economic downturns on organizations and agility, offering strategies to navigate these challenging times successfully. [10:04] - Brian and John explore the role of Scrum and Agile in an economic downturn. [16:08] - Join Brian and the Mountain Goat Software team for not only a Certified ScrumMaster® class but a full year of membership, learning, and support from Mike Cohn, Brian, and the Agile Mentors Community. You don’t have to lead alone. [17:09] - Brian poses an opportunity to expand the definition of done of Scrum leadership. [19:43] - John introduces the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics as powerful resources to help Agile practitioners and leaders enhance their skills and progress in their development. [23:42] - John shares the tool of Agile Scoping, based on From Contempt to Curiosity by Caitlin Walker, to lean into Scrum success within an organization. [32:25] - Brian shares a big thank you to John for joining him on the show. [33:04] - We invite you to share this episode with a friend and subscribe to the Agile Mentors Podcast. [33:57] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. [34:16] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. References and resources mentioned in the show: John Barratt Clean At Work podcast Scrum Events Meetup #93: The Rise of Human Skills and Agile Acumen with Evan Leyburn The Agile Army - John Barratt Agile Coaching Growth Wheel Agile Coaching Code of Ethics Agile Scoping From Contempt to Curiosity by Caitlin Walker Agile 2024 - The European Experience - Manchester Agile Coach Camp UK Certified ScrumMaster® Training and Scrum Certification Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Mountain Goat Software Certified Scrum and Agile Training Schedule Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is 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. John Barratt is a Certified Enterprise Coach® (CEC) and Certified Scrum Trainer® (CST), passionate about helping individuals, teams, and organizations achieve their best through agile coaching approaches. With a background in the military and a keen interest in systemic modeling, John constantly seeks new ideas and innovations to support organizational resilience and agility. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We are here for another episode of the Agile Mentors podcast. I am with you as always, Brian Milner, and with me today, I have a good friend of mine that I've been trying to get on the show for a while. Mr. John Barrett is with us. Welcome in, John. John Barratt (00:14) Thank you for having me Brian. It's been a while. We've been trying. We're here today. I'm really pleased. Brian (00:18) Yeah, very, very excited. John and I have seen each other at conferences for years. We've crossed paths. And I kind of jokingly said to him, I'm threatening to have a conversation with you not at a conference at some point. And that was kind of how we started this. For those who aren't familiar with John and his work, John works with a company called Agile Affinity. John Barratt (00:34) Hahaha! Brian (00:43) He is a certified Scrum trainer, a certified team coach, and certified enterprise coach. So he has the holy trifecta of Scrum Alliance certifications there from the guide community. He's a coach and trainer. Couple of interesting things. First of all, we'll talk a little bit about this, but John has his own podcast called the Clean at Work podcast that we can talk about here a little bit. But another interesting thing that he told me before, I didn't realize this, but John actually started in the military. So do you want to say anything about that? How long were you in the military? John Barratt (01:19) Yeah, so I was in the military for six years, joined accidentally when I was 18. So I went into the career office with a friend who was joining. And they were like, you're a bright lad, you can earn all of this money. So it was either go to university and getting lots of debt or join the army, get lots of training and get paid and see the world. So no thoughts of joining before that day accidentally joined. Did six years including a tour of Iraq. And the important thing about that for me is when I left, I felt really isolated. So Army is all about team, right? Team focus. Left the Army, was in IT, and it felt totally different. People were there stabbing me in the back, not supporting me. And then I found this thing called Agile, which was about teams again. And this thing called Scrum, where it was a team game. I was like, this is what I've been missing. Where's this been for the last two years since I left the army? And the rest is history. I did do a keynote at Central Agile Spain. I'm not sure what year, but it is on YouTube for anyone who's interested in hearing more about how the army is actually rather agile in my humble opinion. Brian (02:22) Yeah. That's awesome. We'll find that and put that in the show notes here. So if people are interested in finding that, they can go and watch that. John Barratt (02:45) Yeah, we'll have to dust it out of the archives. Brian (02:48) Well, yeah, yeah, I'm sure we can find it. But we were talking before this about our topic and I think this is going to be a topic that's interesting to a lot of people. Really, really kind of diving into the state of the industry right now and what we're seeing as far as the economy in the agile industry. You know, there's there's several organizations that have laid people off You know, there's there's less demand at the moment in the coaching kind of realm So kind of what's behind that the the shifts and you know What might be driving this kind of thing? So I know John you got some opinions on this. So let us have it John Barratt (03:18) Mm -hmm. Yeah, so I don't want to talk too much about the global economics. I don't pretend to be an expert on why we're seeing a recession. We can talk about, you know, COVID and the cost of that and also the war in Ukraine and, you know, all of the pain and suffering that that's caused much more than, you know, what we're seeing, which is, you know, a few people being laid off. So I don't want to go into that. But what I do want to really explore is, so if an organization is struggling, there's two elements. for that. Do they try and cut back as much cost as possible or do they try and innovate themselves out of that recession? Do they try and do something different and in a unique way? Unfortunately what I'm seeing a lot of is the first one which is cut back, reduce cost as much as possible and that's to the detriment of the the Scrim masses and and agile coaches that we see and I'm going to talk a little bit why they are the ones that often are in danger in a minute. Instead of where they should go, which my bias opinion should go, right? What I'm trying to do in the company that I run is to actually lean into that as an opportunity and try and innovate and see, well, what is possible in this new, exciting world that we're perhaps moving into? Where do we need to go when organizations are struggling? What are the opportunities, an example, AI that we've seen and what difference will that make in the next few years? I mean, who knows? Brian (05:14) Yeah, yeah, I think it's fascinating and you know, there's something I've talked about with some friends for several years and that is that I think there's sort of a, boy, I don't know how deep we want to go on this, but you know, you have a lot of executives now that get hired to come into a company and it's gamesmanship because the idea is I've got to increase our... our stock price by however many percentage points. And my bonus is tied to that. The more I can increase it, the more I get a bonus. Well, it's kind of like if you go to a team and tell them, hey, can you do more story points? They can certainly game that and all of a sudden have more story points. Well, the same thing with a short -term kind of executive. If you're in an organization and you're only going to be there for a couple of years, And you know your site is, if I can raise it three percentage points, I get a bonus. Well, there's a lot of easy cuts I can make that all of a sudden I've gone up three percentage points. But the long term of that company has not benefited. It's only the short term. And it just feels like, I don't know if it's a day trader thing, if that's really why this is kind of becoming more prevalent or not. But it seems like investing is kind of more of the short term. Now, and it used to be when you buy a stock, you'd buy it for 10, 20 years because you believed in that company and you expected to pay off over the long run. There's still a little of that, but it seems much more short -sighted. And I think that's trickled down to our, like I said, I don't know how deep we want to get on this. I think that's trickled down to our executives. And I think from the executive, that's trickled down to the employees. And that's really affected how... John Barratt (06:41) Mm -hmm. Brian (07:06) you know, when we've had layoffs and we've had downturns in the economy that just, hey, this is an easy way for us to show an increase in profits. John Barratt (07:15) Yeah, I think that's a really good point. It reminds me of Craig Lammon's laws, structure leads culture. And when we talk about structure, we don't ever just mean the hierarchy, we mean the bonus system, how people are rewarded and paid and all of those things. And so if you're rewarding shortism by giving these execs bonuses based on Brian (07:34) Yeah. John Barratt (07:41) profit for this year or as you said stock increase by 3 % then they will cut costs because what looks good for short term and for stocks is to have the minimum operational expense possible right if they can keep that as low as possible then that looks like a solid company because they're keeping controlling costs they talk about and and If they're working on margins and profits start to go down, which is what we're seeing as a trend at least UK, US, I can't say if it's completely global, but it seems like a large percent of the company and the organizations are going in that way, then what they do is to keep their margins so that they get their bonus is they start to reduce that, right? Because they need to keep that buffer. If they were to do what I'm suggesting, which is to lean into that and perhaps spend a little bit, spend some money to make some money, or at least keep it lying and try some innovative stuff, then that's high risk for them. Hmm. Brian (08:50) Yeah. Yeah, I've seen things before that have said that when there is economic downturns, that their evidence shows that the companies that invest more during the economic downturns actually end up increasing their positions to a much greater extent when the downturn starts to turn around because... John Barratt (09:02) Mm -hmm. Brian (09:14) they haven't just set idle or they haven't tried to reduce, they've tried to invest and now they're positioned to really take advantage of it once the economy starts flowing again. I'm not like you, I'm no economic expert, I'm no economist. So I don't know all the ins and outs of what's causing that. But it certainly has caused pain in our sector. And I think a lot of sectors, because I have I know lots of people who have gone through layoffs, not just in the tech industry recently. So I guess kind of the question that I ask about this as far as the agile community is concerned is, if we were delivering value, right? If it was undeniable that what we were doing was increasing profits, increasing value to our customers, I think that would make it a lot. harder for these kind of layoffs to happen. So I don't want to entirely say, hey, it's bad leadership, right? I think we have to take ownership a little bit. John Barratt (10:23) Yeah, and I'm going to say something I think is quite controversial here, which I actually blame servant leadership for this. So I know in the latest version of the Scrum Guide, we use the word true leadership, but I still like the word servant leadership. And I've actually changed my mindset and how I teach these things over the last few years because of this, because we've started to see this trend. Brian (10:28) Go for it. All right. John Barratt (10:51) And I've seen it in organizations where I've worked, I've left one year later, and then they've made all the agile coaches redundant. And I think it's down to how we use and perceive servant leadership. So historically, I was always, you know, Scrum Master or Agile Coach is the great person in the background. They let everyone else take the credit. They're there to help and support the team and to do all of that stuff, which is great, right? until someone with a balance sheet comes along and goes, what are all these scrum masters who aren't delivering any value, right? They're an overhead. They're seen as an overhead. Not delivering any value. No one can even tell me what value they've created. These developers over here, they're doing great. And the product owner is really maximizing the value of this product. But these scrum masters, they don't add any value. Because that's what we told them to do, right? We taught them to... Brian (11:29) Yeah. John Barratt (11:49) give everyone else the credit and serve everyone else and be in the background. So I think we've got a lot to blame, Brian, as trainers for, well, I don't know how you've taught it in the past, but I feel a little bit guilty. Don't worry, I've got the answer, but I just want to hear from you, what you, where you are with that one. Brian (12:04) No, no, no, no. Yeah. I'll tell you my opinion and you'll tell me if I'm correct or not. Yeah, no, I agree. I definitely think that's part of it. But maybe this will be a little controversial. I kind of spoke about this recently at the Scrum Gathering in my talk. In the trend that we've seen, John Barratt (12:15) Yeah! Brian (12:40) that I kind of talk about the diminishing of the perception of value of the Scrum Master. And I think that there's kind of multiple parts to that. I think part of it could be, hey, leadership doesn't really understand the value. But I think that there is a secondary part of that, that they're not seeing the value. And if they're not seeing the value, then I think that that's John Barratt (12:48) Mm -hmm. Mm -hmm. Brian (13:08) that rest on us. I think that we have to partly do a better job of helping them to understand it, but partly doing a better job of delivering it. And again, don't want to get too controversial here, but in our industry, in our training industry, You know, we've done lots of two day classes. We've done lots of things where we get people out the door and then they're in place and they're doing things. And the follow -up, you and I both know the follow -up is so important. You can't just take a two day class and then you're set for life. It's two days, but that's a kickoff and you got to continue that. and if I, if I take a two day class and I kind of slide backwards a little bit from that class and I get in and I'm a scrum master, there's, John Barratt (13:43) Mm -hmm. Yeah. Brian (14:01) Unfortunately, I think there's a lot of scrum masters out there who see their job as meeting scheduler. I'm here to schedule meetings, and that's the value I bring. Well, I can't blame a leader for letting that person go, because anybody can schedule meetings. It doesn't really take a lot of skill to do that. John Barratt (14:08) Mm -hmm. Yeah. Brian (14:26) The skills that we should be adding are those soft skills, the conflict resolution and understanding the personality types that make up our team. And essentially what I talked about in my talk was that first phrase of the Agile Manifesto, individuals and interactions over processes and tools. It's about individuals and interactions. We have to know the people that make up our team, not every team in the world, but our team. And we have to know. how they work best together. And I think people who do that, there's enormous value for that. So I would propose to you there's a shared blame, right? I think there's a blame there that we need to do a better job of showing the executives, but we also need to do a better job of actually providing value for the executives. John Barratt (14:58) Mm -hmm. Yeah. Yeah, yeah, I'm just, I was just, you know, I'm new to running CSMs and things like that. And one of the things I've brought in is a follow -up session. So, you know, a month after the training, they can have 30 minutes and we can talk about stuff. And that's really where you appreciate that the CSM isn't enough, right, to be a Scrum Master because you... There's only so much you can do, but the thing that always lacks, at least I haven't managed to perfect it yet, is those soft skills, right, which are the things that are important because you can't cover that in half an hour, an hour, right? All of those things are a full one, two, well, I'm being generous, just touching the sides with a one, two day course in some of those. And it's good to see the Scrim Alliance moving into some of those, you know, competency based or what they call skills based. courses where we can go a bit deeper into those key things. Because they're talking about, well, how can I do this? And in my head, it's obvious, but it's clearly not. So there's a huge gap between putting someone on a two -day course and thinking they can be a scrum master. And we do see a lot of bad scrum masters in the industry. And it certainly does cost everyone, even the good ones, some credibility. Right? Because... And if there's more ones, and it's not bad because they're bad people or trying to do a bad job, it's just that they haven't been equipped to do the job, right? Yeah, it's as simple as that. Brian (17:03) Yeah. At one of the tables I was at at the recent guide retreat at the Scrum gathering, we were having a discussion around this. And one of the things that kind of struck me as that was going on was, you know what it sounds like? It sounds like we don't have a stringent enough definition of done. Like when we think about someone who's you're now ready to be a Scrum master, well, that definition of done right now is a two day class. Right? And. John Barratt (17:22) Mm -hmm. Brian (17:32) I think we have to put in the expectation that, no, this is a component of that definition of done, but there's actually more that you need in order to, you know, this is an important role. This is somebody who is shepherding and guiding a team to be successful in this. So if someone's not qualified in doing that, it's no wonder that we see a bunch of bad scum out there because the person leading it isn't qualified, you know? John Barratt (17:38) Hmm. Yeah, and actually, I was just thinking an apprenticeship approach would be a much better idea, right, for this type of work. I often give the metaphor in my classes that agile coaching is a craft, Scrum Mastery is a craft. And imagine you're a carpenter, you don't get better at being a carpenter by reading lots of theory about good joints and all of this stuff. You know, you pick up a few things, you get better at Scrum Mastery or agile coaching. Brian (18:07) Yeah. John Barratt (18:29) by working and getting feedback. Our work is with the people, right? And people are a lot more complex than would, so we have to do even more of it to get any good. And of course, in carpentry, you wouldn't think about, we'll do a two -day training course. You would do an apprenticeship, right? And they do it for years before they become like a master carpenter. Yet we have scrimmasters after two days. Brian (18:58) Yeah. Yeah, no, I completely agree. And for the organization, I know when you've seen organizations that have sort of that layer, that hierarchy of we have Scrum Masters, but we have coaches, and we have enterprise coaches. When you have that kind of structure where you can have the phrase we use as mentor and be mentored. And if you can be in that place where you mentor others and you're also being mentored, John Barratt (19:21) Mm -hmm. Brian (19:28) That I think is really key to reaching the next level, to being able to kind of grow into what it is that you want to become in this industry. John Barratt (19:39) Yeah, I mean, I can't solve that problem very easily myself. You know, we've got a certified team coach and enterprise coach in the Scrim Alliance. It needs to be a bit more of a gap, I think, between that and CSPSM and we'll see what comes out in the next few years. But there is a couple of resources that I have worked on to try and help with this. So I've been on a mission to try and professionalize the world of agile coaching for at least five years. And the two things that I've found that have helped most people, is something called the Agile Coaching Growth Wheel, which you may have heard of. We'll put the link in the chat to that, which has kind of all of the competencies that we think you need in Agile Coaching, which is the set of competencies that a Scrum Master needs. So not Agile Coach, Agile Coaching, Scrum Master, Agile Coach, or any, you know, job title could be anything, right? It doesn't really matter. So that's a really useful tool. gives you all the areas, but it also gives you guidance, like a one to five guidance that almost uses the apprenticeship type thing. I can't remember all the levels, I think it uses like the Drift for scale, but it says at level one, you should be able to do these sorts of things. At level two, you should be able to do these sorts of things. And that gives people at least a starting point. You don't know what you don't know, right? Brian (20:58) Right. No, I think that's awesome. And we definitely will put that in our links and make sure that people can find that. Yeah, you're right. That kind of apprenticeship idea, I know that I could not have gotten to where I am without the mentors I've had. John Barratt (21:15) Mmm. Brian (21:18) And it's people who have, for no benefit of their own, have taken their own time to say, I'm going to invest time in this person and help them reach the next level. And I've tried to carry that forward as I've grown in this career as well, because I think it's important. I think we have to help the next group that's coming along. Yeah. John Barratt (21:44) Mm -hmm. I was thinking becoming a CST is almost like that apprenticeship type system, right? Where you have to do the co -trains with different people. They're like mentors, right? Different diversity, different types and groups. And you learn, both people learn from doing the co -train. And I think personally, it'd be a shame if they ever... Brian (21:54) Yeah. John Barratt (22:16) remove that concept because I think it's the closest we've got to an apprenticeship. Brian (22:21) Yeah. Yeah, and it works, right? I mean, I think that it does a good job of getting people to the level they need to be. There's still a lot, I mean, that doesn't do it all on its own, but it is, you know, I think anyone who's been through it, I think you would probably agree with this as well, is, you know, that was a foundational part of becoming a CST for me, is being able to observe and watch others and learn from them and... get feedback on how I was doing it. So I think you're right. That could be a very intriguing addition if there was someone who kind of incorporated that into the process. And I think that would give organizations kind of a confidence to say, I can trust this person. John Barratt (23:10) Which is what we really want with the CCCTCs, right? It's that stamp. I can trust that person. Second tool I wanted to highlight was the Agile Coaching Code of Ethics. So this was an initiative we did with the Agile Alliance. And the beauty of when we created this code of ethics, it was for people who were just starting out as well as experienced professionals. So you can read through that and that's kind of your rule sheet of Brian (23:25) Yeah. John Barratt (23:40) I'm new to this. This is the minimum standard we expect from a Scrum Master or an Agile coach in this industry. Because you don't know what you don't know again. But we've tried to make it as simple as possible. A simple list of these are the things you should definitely do if you want to be ethical in your work. Brian (24:00) Yeah. Yeah, that's a good resource as well. And we'll make sure we have that linked. Was there another resource as well that you wanted to mention, or is it just those two? John Barratt (24:12) So it's the Agile Coaching Growth Wheel and the Agile Coaching Code of Ethics. So we've talked a lot about the problem of where we're at, and we've given a couple of pointers. I wanted to talk a little bit about how I've changed my direction from this original kind of servant leadership type focus, which seems to be having some... Brian (24:36) Yeah. John Barratt (24:40) traction and benefit and value to people. And it's a couple of tools combined. So I created something a couple of years ago called Agile Scoping, which was based on Clean Scoping. So Clean Scoping is something that Caitlin Walker created based on Clean Language around how she scoped out a new piece of work. If you want to know more, then I highly recommend her book from Content Curiosity. Brian (24:44) Awesome. John Barratt (25:10) Bit biased, but one of the best books I've ever read. Not an agile book at all, but just a truly incredible story about how she's used clean language and something we call systemic modeling, which is using clean language in groups, with youths that have been kicked out of school, for example, and how they went from all individuals to suddenly kind of helping and supporting and understanding each other. Brian (25:31) Hmm, yeah. John Barratt (25:40) So great book. But anyway, Agile Scoping was based on that and it starts off with a discovery phase. We call that initial scoping, which is setting out kind of, is this work set up for success? So is the person in charge actually got enough influence over the system to actually make any change? So if you are doing Scrum. Do they have permission to actually change the structure into something that is actually going to help Scrum succeed? Have they tried different things before? And also this thing called congruency. So it's what they're saying aligned to what they're doing. So asking for those examples of, okay, you're saying that this, have you tried that before? Those sort of things. Very high level, just checking it out. And you can do that in an interview as well. So this isn't just for an external person. I always think that interviews should be two -way, right? It's not just a one -way thing. I want to check that if I'm signing up 40 hours a week or however many, that this is an organization that actually wants to be agile. I mean, I always put my hand out to the people on my training and people I meet at conferences where they're really struggling, right? And it's a really hard environment. And I always think, wow, you've got way more patience than I have. I really respect that. but my patients' levels are very low. So if I'm going to work with a client, I need to have a feeling that they can work at a pace, right? Brian (27:20) Yeah, right. Right. John Barratt (27:21) So that's level one and that's fine. Then we do an organizational scoping phase where you work with as many people as possible. You're looking at the problems that the organization says they've got, what the culture is now, where they want it to be, running some workshops, finding out what's happening. And again, we call it scoping because you can scope it to the level that you've been brought into. So if you're a Scrum Master working with one team and it's... One product owner, small product, that's fine. That's your scope if it's a whole organization, much wider. At the end of that, you create a coaching plan with the organization. So you have a session and you agree up to four outcomes is what I've found. So we move into outcome -based approach. So even if you skip all of the other stuff, what I would say is move away from any output thinking. As a scrum -rosterer, Brian (28:10) Yeah. John Barratt (28:18) even if it's just in your yearly appraisal, make it clear these are the outcomes that we're looking for. And these are more business related outcomes or things that are going to actually make a difference to the organization. So it could be things like make more money for the organization, could be increase employee engagement, increase customer engagement, number of active users in your mobile app, whatever those are. But they're nothing to really do with Agile, they're to do with... Brian (28:42) Yeah. John Barratt (28:47) that the organization wants to set. Those go into a coaching plan. We have a coaching agreement canvas that you can use to put all of that in. And then it's really clear, like these are the things that I'm going to help and support you with as a Scrim Master or Agile coach. There's a bit more risk, right? Because if you don't meet them, then you've got to have a conversation, but at least then it's visible, right? These are what I'm saying I'm going to help with. This is what you've said you want help with. And now we're going to do a number of experiments to try and get there. And that's where we get into that continuous improvement cycle of trying to involve, adapt, inspect, work on all of those things that are happening within your team, within your department, within your organization, depending on where your scope is, constantly evolving and looking at. where we're at. We might have some lead -in indicators as well, perhaps in there to help us cycle time, lead time, throughput. Those can be useful, but really we're looking at end value and we're measuring our performance of a Scrum Master Agile Coach based on the value being given. We're not letting the product owner take all of that praise and credit. Of course, we don't want to be too arrogant and go too far the other way. It's a team effort. but we're at least putting our, you know, more, I think skin in the game is the thing. What I've seen in the past is, you know, bit of a puppy dog type thing, Scrum Master, ooh, shiny over here, great, shiny over there, no, skin in the game, this is a partnership, and we're gonna work on this together. Sorry, I spoke for a long time, though. Brian (30:16) Yeah. Love that. No, no, no. I love that. You were saying great stuff. And I mean, I love the bit about outcome -based kind of approaches to it. I think that's really, really important. I've always thought, you know, like the performance, I'm always really hesitant about performance -based kind of metrics. And I always want to shift more to output outcome -based kind of metrics, not output. And I think that because that's, You're right. A business doesn't care how agile we are. A business cares if we're increasing our bottom line, if we're increasing our membership, all the business goals that you might have. That's what they care about. And agile -ism means to that. John Barratt (31:17) Yeah, I have a big shiver when teams have like agile maturity models. Like the word maturity, first of all, like if I say to you, Brian, you're immature, Brian. You know, that's just like, why would you do that? And also if I, you know, it's many people have said agile is never the goal, right? We're never trying to be agile for agile sake. We're doing it to help organizations and, you know. Brian (31:23) Ha ha ha. John Barratt (31:44) Therefore, why would you want to know how mature a team is when that's not actually that important, right? Could be a very leading indicator, perhaps, of where you're trying to get to, but it scares me when I see those sort of things. Brian (32:04) Yeah, this is great. This is great stuff. And there's so I mean, from what you've said, there's so many good links that we're going to be able to put in our show notes for this. We'll also, by the way, make sure that people can get in touch with you, John, if they want to follow up and learn more individually from you, because that's always really important here as well. And I know it's conference season. There's a lot of conferences going on. And you were telling me you're going to be at the Europe. John Barratt (32:12) Mm -hmm. Brian (32:33) Agile 24 conference, right? John Barratt (32:36) Yeah, so I've decided to do my part for the environment and not fly out to America for the third time this year. So I'm going to be in the Agile Alliance Manchester in July. I'm doing two sessions there. One looking at product refinement using clean language and the other one how to help and support self -managing teams with Caitlin herself. So if you like the idea of the stuff I was talking with Caitlin. and that's the session for you. Also going to be in Agile Prague this year, Agile Coach Camp UK, which I run, but unfortunately that is full. So there is a waiting list if you did want to try and sneak into that. And I'm sure I'll be at a few other places as well. There's also my monthly meetup that I run with a number of other colleagues called Scrum Event. It's actually the second largest Scrum Alliance user group in the world. Brian (33:33) Awesome. John Barratt (33:34) and we tend to have some pretty cool speakers there, so watch out for that. Brian (33:40) That's awesome. Yeah. We'll try to link to all of that so that people can find it. But yeah, if you're going to be at any of those conferences or if you're on the fence about going to the conference, you can hear great speakers like John there. So make sure that if you do, that you go up and say hello and tell them that you were listening to the podcast and heard this and were interested. And that's why you're there. Well, John, I appreciate your time. We're recording this on a Friday afternoon for you. And I know that's really precious time at the end of a week. So I really appreciate you giving us your time here and sharing your knowledge with us. John Barratt (34:19) Thank you for inviting me and having me. It's been a blast. Brian (34:24) Absolutely.

Are Scrum & Agile Dead? - Mike Cohn I've always said I wanted Scrum and agile to go away.Is that happening? I don't think a week passes without some article about their deaths appearing in my browser or email.Within a few years of the Agile Manifesto being written, I began to say I wanted agile to go away. I didn't mean I wanted us to stop using them. Rather, I want them to win.I want agile to become so much the accepted approach to product development, or to teamwork in general, that we could stop talking about it.Instead of saying “agile software development,” for example, I could just say “software development” and the assumption would be that, of course, that meant agile software development.To some extent, we're there.Changes Accelerated by AgileWhen Scrum emerged as the original agile framework in the mid-1990s, cross-functional teams were not common. They are now.Software development back then was done in phases—typically an analysis phase followed by design, coding, and testing phases.Heavy duty, pixel-perfect prototypes were common back then due to the high cost of iterating over a design. While prototypes are still used today, multiple quick prototypes are now common to help product owners and managers choose between options.Before the advent of agile, organizations thought they could add quality to a product by testing quality in at the end. Agile has helped us see that isn't true.Barry Boehm's spiral model (1986) and Tom Gilb's evolutionary delivery (1988) had started a shift to iterative, incremental development. But that shift accelerated dramatically after the Manifesto in 2001.(Did you know I named Mountain Goat Software after a sentence in Tom Gilb's book?)What I Hear about Agile TodayRecent articles and podcasts saying agile is dead are not saying we need to reverse the improvements agile initiated or accelerated.I haven't read anything advocating a return to waterfall development or, more accurately, the ad hoc development practices that were more common before agile.Instead, the “agile is dead” articles more closely mimic my long-held view that we can eventually stop talking about agile teams, agile development, agile frameworks and more. They'll just become teams, development, and frameworks.So are agile and Scrum dead?I don't think so.I think there's still plenty of work ahead. It's why we're focusing more attention toward whole-team training.Some of the agile and Scrum fatigue I sense today is analogous to what happens in the music industry. Fans who love an artist's first few albums often sour on that artist when they're discovered by the masses. The artist is no longer the hip, new thing and many early fans move on because of that.I will be happy when agile wins, when we can drop it as an adjective in front of so many terms. Until then I will remain dedicated to helping teams succeed with agile, How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Join Brian Milner and McCaul Baggett as they explore the power of empathy and storytelling in successful Agile transformations. Learn McCaul's five-step approach to effective communication and discover strategies to overcome common pitfalls in organizational change. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with McCaul Baggett, Chief Agile Officer at CAVU, to discuss the intricacies of communicating change within organizations. They delve into common pitfalls in Agile transformations and highlight the importance of empathy and storytelling in engaging teams. McCaul shares his five-step approach to effective communication, emphasizing the power of testimonials and spreading awareness. Tune in to gain valuable insights and practical tools for navigating and leading successful Agile transformations. Listen Now to Discover: [1:10] - Join Brian as he welcomes McCaul Baggett, Chief Agile Officer at CAVU and a master of Agile transformation, to delve into the secrets of successful Agile transformation. [3:15] - McCaul emphasizes the critical role of storytelling in engaging and guiding teams through the process of Agile transformation. [5:57] - Brian addresses a common challenge in Agile transformations: navigating the unknown and its impact on team dynamics. [8:01] - McCaul explains how effective communication and a compelling narrative can help teams grasp their value during a transformation. [10:40] - McCaul advocates for going beyond the basic 'why' by incorporating testimonial narratives to create more meaningful connections. [14:39] - Brian suggests using these tools to foster empathy, advocating for their use in both top-down and bottom-up approaches when initiating a transformation. [16:29] - Dive into Mike Cohn's book, Succeeding with Agile, for practical advice on navigating your transformation. Discover strategies for communication, overcoming resistance, and other key aspects of Agile success. [17:54] - Brian inquires about effective ways to connect with and engage resistant individuals within the team. [22:49] - Join McCaul and Brian as they discuss the importance of creating specific best practices that suit the unique needs of this particular team and organization. [28:07] - Brian shares a big thank you to McCaul for joining him on the show. [28:33] - Join Brian in attending Agile conferences to connect with and learn from Agile experts and peers, fostering valuable discussions and insights. [29:53] - If you’d like to continue this discussion, join the Agile Mentors Community. You get a year of free membership into that site by taking any class with Mountain Goat Software, such as CSM or CSPO. We'd love to see you in one of Mountain Goat Software's classes, you can find the schedule here. [30:35] - We invite you to subscribe to the Agile Mentors Podcast. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: McCaul Baggett Communicating Change Made Easy with McCaul Bagget and Tom Bullock Succeeding with Agile by Mike Cohn Agile 2024 Subscribe to the Agile Mentors Podcast Certified ScrumMaster® Training and Scrum Certification Certified Scrum Product Owner® Training Mountain Goat Software Certified Scrum and Agile Training Schedule 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 podcast@mountaingoatsoftware.com 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. McCaul Baggett is the Chief Agile Officer at CAVU, specializing in Agile transformations and effective communication strategies. With a focus on empathy, storytelling, and practical tools, McCaul helps organizations navigate change and foster sustainable Agile practices. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors, we're back. This is another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today I have the one and only Mr. McCaul Baggett with us. Welcome in McCaul. McCaul Baggett (00:13) Hey, thanks Brian, really glad to be here. Brian (00:15) Very excited to have you. For those who aren't familiar with McCaul, McCaul is the chief agile officer at Cavu. He has been working in transformations for quite a long time doing some large-scale transformations at different organizations. One that he is allowed to publicly mention is John Deere, but there's others that he's been a part of as well. You know companies are funny that way. They don't always necessarily want you to publicize things for some reasons. I don't know why. McCaul Baggett (00:43) Yeah. Brian (00:44) We were joking about that earlier. But I wanted to have him call on because we were both at the Agile 2023 conference, and I saw him on the agenda, and it was one of those sessions I didn't get a chance to go to, unfortunately, but really thought it was an interesting topic. I wanted to have him come on and kind of chat with us a little bit about this. So his topic was about communicating change and communicating change in an easy way, you know, kind of making that an easy process. So let me start there with you, McCaul, on this is, what do people get wrong when they're going through a transformation and we make the decision to go through a big change in our organization? What are some of the common pitfalls organizations fall into when they make that decision? McCaul Baggett (01:34) Well, let me start by saying it wasn't me solely that was doing the talk. I did have some partners there with me. And if you look it up, you should definitely speak to them as well or look them up as well. Dana Dismukes is a transformation lead for Dell. Tom Bullock is the chief storyteller for Scrum Inc. And really the academics of the talk came out of Tom's brainchild. But through my work, I got a chance to apply it. And it was precisely because of this very issue, the ch- the- non-working approach that many organizations take to communicating about change. There's a tendency in a lot of change management structures to discuss the need for communication, but as Agilists, we don't inherently do a lot of study of the nature of communication. And so I would say probably the biggest, most common error that people in a transformation of any kind and most close to my experience in Agile transformations make in communicating about change is going about it from a way that is, from the perspective of trying to reassure their teams, their departments that this is something that has leadership endorsement by communicating from the top down. I mean, please forgive the hierarchical metaphor, but getting some senior leader to say, hey, this is gonna be great, you can do it, we're gonna do this. When in fact, the most effective way to communicate to someone, especially someone who's not fully bought in, is by telling them a story of someone who is like them, has experience like them that they can relate to. And that storytelling perspective is what we talk about in this talk, Communicating Change, maybe. Brian (03:16) Yeah, there's a lot just in there to unpack. I mean, just the idea, thinking about, I've talked with a lot of organizations and a lot of people have come through classes and stuff that I've talked with who are going through changes like this, but then they're not really even sure how much their leaders are on board with this. They just, they have some layer of management who says, yeah, this is what we're gonna do, but do the people at the top really feel that way? Do they even know what it is that we're doing? McCaul Baggett (03:34) Sure. I mean, that's even tougher. I would find it hard to even consider it a true transformation if you can't be sure your leaders are bought into it. But you're not wrong. It is stunning how often you get these folks that you run into and they say, my leadership may be willing to do this. I teach a lot of Scrum at Scale. And so we talk a lot about executive Metascrums and executive action teams and prescriptions about how involved the leader should be. And people will sort of stop and say, wait, you want a leader to meet about team obstacles every day? And I say, yeah, or however long those executives are willing to let their teams go without support to removing their obstacles. Like, what is it that they're doing that's more important than clearing the impediments for their teams? But that does tend to be the perspective is, I don't know if my leaders even bought into this change. That's tough. Brian (04:34) Yeah. Yeah, it is. And I think that speaks to some of the fundamental flaws, I think, that people have with transformations before you even get to communicating, right? Just do we know why we're here? Do we know what it is we're trying to do? Those kinds of things. I like to focus on the communication, though, here because communication is such a McCaul Baggett (04:46) Yeah, that's true. Brian (04:56) delicate beast. I mean, it just, you know, when you're trying to speak with another human, even if it's just within your team, you know, it's difficult because we're different personalities and we have different backgrounds and everything else, much less when you're talking about it over an entire organization. I would imagine, and you, I mean, correct me if I'm wrong on this, but I would imagine that one of the biggest sources of kind of consternation or, you know, anxiety I think when these kinds of things happen is the unknown, just not really understanding how do I fit in and what does this mean for me. McCaul Baggett (05:33) Yeah, I think you're absolutely right. Sometimes it's phrased that it's termed what's in it for me. And I think that's the wrong perspective to take. People aren't often necessarily, people are not always looking for some kind of payoff for the transformation. They don't need to know sort of what they get out of it. But I think that you really put your finger on a lot of the reason that we see trepidation with a transformation is because it implies that Brian (05:38) Mmm. McCaul Baggett (06:00) Business as it had been occurring before was not acceptable. What you'd been doing previously was not good enough. And now we need to get you to do it another way. That inherently sort of fundamentally starts with a position of questioning whether or not your position is stable. And that gets, you get some amygdala hijack stuff going on. You get the brain started worrying about existence, not just change. So you're right, contextualizing. Brian (06:26) Yeah. McCaul Baggett (06:29) your communication about this is really important. And I think taking a perspective of empathy and meeting especially resistance in a change environment, a changing environment, meeting resistance with an attempt to understand the perspective really fundamentally underpins any successful communication you're gonna have about change management in general, but communication in particular. Brian (06:52) What do you think about that, McCaul? I mean, if you're a leader in that kind of organization and you recognize this and you see, people are gonna, I'm gonna send people into a little bit of a panic, right? Because you're right, there's no way that I can hear that message, hey, we're gonna do things differently than the way that we've been doing them without kind of self-internalizing, well, that means that something I've been doing has not been acceptable, it's not been good enough, it's not been what the organization needs. How do you communicate that in a way to say, no, it's not you, right? It's kind of a process thing. It's not that you did anything wrong. It's that we found this is a better way of working. McCaul Baggett (07:30) Yeah, so I think starting with that fundamental basis of why this is occurring is really key. But even before you get to the communication about why, it's really important to figure out who it is you're speaking to. So going back to that sort of, that empathy piece, there is a need to get that communication about, okay, it's not that you did anything wrong. and here are the reasons why we're doing it, that is the message we're looking to communicate. But at a communication level, like understanding even how to begin that communication really requires us to take a step back so that we can consider the people we're telling that story to. So just to connect this to the topic that actually came up in the talk about how we do that communication, it's really fundamentally about, and just a quick aside about that talk. So in the Agile 2023 conference, we actually applied for a longer workshop, like 120 minutes, 160 minutes, one of the long time boxes. And they'd come back to us and said, why don't you do one of these 30-minute segments? So we really pared down a lot of the things that we wanted to say. And so to connect back to what really, what emerged was actually, it was actually probably a better talk than if we'd had a longer period of time to do it. We just, we had to cut everything until we could come back with just, Brian (08:36) Yeah. Hahaha. Mm. McCaul Baggett (08:58) the real good nuggets. And what stayed was this. In order to communicate effectively when you're going through any kind of change management process, first of all, having a change management process and a plan for how you're gonna manage that, that's your beginning. But to get a little bit more particular about how we communicate about that change, there is one technique which we agreed was probably the thing to focus on so that it would be most universally helpful. in any stage of a transformation that was going on. And that was creating a, finding a way to create a narrative, a personal narrative that could connect to the various people that you're trying to connect to, right? So to create a testimonial. And so we spent our time in that talk discussing how to really get a useful testimonial. And then once you've... got that how to do something useful with it. And we outline kind of five steps for how to think about this. Brian, tell me if I'm getting too deep or you kind of want to... Okay, cool. And I don't know that these are the only five steps. We try to make it easy to remember. The takeaways that we were trying to give were, you have to be first thoughtful about what it takes to make a compelling testimonial. So this is where I mean, you can't start with why. Brian (10:00) No, no, this is awesome. Go for it. McCaul Baggett (10:21) we're doing this, you have to start with who you're speaking to about why. Because the why shifts. If you're speaking to stakeholders, there's one why. And if you're speaking to the organization, to your employees, to the people that are doing the work, it's not that the why is different, but the way that you talk about it may be different. So once you know what it's going to take to make the testimonial, the next step would be to think about how you can work. how you can set yourself up ahead of time to maximize the potential to make an impact with your audience, to plan. how you're gonna get the story, the testimonial that's gonna resonate. Which is the story that I wanna tell? So fundamentally what we're doing here is we're assuming that, testimonial, this is only one way to communicate, but it's a fairly useful one universally. If you're going to try to get that testimonial, what are the questions that are gonna be useful to the who that you've identified ahead of time? What is the story you need to find to tell? Then step three is actually. having the conversation. So you've already done a lot of pre-work ahead of time before you even begin the process of the discussion. And then once you've started the discussion, once you've got it, using that testimonial, which is typically recorded kind of like this, grounding that in a way that doesn't sound overly positive and really connects with reality, and then using what you've got to spread that awareness as broadly as possible. So five steps. Know, think, get. ground and grow. I don't know if that's a useful mnemonic of any kind, but that's what we came up with. Brian (11:59) That's awesome. No, like I said, easy to remember. Just a few things to kind of keep in mind there. Yeah, I love the concept of telling it as a story, that we're not just, because that makes it much easier for me to see myself then fitting in there. Like we talked about earlier, right? If I have a fear of, oh my gosh, does this mean that I'm gonna lose my job? Does this mean that I'm gonna have to... McCaul Baggett (12:03) Yeah, just five steps. Brian (12:24) now do something that's very different from what I've been trained for or what I'm used to doing or what I wanna do as a career, telling it as a story can kind of allow me to see myself in the story. McCaul Baggett (12:37) You are exactly right. Not only does it allow you to do that, we as humans are wired to do that very thing. We do it all the time. In fact, when you're listening to a podcast like this, you'll often sort of have the sense that you're sitting at the table, thinking through, like you're literally exercising pathways in your brain as if you were participating in the conversation. And that direct involvement allows you to mitigate some of the inherent resistance that you. that you find, that amygdala hijack, that fight or flight response is not present because you're following along in a story, hopefully about a successful element of the transformation. So you really engage that piece right from the very beginning. Brian (13:20) Yeah, I love this and understand to the listeners as well, right? I mean, we're speaking at like a neuroscience level here and trying to understand that, you know, the preparation that needs to be made so that, uh, like McCaul is saying, there's not that amygdala hijack going on of just saying, uh, oh my gosh, I'm panicked. I can't get past this panic. Uh, you know, in my, that's going on in my head that has to be stripped away. That has to be. resolved so that now I can start to learn, now I can start to see and form, like you said, the new pathways. And that is, you know, physically what's going on. We're forming new connections in our brain to say, oh, I've never seen it this way, but let me try to make this connection and see it a different way. McCaul Baggett (14:10) Yeah, not only is it important to do that, we as humans, now I'm stepping a little far beyond my training, so I'll be careful. My understanding is that fight or flight response really lives in an entirely different system, in the limbic system of the brain, much earlier part of the brain. And in order to engage the neocortex at all, or in any significant way to create those Brian (14:21) Ha ha ha. McCaul Baggett (14:39) pathways to be able to see a perspective of the other than our own, we have to kind of dampen that limbic response, that fight or flight. Will I, won't I have a means to feed myself beyond this space? Am I safe before we can start to begin that conversation, to begin that connection with someone we want to connect to? Brian (14:59) Absolutely. And I think this applies not only, I mean, we started in kind of approaching this from sort of a high level top down, like you said earlier. But I think it applies even if you're a Scrum Master, or maybe you're part of a small group in the organization. Maybe you are in an organization that's not agile in any way, but you've gotten permission to have a pilot, to just have a pilot team. McCaul Baggett (15:08) Sure. Brian (15:28) and your desire is to grow this in the organization, or maybe they're doing it poorly and you wanted to have one pilot team that does it the right way so you can start to spread this out to other places. All this applies, I think, to you as well because you're gonna be communicating this and you're gonna encounter the same resistances, right? You're gonna have the same kind of skepticism. You're gonna have the same kind of possibility have someone have amygdala hijacks going on thinking, Oh my God, what's this guy doing? What's this woman doing? Why is she trying to make these big changes in the organization? Is she gonna try to change my job? Yeah, am I under threat? So while we started top down, I think it applies bottom up as well. They're all principles I think we have to think through before we even start to try to communicate with this. McCaul Baggett (16:05) Yeah, am I under threat? Oh, absolutely. I mean, any good scrum master is gonna be thinking and hopefully practicing their ability to deal with any tense conversation. And so that limbic engagement, that epinephrine and adrenaline start coursing through the brain. And you can see it in many people when you're looking at group dynamics, regardless of large or small group dynamics, but any group. that shutdown of the ability to really process new information and assimilate it, you have to start by working past the threat. You have to get people beyond that sort of defensive place before the conversation can even begin. Yeah, I agree. Brian (17:01) Yeah, yeah. Awesome. Well, in how we're talking about this, I kind of had this one scenario in mind I wanted to kind of run by you because I know I've encountered this before. I know, you know, I've encountered this in classes before. So I'm curious kind of how this communication approach would kind of adjust for this kind of individual. But what about the person who just sort of is crossing their arms McCaul Baggett (17:11) Sure, hit me. Brian (17:28) And they kind of take the approach of, ah, this is a fad. It's not so much as an active, hey, I'm gonna really counteract you and go against you to try to dispreview, but I'm just gonna, you know, I'm not budging. I'm gonna stay here, because I know this is a fad and it's gonna change eventually back to the way I wanna do things. So you do whatever you wanna do, but you know, I'm not gonna get on board with you because. I've seen lots of things come and go on this is just another McCaul Baggett (17:59) I think that takes a couple of forms. Certainly some of those, and particularly when I've been asked by an organization to come and do training, you get a lot more of those because, nope, they didn't raise their hand to come and join a public class or something. I think there's really two significant flavors of that engagement. One is, as you described, someone who's just sort of like passively waiting for this to sort of blow on by. And that's a lot more tricky than the one that's actively pushing back. By far, I prefer someone who's willing to stand up and say, this is not going to work here and here are the reasons why. Because to come into the space of someone who is not choosing that engagement is inherently threatening. So you've picked a very challenging person to get through to, um, because directly calling them out and being like, Hey, Brian, you've been really quiet. What do you think of what's going on? when they were not inclined to share that, sort of already starts to engage that, am I prepared to risk saying out loud what I think is gonna happen? And it also, it could inherit, it could just by the nature of asking them to speak out loud that they don't believe in what's going on around them, sets them apart from the rest of the group and could mean that makes them something of a target if they don't feel like their culture is a safe place to speak. So, That is your problem Often I have found that a testimonial based approach, one where you can tell someone's stories about someone in a similar position, not stories about why this is going to work from a leadership position, but a testimonial based communication campaign is one of the best ways to reach folks just like this. You don't need to directly address them. You don't need to confront them. It's fine. If you're not, if you're not buying this, that's okay. Why don't I tell you about where it's happened elsewhere? And frankly, that thing is one of the things that training in person used to be so great for, because you could stand away and kind of watch these people who weren't necessarily bought in, sit back and just study what was going on in front of them. It wasn't being forced on them. They could just sort of watch their teams and you'd do something silly like. Brian (19:58) Yeah. McCaul Baggett (20:17) play any number of the Agile games that are meant to demonstrate things like small batch processing or teaming, right? Team dynamics and that joy that human collaboration and competition can bring in a really small scale in a very short amount of time and like a magic trick you could be like was that fun? Was folding these paper airplanes and throwing them across the room fun? And they'd be like yeah it was fun it's paper airplanes whatever I'm not working and then you could take a step back and say okay Was it fun because you just love folding paper airplanes or was it fun because you were making connections with people that you don't get to do in your daily job? And just sort of, again, the story here is, look what's over there. Look what this says about the nature of communication. It's not testimonial based per se, but it is lighting that fire, that inspiration that I always loved about training. And it's not just in person, but it really... I do miss that about in-person training because you could really connect really well. Brian (21:19) Yeah, I mean, we're talking about communication in general and we can't escape the Agile Manifesto comment about it. It's best done in person face to face, right? So it doesn't mean you can't in another way, it just means it's best that way and it works easiest that way, right? Yeah, I completely agree. Yeah, I just wanted to just, go ahead. McCaul Baggett (21:28) That's right. That's right. I'm sorry. Not to go too far off topic, though, but to that very point, we see this request of many executives later, the return to the office movement being another form of, is that the best way to communicate? Yeah, it is. Is it the only way to communicate? Should we be seeking that to the detriment of our work forces at scale? And there are many reasons that people are choosing to encourage their. employees to come back to the office. But I think part of that is because leadership is also far easier in person. So we're missing some opportunities for leadership to understand how to lead remote teams and may have caused that sort of same challenge. Anyway, another topic. Brian (22:23) No, no, I agree. And I think that part of that as well is just kind of the general whole. I've talked about this a couple of times in the podcast where we, we seem to be stuck in a cycle of trying to find out what is the way to do something versus what is the way for this team, for this organization to do something. There's lots of data out there that we can get, can inform us. Just like if I'm a product owner. There's lots of data that can inform me about the market, but ultimately I've got to make the call about what's right for us to do next. Same thing with the organization, same thing with the team. What's going to work in this instance? McCaul Baggett (23:03) Absolutely. It's probably one of the biggest challenges that I think, uh, when we see transformations, not even transformations, when we see an agile, um, enthusiast really go off track and good. I did it for sure when I was a new scrum master. Like this is how the scrum guide says we're supposed to do things and we're not doing these particular things. We need to do scrum the right way. that sort of the willingness to take a step back and say, well, there are a lot of better practices. Is there a best practice in our case that is true? Actually, the challenge is not, is there a better practice in all cases? And almost certainly not, but there may be a better practice in our case, even a best practice in our case, but you have to be willing to let go of the dogma of this is the way it's meant to be, and instead seeking, seeking to be informed by these, yes, science-based studied practices. It is better to be in person, but let's not fire all our remote employees. Let's, let's figure out another way or let's make teams that can figure out other ways to do it. Brian (24:11) Yeah, absolutely. Yeah, we're in an interesting time, I think, as far as that's concerned, because like you said, it's the dogma, I think, of pragmatism and what's gonna work best in this scenario. Yeah, I struggle a lot in classes, even, when people will bring up certain topics, to ever say always, that this is always, it should always be this way. McCaul Baggett (24:22) Yes. Yes. Brian (24:36) Because I don't know, I frequently will say things like, my experience has been, what I have seen is this, but that's just my experience. And that's a limited set of experiences. You have to line that up against what you've experienced and what your organization is going through and say, hey, does this sound similar? Are we seeing those same things? Are we not seeing those same things? There are best practices. There are some things that we could say, yes, this... And a lot of situations will work best in this way, but not all. And that's where it takes experience. That's where it takes somebody who's been there before to know. McCaul Baggett (25:16) Well, yeah, and a lot of this grew up in a very particular environment, right? So Agile practices, many of the ones that we've adopted, grew up through software, and through software in North America. So one of the things that I've been passionate about, and one of the reasons that I've pursued the career that I have is because a lot of the Agile community looks like you and me, right? So if you take into account not only are these the, quote, Brian (25:29) Ha ha. McCaul Baggett (25:43) but it's for teams that tend to look like you and me, tend to live in North America, and tend to be working on software. And that's such a narrow area that we're foolish to assume that such a thing as best practices have been codified yet. Brian (25:58) Yeah, no, and please, for the listeners, don't get me wrong because if you listen to the show, you know I'm a geek for the data. And I love being able to have really hard scientific data that you can look at and say, hey, studies show that this is how you do this, but you gotta be cautious about asking, was that a rigorous scientific actual study or was this just an internet sampling? McCaul Baggett (26:13) Yes. Brian (26:26) That's not a scientific study. That's just kind of gathering people together and saying, hey, if this group of people who choose to respond to this, what do they think about something versus something else? But you're absolutely right. You have to understand the basis of where this comes from. And the basis of where we get a lot of our stuff is people who look like you and me, who have been working in the software industry for kind of the time we've been working in the software industry. So things have changed. McCaul Baggett (26:50) Yeah. Brian (26:53) cultures change, cultures bring different dynamics into things. And what works for my team of five, six developers based here in Dallas, Texas, is going to be very different from my team that I have five people in India and three people here, or even all the team is in India, or all the team is in Malaysia, or all the team is in Saudi Arabia or Ireland. I've worked with teams all over Israel. McCaul Baggett (27:09) Yes. Brian (27:23) You work with teams in different cultures and you have to understand what the playbook I used for that last team ain't gonna work for this next one because they're different people. McCaul Baggett (27:32) I heard the term coined radical pragmatism. It was, JJ Sutherland said it. And it was, it is precisely what we should be shooting for. Radical pragmatism informed by the best data, informed by the best science, and then immediately thrown away when it's not applicable to the situation we're in. Yes, these are the ladder, the rungs, the steps to head in the direction we need to be headed, probably, but let's evaluate them for ourselves and reevaluate. Brian (28:02) Yeah, if you're gonna go buy a car, you're gonna do your research, you're gonna figure out what gets the best gas mileage, blah, right, all this stuff. But then you're gonna get on the line, you're gonna test drive and go, I just like the way this feels. Ha, ha, ha. McCaul Baggett (28:12) That's right, test drive the car, yes, for sure. Brian (28:16) Awesome. Well, this has been a great conversation. I really have enjoyed having you on, McCaul. And yeah, thank you for kind of sharing kind of some of the wisdom in there from the talk. I know we, you know, the talk was not long and we have not long to kind of dissect stuff here in our podcast, but I appreciate you making time to share with us. McCaul Baggett (28:36) Absolutely, Brian, this is a pleasure. And if you ever need somebody to shoot the breeze with again, give me a call. Brian (28:42) I will take you up on that. McCaul Baggett (28:43) Thanks.

Are YOU Looking to Take the Exam? Sign up: http://HPMEXAM.com

It's the season finale of Elixir Wizards Office Hours! SmartLogic's Project Manager Alicia Brindisi and VP of Delivery Bri LaVorgna join host Dan to delve into the agile ceremony of retrospectives. They explore the vital role of retrospectives in Agile project management and unveil practical strategies for enhancing their effectiveness. Alicia and Bri break down the elements of a successful retrospective. They cover everything from meticulous preparation to facilitation techniques, and how to choose the best format for fostering open dialogue and actionable results. Learn how to navigate common obstacles and guide discussions toward productive, solution-focused outcomes. Throughout the episode, they emphasize the transformative potential of retrospectives within the Agile framework, portraying them not just as a procedural activity, but as a catalyst for continuous team growth and project success. Key topics discussed in this episode: Mastering the full potential of retrospectives in Agile environments Best practices for effective preparation and facilitation Choosing the right format to suit your team's dynamics Strategies for overcoming typical challenges during retrospectives Techniques for addressing and resolving interpersonal conflicts constructively The critical importance of valuing each team member's perspective Practical advice on applying insights from retrospectives to enact organizational changes Tailoring and refining retrospectives to meet your team's unique requirements Links mentioned: SmartLogic https://smartlogic.io/ SmartLogic LinkedIn https://www.linkedin.com/company/smartlogic-io Contact Bri Bri@smartlogic.io Retrium Retrospectives for Scrum & Agile Teams https://www.retrium.com/ 4Ls Retrospective Template https://www.retrium.com/retrospective-techniques/4ls Start Stop Continue Retrospective https://www.retrium.com/retrospective-techniques/start-stop-continue Sailboat Retrospective https://www.retrium.com/retrospective-techniques/sailboat Starfish Retrospective https://www.retrium.com/retrospective-techniques/starfish ClickUp Project Management Platform https://clickup.com/teams/project-management Asana Task Manager http://www.asana.com Jira Project Management Tool https://www.atlassian.com/software/jira  Special Guests: Alicia Brindisi and Bri LaVorgna.

In this episode of the WLEI podcast, LEI speaks with software industry veteran Robert Martin. Robert is one of the original signers of the Agile Manifesto and the author of several influential books, including Clean Code: A Handbook of Agile Software Craftsmanship.  During the conversation, Robert shared insightful perspectives on some of the biggest challenges facing software development today. From the demographic problem of perpetual inexperience to his pioneering approach to development dubbed "software craftsmanship" that aims to promote quality work, Robert covered a wide range of issues impacting the industry. Some other topics discussed include: Balancing speed and quality in development and emphasizing a quality-first mindset. The benefits of test-driven development, such as providing freedom to change code safely. AI's potential impacts and appropriate uses of AI-generated code. Be among the first to get the latest insights from LEI's Lean Product and Process Development (LPPD) thought leaders and practitioners. This podcast was delivered to subscribers of The Design Brief, LEI's newsletter devoted to improving organizations' innovation capability. It is the second of four in a series focused on craftsmanship or pursuing perfection in products and people. Craftsmanship embodies simple elegance, precise execution, and a deep, personal connection to work that transforms both the creation and the creator.

Today, on Innovation Talks, Paul Heller and Greg Coticchia, the CEO of Sopheon, bring a wealth of experience in product management. In this episode, they delve into the challenges and opportunities faced by product managers, highlighting their crucial role in driving innovation and business success. Greg emphasizes the importance of leadership, collaboration, and strategic thinking for product managers to excel in their roles. He stresses the need for product managers to gain the trust and support of their executive team and the development and sales teams.   Greg and Paul discuss the evolving nature of the product manager role, noting how it has changed over the years. They highlight the shift from product managers being solely focused on feature prioritization to becoming business owners responsible for their products' overall health and success. They emphasize the need for product managers to go beyond just being a proxy for the customer and actively engage with customers, salespeople, marketing, and development teams to gain a holistic understanding of the market and drive product success.   The conversation also touches on the importance of executive support and understanding of product management. Greg emphasizes that executives need to recognize the value and impact of product management on the company's growth and profitability. He encourages executives to educate themselves on the role of product management and how they can support and empower product managers to make strategic decisions.   Throughout the episode, Greg and Paul stress the need for product managers to learn and develop their skills continuously. They recommend taking sales and marketing courses better to understand the customer journey and the sales process. They also highlight the importance of staying updated on digital marketing strategies and tools to market and sell products in the digital age effectively.   "If you're an executive and you don't know a lot about product management, you should. You should understand it as a profession. You should understand its role. You should understand how it helps you and your business." ~ Greg Coticchia     Greg Coticchia is the CEO of Sopheon and a seasoned expert in product management. With a wealth of experience in the industry, Greg has witnessed the transformation of product companies over the years and deeply understands the challenges faced by product managers and the evolving expectations placed upon them. Instrumental in reshaping the role of product managers, Greg lobbies for their involvement in strategic decision-making and their ability to drive business growth. He strongly advocates for product managers to develop leadership skills and build trust with key stakeholders, including developers, sales teams, and executives. Greg's insights and expertise make him a valuable resource for anyone navigating the complex world of product management.       This Week on Innovation Talks: • Product managers should not fear or avoid working with sales organizations but rather find ways to collaborate and support them. • Building relationships and trust with developers, sales teams, and executives is crucial for product managers to succeed. • Education in strategy, business leadership, and sales can enhance the skills and effectiveness of product managers. • Leadership is a key aspect of the product manager role, and they should strive to demonstrate leadership qualities in their work. • Building relationships with sales teams is important for product managers to understand customer needs and effectively sell the product. • Education in sales methodologies and digital marketing is essential for product managers to understand the customer journey and effectively support sales efforts. • Understanding the role of product management and its impact on the organization is important for executives to provide the necessary support and resources. • Product managers should not just focus on technical aspects but also understand their products' business and financial aspects.   Resources Mentioned: • Sopheon (https://www.sopheon.com/) • Agile Manifesto (https://agilemanifesto.org/) - The Agile Manifesto that changed the role of product managers. • HubSpot (https://www.hubspot.com/) • Salesforce (https://www.salesforce.com/)   This Podcast is brought to you by Sopheon Thanks for tuning into this week's episode of Innovation Talks. If you enjoyed this episode, please subscribe and leave a review wherever you get your podcasts. Apple Podcasts (https://podcasts.apple.com/us/podcast/innovation-talks/id1555857396) | TuneIn (https://tunein.com/podcasts/Technology-Podcasts/Innovation-Talks-p1412337/) | GooglePlay (https://www.google.com/podcasts?feed=aHR0cHM6Ly9pbm5vdmF0aW9udGFsa3MubGlic3luLmNvbS9yc3M%3D) | Stitcher (https://www.stitcher.com/s?fid=614195) | Spotify (https://open.spotify.com/show/1dX5b8tWI29YbgeMwZF5Uh)...

Mike Lyons: When Technical Knowledge is an Impediment to Great Product Ownership in Scrum Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Visionary Product Ownership, Leading with Passion and Purpose In this segment, Mike celebrates a Product Owner who exemplifies vision and passion, bringing humanity and customer focus into the product development process. He also shares how this approach enhances team empathy and product quality, and what lessons can other Product Owners take from this exemplary behavior. The Bad Product Owner: The Pitfalls of Technical Product Ownership In this segment, Mike discusses the challenges and pitfalls when technical expertise overshadows the true role of a Product Owner. What can go wrong when a former developer becomes a Product Owner, and how does disengagement from the role affect team dynamics? Unpack the essential qualities of vision, passion, and advocacy that every Product Owner should embody.   [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

Mike Lyons: Guiding Agile Teams to Independence, Tips For Scrum Masters Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this segment, Mike shares practical tips on measuring and fostering team independence using the five events of Scrum. Key strategies include ensuring teams have seen work before planning, encouraging team-defined goals, limiting the scrum master's role in daily scrums, optimizing sprint lengths for quicker feedback, and focusing on product showcasing and feedback during sprint reviews. Mike challenges teams to push boundaries and continuously improve. Featured Retrospective Format for the Week: Commitment-Driven Retrospectives Mike shares his favorite retrospective format—commitment-driven retrospectives. Mike emphasizes the importance of starting retrospectives with the question, "Did we make the improvement we committed to last time?" He argues that without this initial focus, the format of retrospectives becomes irrelevant and could lead to disengagement. Mike discusses creating an environment that empowers team members to bring and own their improvements, highlighting the scrum master's role in modeling effective approaches to continual enhancement.   [IMAGE HERE] Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

Mike Lyons: Agile Beyond Teams, Leading Organizational Change Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Mike discusses the broader implications of Agile beyond just team dynamics, highlighting the need for coaching and influence at the organizational level. Why does Mike believe that Agile is not just a mindset but a substantial practice that requires change in behaviors before culture can shift? Explore how understanding business language and aligning with organizational outcomes can expand and strengthen the role of Scrum Masters.   [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

Mike Lyons: Slipping Back, When Agile Teams Drift Back Toward Waterfall Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Mike shares a story from his time with a team that inadvertently started adopting waterfall practices despite beginning with Agile intentions. How did the introduction of a business analyst role lead to a disconnect between the team and their product owner, and what does this signify about the delicate balance of roles within Agile teams? Learn from Mike's retrospective insights on maintaining Agile principles and the importance of quick feedback cycles. Featured Book of the Week: The Phoenix Project by Gene Kim In this segment, Mike describes why the "The Phoenix Project," a business novel resonates so much with scrum masters and Agile practitioners. Why does Mike find himself returning to this book time and again, and how does it mirror the realities of DevOps and Agile environments? Explore how the narrative's emphasis on improving daily work over performing it can revolutionize your approach to Agile project management.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

Mike Lyons: The Humility to Listen, A Sprint Planning Turnaround Story Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. When Mike took on one of his early projects, a seemingly small requirement during sprint planning sparked an epiphany about Agile workflows. Mike's story unfolds as he learns that dictating tasks isn't always the best approach, and he realized the importance of listening and empowering those who do the work. What crucial lessons did Mike learn about intellectual humility and creating space for his team to excel? Discover how these insights transformed his approach to sprint planning and why the Toyota Production System might hold secrets to doing your best work.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Mike Lyons After reading the Agile Manifesto in 2006, Mike focused on making teams and organizations more adaptive and efficient. Despite facing failures and mistakes, these experiences provided him with valuable lessons that enhanced his ability to achieve tangible results with Agile. You can link with Mike Lyons on LinkedIn.

The Agile methodology has undoubtedly revolutionized project management, reshaping the way teams collaborate, deliver value, and embrace change.Galen Low is joined by Jim Highsmith, co-author of the Agile Manifesto, to discuss the ongoing evolution of Agile principles and their application in today's ever-changing digital landscape.

Tom Baldwin: Agile Team Champion, The Product Owner Who Gave the Stage Away Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Agile Team Champion, The PO Who Gave the Stage Away This segment spotlights an exemplary Product Owner who, through openness and experimentation, fosters a strong bond between stakeholders, developers, and the Scrum team. Tom emphasizes the importance of backlog management, team involvement in decision-making, and the PO's non-technical, yet impactful, leadership style, illustrating how an effective PO can be a linchpin for team success and stakeholder satisfaction. The Bad Product Owner: The Proxy PO As A Strategy To Overcome PO Anti-Patterns Tom shares some critical anti-patterns often seen in the role of the Product Owner, like distance, dictatorship, and the toxicity surrounding the PO role. By proposing solutions such as empowering subject matter experts and adopting the Proxy PO pattern, Tom provides a blueprint for transforming the PO role into a catalyst for effective Scrum practices, ensuring a balanced and productive team dynamic.   [IMAGE HERE] Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate.   About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

Tom Baldwin: Beyond The Process Ceremonies, The Necessary Evolution Of Scrum Master Success Over Time Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Tom talks about how we need to, over time, evolve our signs and metrics of success for Scrum Masters, from mastering ceremonies to measuring lead times and value delivery. Emphasizing the importance of team engagement with users and customers, Tom offers insights into fostering a culture of responsiveness and continuous improvement, ensuring that the team's journey towards autonomy and efficiency is both measurable and meaningful. Featured Retrospective Format for the Week: 5 Why's Tom explores the essence of effective Agile retrospectives, focusing on the 5 Why's technique to address root causes of team challenges. He advocates for personalized approaches, ensuring the right stakeholders are present, and fostering an environment where the team can own the process and outcomes. Through strategic documentation and visualization, Tom illustrates how to guide teams towards self-improvement and a focus on collaboration. [IMAGE HERE] Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

Tom Baldwin: Agile Under Pressure, Strategies for Effective Organizational Change Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Tom shares a story about leading organizational change under a tight deadline, leveraging Agile principles to dismantle complexity and align teams with corporate goals. Through collaboration with an organizational design consultant, Tom emphasizes practical steps like optimizing team structures, engaging support functions, and applying throughput accounting to facilitate a transformation focused on simplicity, efficiency, and problem-solving, inspired by insights from Taiichi Ohno on eliminating waste.   [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

Tom Baldwin: From Centralized to Collaborative, Cultivating Independent Agile Teams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. As Tom steps into a team entangled with centralized communication and decision-making issues, he shares his strategic approach to fostering team independence and effective communication, especially during a managerial hiatus. Key strategies include direct dialogue among team members, engaging leadership in problem-solving discussions, and advocating for managerial coaching, drawing upon a real-life transformation where team autonomy and progress shine despite initial resistance. Featured Book of the Week: The Scrum Field Guide by Mitch Lacey Tom sheds light on the pivotal role The Scrum Field Guide by Mitch Lacey played in his Scrum Master journey, emphasizing its approachability and practical insights into role expectations, task decomposition, and work management. With anecdotes and tips like fitting work to time and embracing various work breakdown strategies. In this episode, we also refer to the episode with Anton Skornikov on slicing User Stories. [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

Tom Baldwin: When the Stand-Up Turns Into Chaos, Conflict, Care, and Change for Agile Teams Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In a gripping episode with Tom, we talk about the chaos of a stand-up gone wrong, spotlighting how personal tensions can reflect deeper process issues. Tom recounts a fiery disagreement between developers, stemming from a pressured environment, and how it led to a transformative shift in team dynamics and location. We talk about how Scrum Masters can navigate through conflicts, focusing on psychological insights and team unity. Key takeaways include the importance of 1-on-1 chats, understanding triggers, and collective decision-making, all while referencing seminal works like Deming's 14 principles for management and Lencioni's "The Five Dysfunctions of a Team."   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

The SPaMCAST 802 features a panel discussion.  Mark Metze, Jeremy Willets, and myself. discuss “Is agile still a movement or has it reached middle age?”  We weigh the appropriateness of wailing and gnashing of teeth, hand wringing and sullen withdrawal, or pragmatism and philosophy. In the end perhaps the right answer is to buy a pair of mom or dad jeans and accept that all great movements reach middle age at some point. We look forward to your opinions and comments.   Panelists Mark Metze: With a career spanning over 30 years in the software industry, Mark has evolved from a seasoned developer, dedicating 19 years to crafting high-quality and maintainable code that directly addressed real-world challenges. Transitioning into a management role, he spent the next 9 years leading development teams, gaining a holistic perspective on the various roles crucial for successful software delivery. Embracing the philosophy of servant leadership, he transitioned once again to the role of a Scrum Master. Over the last 3.5 years, his focus has been on fostering collaboration, continuous improvement, and empowering teams to excel in their agile practices. Mark's journey from a hands-on developer to a supportive Scrum Master reflects a deep understanding of the intricacies of software development, coupled with a passion for facilitating teams to achieve their highest potential. Mark also hosts The Agile Within podcast with new episodes debuting each week. It's mission is "Providing agile insights into human values and behaviors through genuine connections". You can listen on your favorite podcast platform or on the web: Jeremy Willets is a coach, speaker, and author who has spent the last decade working with people and teams to achieve greatness in the workplace. He started out as a technical writer on a Scrum team and quickly fell in love with Scrum and the Agile Manifesto values and principles. Since then, he's served thriving organizations as a Scrum Master, Agile Coach, Senior Agile Coach, Release Train Engineer, people manager, and mentor.   Jeremy has spoken at conferences throughout the midwestern United States. He's an avid Substack blogger and music maker. He holds a SAFe® Practice Consultant (SPC) certification. Jeremy can be found at    Learn To Tame Your Work Intake Beast! Jeremy Willets and I have opened a new workshop cohort to help you learn to tame the work intake beast!  The workshop will run from 31 May to 28 June in five manageable 90-minute chunks. For more details hop over to our Maven site  for more information, sign up, or join the mailing list!   Re-read Saturday News Chapter 3, Deep Work is Meaningful completes Part 1 of by Cal Newport. If you are reading this chapter for the first time, my interpretation of the author's intent is not to prove that deep work is meaningful but rather to argue that it is more meaningful than shallow work. On deeper reflection, there are even more cautionary notes for the always “in contact” amongst us. Read the chapter, this week's re-read post, and contemplate!                                                                                                       Remember to buy a copy of and read along. Week 1:  -   Week 2: -   Week 3: -   Week 4: -     Next SPaMCAST  In SPaMCAST 803 we will contemplate the product roles impact on work intake. These roles appear straightforward and at the same time offer many layers and nuances. Regardless of the approach or structure someone is using, making work intake decisions might enhance or trash product decisions. Someone is making those decisions, you need to understand the impact. We will also have a visit from Susan Parente who brings her Not a Scrumdamentalist column to the podcast.   

Leadership Is the Big Gaping Hole In the Agile Manifesto From time to time, people will declare Agile dead. On December 1st, Cliff Berg declared Agile dead in a viral post on LinkedIn. Personally, I think declaring a tool like Agile dead because it doesn't work is like declaring a pencil dead because it doesn't turn us all into Michelangelos. A tool enhances human capabilities. A tool is only as powerful as the people using it. But declaring things dead can be a good way to see what is wrong with it, maybe redesign it. In his post, Cliff stated that “Agile is dead … but companies still need agility.” Agile is dead, long live agility. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

What Are Words For? NOTHING is more annoying than when people take words and twist them out of context and or take sound bites of entire documents to force others to believe their point of view. While there is a time and a place to be selective of our word choices, dissecting the Agile Manifesto is NOT one of them. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Join Brian and David Bland as they journey into the novel idea of testing assumptions before development to avoid costly mistakes and ensure the right things are being built in the latest episode of the Agile Mentors Podcast—a must-listen for any product owner wanting to determine if their team is working on the right thing. Overview In this episode of the Agile Mentors Podcast, Brian talks all things testing with David Bland, the founder of Precoil and co-author of the book Testing Business Ideas: A Field Guide for Rapid Experimentation. Learn the importance of testing assumptions and experimentation in product development as David shares his journey from working in startups to coaching and consulting and how he realized the need to bring Agile principles into the discovery phase of product development. You can listen in as they explore the concept of testing business ideas and the three-step process of extracting assumptions, prioritizing them, and running experiments. Listen Now to Discover: [01:01] - Brian introduces David Bland, founder of Precoil and co-author of Testing Business Ideas: A Field Guide for Rapid Experimentation. [02:10] - David dives into weaving testing assumptions and experimentation into managing the product backlog for product owners. [02:51] - David discusses how you can determine if you're working on the right things and prevent iteratively delivering something that nobody cares about by applying the Agile principles further upstream. [04:20] - Brain adds insight with the notion of being selective as the product owner, referencing the work of Henrik Kniberg. [05:18] - David breaks down the themes he developed from design thinking and how they apply beautifully to the product backlog: desirable, viable, & feasible [06:50] - Brian asks the question burning through many of our minds, “How do you apply it to testing your ideas?” [07:15] - David lays out the three-step process he uses and applies to testing business, product, and service ideas. [08:32] - David discusses the difference between requirements and assumptions. [10:33] - David provides a practical example of adding wishlist functionality to a website and what testing this idea would look like under his testing framework. [14:47] - Today's episode of the Agile Mentors Podcast is brought to you by Mountain Goat Software's Private Training for Agile transformations. Get your team on the same page through customized training and coaching programs to level-set your team. For more information, visit the Mountain Goat Software’s Private Training page. [16:07] - Brian poses the concept of asking, “How does an idea move the needle” before the idea is developed? [18:14] - David shares his thoughts on running customer-facing acceptance criteria and the product death cycle, a term David coined. [21:06] - David provides an example of a client who puts a positive spin on killing projects that prove not to be viable via testing. [22:33] - Brian asks if there are testing methods that can be applied after a product launch as a lagging indicator of the launch. [24:57] - Brian clarifies the value of testing before making a bet on a new product, even as an entrepreneur working alone, through the example of knowing how a bet will play out in a Las Vegas casino. [25:38] - David lays out the common objections he sees from companies and how you could address them. [27:13] - David lays out one of his favorite techniques for testing, concierge, which he lays out in detail in his book. [30:41] - Brian draws the conversation back to the Agile Manifesto. [31:49] - Brian shares a big thank you to David for joining him on the show. [33:30] - We invite you to subscribe to the Agile Mentors Podcast on Apple Podcasts. Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: David Bland Precoil Testing Business Ideas: A Field Guide for Rapid Experimentation by David Bland & Alexander Osterwalder #25 Scaling with Henrik Kniberg Agile Manifesto Subscribe to the Agile Mentors Podcast on Apple Podcasts Mountain Goat Software’s Private Training Mountain Goat Software Certified Scrum and Agile Training Schedule Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is 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. David J Bland helps companies such as GE, Toyota, Adobe, HP, and Behr find product market fit using lean startup, design thinking, and business model innovation through his company, Precoil. He is the lead author of Testing Business Ideas with Alexander Osterwalder.

Original signer of the Agile Manifesto, author of the Extreme Programming book series, rediscoverer of Test-Driven Development, and inspiring Keynote Speaker. I read his TDD book 20 years ago.   Topics of Discussion: [4:06] What led Kent into extreme programming, and realizing that technical mastery alone is not enough for project success. [6:24] The significance of extreme programming. [9:15] The Agile Manifesto. [10:46] The importance of taking responsibility seriously. [14:06] What was the inspiration behind Tidy First? [16:27] Why software design is an important skill. [17:31] The human aspect dominates in design. [19:40] You can make large changes in small safe steps. [23:09] Normalizing symmetry. [30:17] Preserving flexibility in design through empirical and reversible changes rather than rather than speculative or reactive design. [31:51] Kent's experimentation with the GPT phase of AI on publications. [32:11] Rent-A-Kent to get better answers around software development. [37:19] Advice for young programmers.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! Rent-A-Kent Tidy First? by Kent Beck Test Driven Development, by Kent Beck Extreme Programming Explained, by Kent Beck with Cynthia Andres Implementation Patterns, by Kent Beck   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

BONUS: Helping the PO Measure Value, Unwrapping Metrics Mastery with Vasco Duarte Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Merry Christmas, dear listeners! We hope your festive season is filled with joy and warmth. Today marks another special BONUS episode in our Christmas week lineup, and we're diving into the crucial topic of helping Product Owners measure value. If you missed our previous episode on defining business value, be sure to check it out as today's content builds upon those insights. This episode, like all others this week, is a companion to the Coach Your Product Owner e-course, accessible at bit.ly/coachyourpo. Why We Need To Help Product Owners Measure Value Ever envisioned driving a familiar road blindfolded? Many teams find themselves in a similar predicament, knowing their backlog and delivery process well but lacking clarity on their goal. A backlog of items, as emphasized yesterday, is not a goal. Defining Value is Not Enough; We Must Measure It While some teams may define goals, many stumble when it comes to measuring them early and consistently. Aligning with the Agile Manifesto, this episode emphasizes why continuous delivery of valuable software needs to be complemented with the same continuous measurement of value! Leading and Lagging Indicators and Why That's Important In this episode, we discuss the distinction between leading and lagging indicators. Leading indicators provide insights into future events, while lagging indicators validate that the product is delivering value. Explore the significance of both in making informed decisions. The Difference Between Strategic Metrics and Day-to-Day Metrics (The Metrics Tree Technique) Building on yesterday's discussion about understanding the company's strategy, we explore the transition from strategic metrics (lagging indicators like revenue) to day-to-day metrics. This transition is essential for ensuring daily value delivery and supporting short-term, customer-focused experiments. In this segment, we discuss the Metrics Tree technique which Vasco learned from Chris Matts. Product Dashboards for the PO and the Team Product Dashboards emerge as a crucial tool to keep teams focused on the right metrics throughout the development process. These dashboards visualize product goals, the target customer, current and future sprint goals, and key metrics. They serve as a cornerstone for team accountability, fostering self-management and autonomy. In this episode, we discuss a Product Dashboard similar to the one illustrated below:  How To Measure Value: A Summary In today's episode, we covered the following steps to help the PO measure value: Define value (discussed in the previous episode). Define appropriate metrics for the defined value. Consider both leading and lagging indicators. Ensure a balance of strategic and day-to-day metrics for decision-making. Build a product dashboard with the PO and the team to enhance self-accountability and self-management. Explore these concepts further in the Coach Your PO e-course: Module 3 (Version 1.0): Setting up ACTIONABLE metrics, distinguishing between ACTIONABLE and Vanity Metrics. Module 2.0: Scaling up the Product Owner role for multiple teams and products, featuring insights into Product Dashboards and Vision. Module 09: Techniques for quick feedback and leveraging process metrics critical for the discussed product dashboard. For more details on the Coach Your PO e-course, visit bit.ly/coachyourpo. If personalized coaching suits your needs, reach out to us at coaching@oikosofy.com. Keep learning, keep helping your team, and we'll catch you in the next episode! About Vasco Duarte Vasco is a leading voice in the agile community, known for his contributions to the development of agile methodologies and practices. He is the co-founder of Agile Finland and the host of Scrum Master Toolbox Podcast, the most popular Agile podcast in the world, which has more than 10 000 000 unique downloads. He is also the author of “NoEstimates: A novel look at how Agile can transform software development, making it both more sustainable, as well as incredibly profitable.” Vasco is a keynote speaker at many conferences and events, sharing his knowledge and experience with the agile community. With his passion and expertise in agile, Vasco has made a significant impact on the way software development is done today, helping organizations to become more efficient, flexible, and responsive to changing requirements.lYou You can link with Vasco Duarte on LinkedIn and connect with Vasco Duarte on Twitter.

Ned Bellavance worked in the world of tech for more than a decade before joining the family profession as an educator. He joins Corey on Screaming in the Cloud to discuss his shift from engineer to educator and content creator, the intricacies of Terraform, and how changes in licensing affect the ecosystem.About NedNed is an IT professional with more than 20 years of experience in the field. He has been a helpdesk operator, systems administrator, cloud architect, and product manager. In 2019, Ned founded Ned in the Cloud LLC to work as an independent educator, creator, and consultant. In this new role, he develops courses for Pluralsight, runs multiple podcasts, writes books, and creates original content for technology vendors.Ned is a Microsoft MVP since 2017 and a HashiCorp Ambassador since 2020.Ned has three guiding principles: embrace discomfort, fail often, and be kind.Links Referenced: Ned in the Cloud: https://nedinthecloud.com/ LinkedIn: https://www.linkedin.com/in/ned-bellavance/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is Ned Bellavance, who's the founder and curious human over at Ned in the Cloud. Ned, thank you for joining me.Ned: Yeah, it's a pleasure to be here, Corey.Corey: So, what is Ned in the Cloud? There are a bunch of easy answers that I feel don't give the complete story like, “Oh, it's a YouTube channel,” or, “Oh no, it's the name that you wound up using because of, I don't know, easier to spell the URL or something.” Where do you start? Where do you stop? What are you exactly?Ned: What am I? Wow, I didn't know we were going to get this deep into philosophical territory this early. I mean, you got to ease me in with something. But so, Ned in the Cloud is the name of my blog from back in the days when we all started up a blog and hosted on WordPress and had fun. And then I was also at the same time working for a value-added reseller as a consultant, so a lot of what went on my blog was stuff that happened to me in the world of consulting.And you're always dealing with different levels of brokenness when you go to clients, so you see some interesting things, and I blogged about them. At a certain point, I decided I want to go out and do my own thing, mostly focused on training and education and content creation and I was looking for a company name. And I went through—I had a list of about 40 different names. And I showed them to my wife, and she's like, “Why don't you go Ned in the Cloud? Why are you making this more complicated than it needs to be?”And I said, “Well, I'm an engineer. That is my job, by definition, but you're probably right. I should just go with Ned in the Cloud.” So, Ned in the Cloud now is a company, just me, focused on creating educational content for technical learners on a variety of different platforms. And if I'm delivering educational content, I am a happy human, and if I'm not doing that, I'm probably out running somewhere.Corey: I like that, and I'd like to focus on education first. There are a number of reasons that people will go in that particular direction, but what was it for you?Ned: I think it's kind of in the heritage of my family. It's in my blood to a certain degree because my dad is a teacher, my mom is a teacher-turned-librarian, my sister is a teacher, my wife is a teacher, her mother is a teacher. So, there was definitely something in the air, and I think at a certain point, I was the black sheep in the sense that I was the engineer. Look, this guy over here. And then I ended up deciding that I really liked training people and learning and teaching, and became a teacher of sorts, and then they all went, “Welcome to the fold.”Corey: It's fun when you get to talk to people about the things that they're learning because when someone's learning something I find that it's the time when their mind is the most open. I don't think that that's something that you don't get to see nearly as much once someone already, quote-unquote, “Knows a thing,” because once that happens, why would you go back and learn something new? I have always learned the most—even about things that I've built myself—by putting it in the hands of users and seeing how they honestly sometimes hold it wrong and make mistakes that don't make sense to me, but absolutely make sense to them. Learning something—or rather, teaching something—versus building that thing is very much an orthogonal skill set, and I don't think that there's enough respect given to that understanding.Ned: It's an interesting sphere of people who can both build the thing and then teach somebody else to build the thing because you're right, it's very different skill sets. Being able to teach means that you have to empathize with the human being that you're teaching and understand that their perspective is not yours necessarily. And one of the skills that you build up as an instructor is realizing when you're making a whole bunch of assumptions because you know something really well, and that the person that you're teaching is not going to have that context, they're not going to have all those assumptions baked in, so you have to actually explain that stuff out. Some of my instruction has been purely online video courses through, like, Pluralsight; less of a feedback loop there. I have to publish the entire course, and then I started getting feedback, so I really enjoy doing live trainings as well because then I get the questions right away.And I always insist, like, if I'm delivering a lecture, and you have a question, please don't wait for the end. Please interrupt me immediately because you're going to forget what that question is, you're going to lose your train of thought, and then you're not going to ask it. And the whole class benefits when someone asks a question, and I benefit too. I learn how to explain that concept better. So, I really enjoy the live setting, but making the video courses is kind of nice, too.Corey: I learned to speak publicly and give conference talks as a traveling contract trainer for Puppet years ago, and that was an eye-opening experience, just because you don't really understand something until you're teaching other people how it works. It's how I learned Git. I gave a conference talk that explained Git to people, and that was called a forcing function because I had four months to go to learn this thing I did not fully understand and welp, they're not going to move the conference for me, so I guess I'd better hustle. I wouldn't necessarily recommend that approach. These days, it seems like you have a, let's say, disproportionate level of focus on the area of Infrastructure as Code, specifically you seem to be aiming at Terraform. Is that an accurate way of describing it?Ned: That is a very accurate way of describing it. I discovered Terraform while I was doing my consulting back in 2016 era, so this was pretty early on in the product's lifecycle. But I had been using CloudFormation, and at that time, CloudFormation only supported JSON, which meant it was extra punishing. And being able to describe something more succinctly and also have access to all these functions and loops and variables, I was like, “This is amazing. Where were you a year ago?” And so, I really just jumped in with both feet into Terraform.And at a certain point, I was at a conference, and I went past the Pluralsight booth, and they mentioned that they were looking for instructors. And I thought to myself, well, I like talking about things, and I'm pretty excited about this Terraform thing. Why don't I see if they're looking for someone to do a Terraform course? And so, I went through their audition process and sure enough, that is exactly what they were looking for. They had no getting started course for Terraform at the time. I published the course in 2017, and it has been in the top 50 courses ever since on Pluralsight. So, that told me that there's definitely an appetite and maybe this is an area I should focus on a little bit more.Corey: It's a difficult area to learn. About two months ago, I started using Terraform for the first time in anger in ages. I mean, I first discovered it when I was on my way back from one of those Puppet trainings, and the person next to me was really excited about this thing that we're about to launch. Turns out that was Mitchell Hashimoto and Armon was sitting next to him on the other side. Why he had a middle seat, I'll never know.But it was a really fun conversation, just talking about how he saw the world and what he was planning on doing. And a lot of that vision was realized. What I figured out a couple months ago is both that first, I'm sort of sad that Terraform is as bad as it is, but it's the best option we've got because everything else is so much worse. It is omnipresent, though. Effectively, every client I've ever dealt with on AWS billing who has a substantial estate is managing it via Terraform.It is the lingua franca of cloud across the board. I just wish it didn't require as much care and feeding, especially for the getting-started-with-a-boilerplate type of scenario. So, much of what you type feels like it's useless stuff that should be implicit. I understand why it's not, but it feels that way. It's hard to learn.Ned: It certainly can be. And you're right, there's a certain amount of boilerplate and [sigh] code that you have to write that seems pointless. Like, do I have to actually spell this all out? And sometimes the answer is yes, and sometimes the answer is you should use a module for that. Why are you writing this entire VPC configuration out yourself? And that's the sort of thing that you learn over time is that there are shortcuts, there are ways to make the code simpler and require less care and feeding.But I think ultimately, your infrastructure, just like your software, evolves, changes has new requirements, and you need to manage it in the same way that you want to manage your software. And I wouldn't tell a software developer, “Oh, you know, you could just write it once and never go back to it. I'm sure it's fine.” And by the same token, I wouldn't tell an infrastructure developer the same thing. Now, of course, people do that and never go back and touch it, and then somebody else inherits that infrastructure and goes, “Oh, God. Where's the state data?” And no one knows, and then you're starting from scratch. But hopefully, if you have someone who's doing it responsibly, they'll be setting up Terraform in such a way that it is maintainable by somebody else.Corey: I'd sure like to hope so. I have encountered so many horrible examples of code and wondering what malicious person wrote this. And of course, it was me, 6 or 12 months ago.Ned: Always [laugh].Corey: I get to play architect around a lot of these things. In fact, that's one of the problems that I've had historically with an awful lot of different things that I've basically built, called it feature complete, let it sit for a while using the CDK or whatnot, and then oh, I want to make a small change to it. Well, first, I got to spend half a day during the entire line dependency updates and seeing what's broken and how all of that works. It feels like for better or worse, Terraform is a lot more stable than that, as in, old versions of Terraform code from blog posts from 2016 will still effectively work. Is that accurate? I haven't done enough exploring in that direction to be certain.Ned: The good thing about Terraform is you can pin the version of various things that you're using. So, if you're using a particular version of the AWS provider, you can pin it to that specific version, and it won't automatically upgrade you to the latest and greatest. If you didn't do that, then you'll get bit by the update bug, which certainly happens to some folks when they changed the provider from version 3 to version 4 and completely changed how the S3 bucket object was created. A lot of people's scripts broke that day, so I think that was the time for everyone to learn what the version argument is and how it works. But yeah, as long as you follow that general convention of pinning versions of your modules and of your resource provider, you should be in a pretty stable place when you want to update it.Corey: Well, here's the $64,000 question for you, then. Does Dependabot on your GitHub repo begin screaming at you as soon as you've done that because in one of its dependencies in some particular weird edge cases when they're dealing with unsanitized, internet-based input could wind up taking up too many system resources, for example? Which is, I guess, in an ideal world, it wouldn't be an issue, but in practice, my infrastructure team is probably not trying to attack the company from the inside. They have better paths to get there, to be very blunt.Ned: [laugh].Corey: Turns out giving someone access to a thing just directly is way easier than making them find it. But that's been one of the frustrating parts where, especially when it encounters things like, I don't know, corporate security policies of, “Oh, you must clear all of these warnings,” which well-intentioned, poorly executed seems to be the takeaway there.Ned: Yeah, I've certainly seen some implementations of tools that do static scanning of Terraform code and will come up with vulnerabilities or violations of best practice, then you have to put exceptions in there. And sometimes it'll be something like, “You shouldn't have your S3 bucket public,” which in most cases, you shouldn't, but then there's the one team that's actually publishing a front-facing static website in the S3 bucket, and then they have to get, you know, special permission from on high to ignore that warning. So, a lot of those best practices that are in the scanning tools are there for very good reasons and when you onboard them, you should be ready to see a sea of red in your scan the first time and then look through that and kind of pick through what's actually real, and we should improve in our code, and what's something that we can safely ignore because we are intentionally doing it that way.Corey: I feel like there's an awful lot of… how to put this politely… implicit dependencies that are built into things. I'll wind up figuring out how to do something by implementing it and that means I will stitch together an awful lot of blog posts, things I found on Stack Overflow, et cetera, just like a senior engineer and also Chat-Gippity will go ahead and do those things. And then the reason—like, someone asks me four years later, “Why is that thing there?” And… “Well, I don't know, but if I remove it, it might stop working, so…” there was almost a cargo-culting style of, well, it's always been there. So, is that necessary? Is it not?I'm ashamed by how often I learned something very fundamental in a system that I've been using for 20 years—namely, the command line—just by reading the man page for a command that I already, quote-unquote, “Already know how to use perfectly well.” Yeah, there's a lot of hidden gems buried in those things.Ned: Oh, my goodness, I learned something about the Terraform CLI last week that I wish I'd known two years ago. And it's been there for a long time. It's like, when you want to validate your code with the terraform validate, you can initialize without initializing the back-end, and for those who are steeped in Terraform, that means something and for everybody else, I'm sorry [laugh]. But I discovered that was an option, and I was like, “Ahhh, this is amazing.” But to get back to the sort of dependency problems and understanding your infrastructure better—because I think that's ultimately what's happening when you have to describe something using Infrastructure as Code—is you discover how the infrastructure actually works versus how you thought it worked.If you look at how—and I'm going to go into Azure-land here, so try to follow along with me—if you go into Azure-land and you look at how they construct a load balancer, the load balancer is not a single resource. It's about eight different resources that are all tied together. And AWS has something similar with how you have target groups, and you have the load balancer component and the listener and the health check and all that. Azure has the same thing. There's no actual load balancer object, per se.There's a bunch of different components that get slammed together to form that load balancer. When you look in the portal, you don't see any of that. You just see a load balancer, and you might think this is a very simple resource to configure. When it actually comes time to break it out into code, you realize, oh, this is eight different components, each of which has its own options and arguments that I need to understand. So, one of the great things that I have seen a lot of tooling up here around is doing the import of existing infrastructure into Terraform by pointing the tool at a collection of resources—whatever they are—and saying, “Go create the Terraform code that matches that thing.” And it's not going to be the most elegant code out there, but it will give you a baseline for what all the settings actually are, and other resource types are, and then you can tweak it as needed to add in input variables or remove some arguments that you're not using.Corey: Yeah, I remember when they first announced the importing of existing state. It's wow, there's an awful lot of stuff that it can be aware of that I will absolutely need to control unless I want it to start blowing stuff away every time I run the—[unintelligible 00:15:51] supposedly [unintelligible 00:15:52] thing against it. And that wasn't a lot of fun. But yeah, this is the common experience of it. I only recently was reminded of the fact that I once knew, and I'd forgotten that a public versus private subnet in AWS is a human-based abstraction, not something that is implicit to the API or the way they envision subnets existing. Kind of nice, but also weird when you have to unlearn things that you've thought you'd learned.Ned: That's a really interesting example of we think of them as very different things, and when we draw nice architecture diagrams there—these are the private subnets and these are the public ones. And when you actually go to create one using Terraform—or really another tool—there's no box that says ‘private' or ‘make this public.' It's just what does your route table look like? Are you sending that traffic out the internet gateway or are you sending it to some sort of NAT device? And how does traffic come back into that subnet? That's it. That's what makes it private versus public versus a database subnet versus any other subnet type you want to logically assign within AWS.Corey: Yeah. It's kind of fun when that stuff hits.Ned: [laugh].Corey: I am curious, as you look across the ecosystem, do you still see that learning Terraform is a primary pain point for, I guess, the modern era of cloud engineer, or has that sunk below the surface level of awareness in some ways?Ned: I think it's taken as a given to a certain degree that if you're a cloud engineer or an aspiring cloud engineer today, one of the things you're going to learn is Infrastructure as Code, and that Infrastructure as Code is probably going to be Terraform. You can still learn—there's a bunch of other tools out there; I'm not going to pretend like Terraform is the end-all be-all, right? We've got—if you want to use a general purpose programming language, you have something like Pulumi out there that will allow you to do that. If you want to use one of the cloud-native tools, you've got something like CloudFormation or Azure has Bicep. Please don't use ARM templates because they hurt. They're still JSON only, so at least CloudFormation added YAML support in there. And while I don't really like YAML, at least it's not 10,000 lines of code to spin up, like, two domain controllers in a subnet.Corey: I personally wind up resolving the dichotomy between oh, should we go with JSON or should we go with YAML by picking the third option everyone hates more. That's why I'm a staunch advocate for XML.Ned: [laugh]. I was going to say XML. Yeah oh, as someone who dealt with SOAP stuff for a while, yeah, XML was particularly painful, so I'm not sad that went away. JSON for me, I work with it better, but YAML is more readable. So, it's like it's, pick your poison on that. But yeah, there's a ton of infrastructure tools out there.They all have basically the same concepts behind them, the same core concepts because they're all deploying the same thing at the end of the day and there's only so many ways you can express that concept. So, once you learn one—say you learned CloudFormation first—then Terraform is not as big of a leap. You're still declaring stuff within a file and then having it go and make those things exist. It's just nuances between the implementation of Terraform versus CloudFormation versus Bicep.Corey: I wish that there were more straightforward abstractions, but I think that as soon as you get those, that inherently limits what you're able to do, so I don't know how you square that circle.Ned: That's been a real difficult thing is, people want some sort of universal cloud or infrastructure language and abstraction. I just want a virtual machine. I don't care what kind of platform I'm on. Just give me a VM. But then you end up very much caring [laugh] what kind of VM, what operating system, what the underlying hardware is when you get to a certain level.So, there are some workloads where you're like, I just needed to run somewhere in a container and I really don't care about any of the underlying stuff. And that's great. That's what Platform as a Service is for. If that's your end goal, go use that. But if you're actually standing up infrastructure for any sort of enterprise company, then you need an abstraction that gives you access to all the underlying bits when you want them.So, if I want to specify different placement groups about my VM, I need access to that setting to create a placement group. And if I have this high-level of abstraction of a virtual machine, it doesn't know what a placement group is, and now I'm stuck at that level of abstraction instead of getting down to the guts, or I'm going into the portal or the CLI and modifying it outside of the tool that I'm supposed to be using.Corey: I want to change gears slightly here. One thing that has really been roiling some very particular people with very specific perspectives has been the BSL license change that Terraform has wound up rolling out. So far, the people that I've heard who have the strongest opinions on it tend to fall into one of three categories: either they work at HashiCorp—fair enough, they work at one of HashiCorp's direct competitors—which yeah, okay, sure, or they tend to be—how to put this delicately—open-source evangelists, of which I freely admit I used to be one and then had other challenges I needed to chase down in other ways. So, I'm curious as to where you, who are not really on the vendor side of this at all, how do you see it shaking out?Ned: Well, I mean, just for some context, essentially what HashiCorp decided to do was to change the licensing from Mozilla Public licensing to BSL for, I think eight of their products and Terraform was amongst those. And really, this sort of tells you where people are. The only one that anybody really made any noise about was Terraform. There's plenty of people that use Vault, but I didn't see a big brouhaha over the fact that Vault changed its licensing. It's really just about Terraform. Which tells you how important it is to the ecosystem.And if I look at the folks that are making the most noise about it, it's like you said, they basically fall into one of two camps: it's the open-source code purists who believe everything should be licensed in completely open-source ways, or at least if you start out with an open-source license, you can't convert to something else later. And then there is a smaller subset of folks who work for HashiCorp competitors, and they really don't like the idea of having to pay HashiCorp a regular fee for what used to be ostensibly free to them to use. And so, what they ended up doing was creating a fork of Terraform, just before the licensing change happened and that fork of Terraform was originally called OpenTF, and they had an OpenTF manifesto. And I don't know about you, when I see the word ‘manifesto,' I back away slowly and try not to make any sudden moves.Corey: You really get the sense there's going to be a body count tied to this. And people are like, “What about the Agile Manifesto?” “Yeah, what about it?”Ned: [laugh]. Yeah, I'm just—when I see ‘manifesto,' I get a little bit nervous because either someone is so incredibly passionate about something that they've kind of gone off the deep end a little bit, or they're being somewhat duplicitous, and they have ulterior motives, let's say. Now, I'm not trying to cast aspersions on anybody. I can't read anybody's mind and tell you exactly what their intention was behind it. I just know that the manifesto reads a little bit like an open-source purist and a little bit like someone having a temper tantrum, and vacillating between the two.But cooler heads prevailed a little bit, and now they have changed the name to OpenTofu, and it has been accepted by the Linux Foundation as a project. So, it's now a member of the Linux Foundation, with all the gravitas that that comes with. And some people at HashiCorp aren't necessarily happy about the Linux Foundation choosing to pull that in.Corey: Yeah, I saw a whole screed, effectively, that their CEO wound up brain-dumping on that frankly, from a messaging perspective, he would have been better served as not to say anything at all, to be very honest with you.Ned: Yeah, that was a bit of a yikes moment for me.Corey: It's very rare that you will listen yourself into trouble as opposed to opening your mouth and getting yourself into trouble.Ned: Exactly.Corey: You wouldn't think I would be one of those—of all people who would have made that observation, you wouldn't think I would be on that list, yet here I am.Ned: Yeah. And I don't think either side is entirely blameless. I understand the motivations behind HashiCorp wanting to make the change. I mean, they're a publicly traded company now and ostensibly that means that they should be making some amount of money for their investors, so they do have to bear that in mind. I don't necessarily think that changing the licensing of Terraform is the way to make that money.I think in the long-term, it's not going—it may not hurt them a lot, but I don't think it's going to help them out a lot, and it's tainted the goodwill of the community to a certain degree. On the other hand, I don't entirely trust what the other businesses are saying as well in their stead. So, there's nobody in this that comes out a hundred percent clean [laugh] on the whole process.Corey: Yeah, I feel like, to be direct, the direct competitors to HashiCorp along its various axes are not the best actors necessarily to complain about what is their largest competitor no longer giving them access to continue to compete against them with their own product. I understand the nuances there, but it also doesn't feel like they are the best ambassadors for that. I also definitely understand where HashiCorp is coming from where, why are we investing all this time, energy, and effort for people to basically take revenue away from us? But there's also the bigger problem, which is, by and large, compared to how many sites are running Terraform and the revenues that HashiCorp puts up for it, they're clearly failing to capture the value they have delivered in a massive way. But counterpoint, if they hadn't been open-source for their life until this point, would they have ever captured that market share? Probably not.Ned: Yeah, I think ultimately, the biggest competitor to their paid offering of Terraform is their free version of Terraform. It literally has enough bells and whistles already included and plenty of options for automating those things and solving the problems that their enterprise product solves that their biggest problem is not other competitors in the Terraform landscape; it's the, “Well, we already have something, and it's good enough.” And I'm not sure how you sell to that person, that's why I'm not in marketing, but I think that is their biggest competitor is the people who already have a solution and are like, “Why do I need to pay for your thing when my thing works well enough?”Corey: That's part of the strange thing that I'm seeing as I look across this entire landscape is it feels like this is not something that is directly going to impact almost anyone out there who's just using this stuff, either the open-source version as a paying customer of any of these things, but it is going to kick up a bunch of dust. And speaking of poor messaging, HashiCorp is not really killing it this quarter, where the initial announcement led to so many questions that were unclear, such as—like, they fixed this later in the frequently asked questions list, but okay, “I'm using Terraform right now and that's fine. I'm building something else completely different. Am I going to lose my access to Terraform if you decide to launch a feature that does what my company does?” And after a couple of days, they put up an indemnity against that. Okay, fine.Like, when Mongo did this, there was a similar type of dynamic that was emerging, but a lot fewer people are writing their own database engine to then sell onward to customers that are provisioning infrastructure on behalf of their customers. And where the boundaries lay for who was considered a direct Terraform competitor was unclear. I'm still not convinced that it is clear enough to bet the business on for a lot of these folks. It comes down to say what you mean, not—instead of hedging, you're not helping your cause any.Ned: Yeah, I think out of the different products that they have, some are very clear-cut. Like, Vault is a server that runs as a service, and so that's very clear what that product is and where the lines of delineation are around Vault. If I go stand up a bunch of Vault servers and offer them as a service, then that is clearly a competitor. But if I have an automation pipeline service and people can technically automate Terraform deployments with my service, even if that's not the core thing that I'm looking to do, am I now a competitor? Like, it's such a fuzzy line because Terraform isn't an application, it's not a server that runs somewhere, it's a CLI tool and a programming language. So yeah, those lines are very, very fuzzy. And I… like I said, it would be better if they say what they meant, as opposed to sort of the mealy-mouthed language that they ended up using and the need to publish multiple revisions of that FAQ to clarify their position on very specific niche use cases.Corey: Yeah, I'm not trying to be difficult or insulting or anything like that. These are hard problems that everyone involved is wrestling with. It just felt a little off, and I think the messaging did them no favors when that wound up hitting. And now, everyone is sort of trying to read the tea leaves and figure out what does this mean because in isolation, it doesn't mean anything. It is a forward-looking thing.Whatever it is you're doing today, no changes are needed for you, until the next version comes out, in which case, okay, now do we incorporate the new thing or don't we? Today, to my understanding, whether I'm running Terraform or OpenTofu entirely comes down to which binary am I invoking to do the apply? There is no difference of which I am aware. That will, of course, change, but today, I don't have to think about that.Ned: Right. OpenTofu is a literal fork of Terraform, and they haven't really added much in the way of features, so it should be completely compatible with Terraform. The two will diverge in the future as feature as new features get added to each one. But yeah, for folks who are using it today, they might just decide to stay on the version pre-fork and stay on that for years. I think HashiCorp has pledged 18 months of support for any minor version of Terraform, so you've got at least a year-and-a-half to decide. And we were kind of talking before the recording, 99% of people using Terraform do not care about this. It does not impact their daily workflow.Corey: No. I don't see customers caring at all. And also, “Oh, we're only going to use the pre-fork version of Terraform,” they're like, “Thanks for the air cover because we haven't updated any of that stuff in five years, so tha”—Ned: [laugh].Corey: “Oh yeah, we're doing it out of license concern. That's it. That's the reason we haven't done anything recent with it.” Because once it's working, changes are scary.Ned: Yeah.Corey: Terraform is one of those scary things, right next to databases, that if I make a change that I don't fully understand—and no one understands everything, as we've covered—then this could really ruin my week. So, I'm going to be very cautious around that.Ned: Yeah, if metrics are to be believed across the automation platforms, once an infrastructure rollout happens with a particular version of Terraform, that version does not get updated. For years. So, I have it on good authority that there's still Terraform version 0.10 and 0.11 running on these automation platforms for really old builds where people are too scared to upgrade to, like, post 0.12 where everything changed in the language.I believe that. People don't want to change it, especially if it's working. And so, for most people, this licensing chain doesn't matter. And all the constant back and forth and bickering just makes people feel a little nervous, and it might end up pushing people away from Terraform as a platform entirely, as opposed to picking a side.Corey: Yeah, and I think that that is probably the fair way to view it at this point where right now—please, friends at HashiCorp and HashiCorp competitors don't yell at me for this—it's basically a nerd slap-fight at the moment.Ned: [laugh].Corey: And of one of the big reasons that I also stay out of these debates almost entirely is that I married a corporate attorney who used to be a litigator and I get frustrated whenever it comes down to license arguments because you see suddenly a bunch of engineers who get to cosplay as lawyers, and reading the comments is infuriating once you realize how a little bit of this stuff works, which I've had 15 years of osmotic learning on this stuff. Whenever I want to upset my wife, I just read some of these comments aloud and then our dinner conversation becomes screaming. It's wonderful.Ned: Bad legal takes? Yeah, before—Corey: Exactly.Ned: Before my father became a social studies teacher, he was a lawyer for 20 years, and so I got to absorb some of the thought process of the lawyer. And yeah, I read some of these takes, and I'm like, “That doesn't sound right. I don't think that would hold up in any court of law.” Though a lot of the open-source licensing I don't think has been tested in any sort of court of law. It's just kind of like, “Well, we hope this stands up,” but nobody really has the money to check.Corey: Yeah. This is the problem with these open-source licenses as well. Very few have never been tested in any meaningful way because I don't know about you, but I don't have a few million dollars in legal fees lying around to prove the point.Ned: Yeah.Corey: So, it's one of those we think this is sustainable, and Lord knows the number of companies that have taken reliances on these licenses, they're probably right. I'm certainly not going to disprove the fact—please don't sue me—but yeah, this is one of those things that we're sort of assuming is the case, even if it's potentially not. I really want to thank you for taking the time to discuss how it is you view these things and talk about what it is you're up to. If people want to learn more, where's the best place for them to find you?Ned: Honestly, just go to my website. It's nedinthecloud.com. And you can also find me on LinkedIn. I don't really go for Twitter anymore.Corey: I envy you. I wish I could wean myself off of it. But we will, of course, include a link to that in the show notes. Thank you so much for being so generous with your time. It's appreciated.Ned: It's been a pleasure. Thanks, Corey.Corey: Net Bellavance, founder and curious human at Ned in the Cloud. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment that I will then fork under a different license and claim as my own.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

Dave Thomas, co-author of The Pragmatic Programmer and Agile Manifesto, on the true spirit of being agile (vs. "doing agile"), common mistakes engineering teams make, and common practices of successful teams. Segments: [00:23] Dave's background [08:45] The genesis of The Pragmatic Programmer [12:47] People don't know what they want, importance of feedback loops [20:24] Doing Agile vs. being agile [24:43] Practices of successful engineering teams [34:42] Being pragmatic at an early stage startup [42:07] Things that are still true 24 years after the book was published [53:32] How does a book define its author's identity? Show notes: - The Pragmatic Programmer book: https://amzn.to/47ewEnU - The Pragmatic Bookshelf: https://pragprog.com/ - The Agile Manifesto: https://agilemanifesto.org/

Stephanie is engrossed in Kent Beck's Substack newsletter, which she appreciates for its "working thoughts" format. Unlike traditional media that undergo rigorous editing, Kent's content is more of a work-in-progress, focusing on thought processes and evolving ideas. Joël has been putting a lot of thought into various tools and techniques and realized that they all fall under one umbrella term: analysis. From there, Stephanie and Joël discuss all the productivity tricks they like to use in their daily workflows. Do you have some keyboard shortcuts you like? Are you an Alfred wizard? What are some tools or mindsets around productivity that make YOUR life better? Kent Beck's Substack Tidy First? (https://tidyfirst.substack.com/) Debugging: Listing Your Assumptions (https://thoughtbot.com/blog/debugging-listing-your-assumptions) Dash (https://kapeli.com/dash) Alfred (https://www.alfredapp.com/) Rectangle (https://rectangleapp.com/) Meeter (https://apps.apple.com/us/app/meeter-for-zoom-teams-co/id1510445899) Vim plugins (https://github.com/thoughtbot/dotfiles/blob/main/vimrc.bundles#L32-L50) from thoughtbot's dotfiles, including vim-projectionist () for alternate files Go To Spec VS Code plugin (https://marketplace.visualstudio.com/items?itemName=Lourenci.go-to-spec) Feedbin (https://feedbin.com/) Energy Makes Time by Mandy Brown (https://everythingchanges.us/blog/energy-makes-time/) Transcript: AD: Ruby developers, The Rocky Mountain Ruby Conference returns to Boulder, Colorado, on October 5th and 6th. Join us for two days of insightful talks from experienced Ruby developers and plenty of opportunities to connect with your Ruby community. But that's not all. Nestled on the edge of the breathtaking Rocky Mountains, Boulder is a haven for outdoor lovers of all stripes. Take a break from coding. Come learn and enjoy at the conference and explore the charm of Downtown Boulder: eclectic shops, first-class restaurants and bars, and incredible street art everywhere. Immerse yourself in the vibrant culture and the many microbrew pubs that Boulder has to offer. Grab your tickets now at rockymtnruby.dev and be a part of the 2023 Rocky Mountain Ruby Conference. That's rockymtnruby.dev, October 5th and 6th in Boulder. See you there. JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I have a new piece of content that I'm consuming lately. That is Kent Beck's Substack [chuckles], Kent Beck of Agile Manifesto and Extreme Programming notoriety. I have been really enjoying this trend of independent content creation in the newsletter format lately, and I subscribe to a lot of newsletters for things outside of work as well. I've been using an RSS feed to like, keep track of all of the dispatches I'm following in that way so that it also kind of keeps out of my inbox. And it's purely just for when I'm in an internet-reading kind of mood. But I subscribed to Kent's Substack. Most of his content is behind a subscription. And I've been really enjoying it because he treats it as a place for a lot of his working thoughts, kind of a space that he uses to explore topics that could be whole books. But he is still in the phase of kind of, like, thinking them through and, like, integrating, you know, different things he's learning, and acknowledging that, like, yeah, like, not all of these ideas are fully fleshed, but they are still worth publishing for people who might be interested in kind of his thought process or where his head is at. And I think that is really cool and very different from just, like, other types of content I consume, where there has been, like, a lot of, especially more traditional media, where there has been, like, more editing involved and a lot of time and effort to reach a final product. And I'm curious about this, like I mentioned, trend towards a little less polished and people just publishing things as they're working through them and acknowledging that the way they're thinking about things can change over time. JOËL: It sounds like this is kind of halfway between a book which has gone through a lot of editing and, you know, a tweet thread, which is pure stream of consciousness. STEPHANIE: Yeah, that's a really great insight, actually. And I think that might be my sweet spot in terms of things I enjoy consuming or reading because I like that room for change and that there is a bit of a, you know, community aspect to Substack where you can comment on posts. But, at least in my experience, has seemed, like, relatively healthy because it is, you know, you're kind of with a community of people who are at least invested or willing to pay [chuckles] for the content. So, there is some amount of good faith involved. His newsletter title itself it's called "Tidy First?" And so, that almost implies that it's, like, something he's still exploring or experimenting with, which I think is really cool. It's not like a I have discovered, like, the perfect way to do things, and, you know, you must always tidy first before you do your software development. He's kind of in the position of, this is what I think works, and this is my space for continuing to refine this idea. JOËL: I'm curious: are there any sort of articles that you've read or just thoughts in general that you've seen from Kent that are particularly impactful or memorable to you? STEPHANIE: Yeah. One I read today during my investment time is called Accountability in Software Development. And it was a very interesting take on the idea of accountability, not necessarily, like, when it's forced by others or external forces like a manager or, you know, your organization, but when it comes from yourself. And he describes it as a way to feel comfortable and confident in the work that he's doing and also building trust in himself and in his work but also in his teams. By being transparent and literally accounting for the things that he's doing and sharing them, communicating them publicly, that almost ends up diminishing any kind of, like, distrust, or shame, or any of those weird kind of squishy things that can happen when you hide those things or, like, hide what you're doing. It becomes a way to foster the good parts of working with other people but not in a necessarily like, resentful way or in a hierarchical way. I was really interested in the idea of accountability, ultimately, like, for yourself, and then that ends up just propagating to the team. JOËL: That's a really interesting topic because I think it sort of sits at the intersection of the personal and the technical. STEPHANIE: Yeah, absolutely. He mentions more technical strategies or tasks that kind of do the same thing. You know, he mentions test-driven development, as well as, like, a way of holding yourself accountable to writing software that, you know, doesn't have bugs in it. So, I think that it can be applied to, you know, exactly both of those, like, interpersonal stuff and also technical aspects too, anyway, that's what's new in my world. Joël, what about you? JOËL: So, this year, I've been putting a lot of thought into a variety of tools and processes. And I think I've come to the realization that they all really fall under one kind of umbrella term, and that would be analysis. It's a common step in some definitions of the traditional software development lifecycle. And it's where you try to after you've kind of gathered the requirements, try to break them down and understand what exactly that means from a technical perspective, what needs to happen. And so, a lot of the things that have been really fascinating to me this year have been different techniques that I can use to become better at that sort of phase. STEPHANIE: Wow. That's very powerful, I think. And honestly, the first thing that comes to mind is, how do you make time for it? JOËL: I think we all do it to a certain extent. You know, you pick up a ticket, and there is a prose description of some work to be done, hopefully not telling you directly, like, just go make a change to this class, but here's a business problem to be solved. And then you have to sort of figure out how to break it down. So, this can be as simple as, oh, what objects, what classes do I need to introduce for this change? But it might be more subtle in terms of thinking, okay, well, what are the edge cases I need to think about? Where are things that could fail, and how am I going to handle failure? So, there's a variety of techniques that you can use to get better at all of these. You can use them kind of at the micro level when thinking about just a ticket. You can use them when working on a larger epic, a larger initiative, a whole project because I think analysis fits into kind of all of these levels. And so, I think those are the techniques that have been most exciting to me this year and that have really connected. STEPHANIE: That is very exciting. It's triggering a lot of thoughts for me about how I incorporate analysis into my work and how that has actually evolved; where I think before, earlier in my career, I assumed that the analysis had been done by someone else who knew better than me or who knew more than me. And that by the time that you know, a piece of work kind of landed in my lap, I was like, okay, well, I just want to know what to do, right? Like, I want someone else to tell me what to do [laughs]. But now I think I have taken it upon myself to do more of that and, like, have realized that it's part of my role. And sometimes it will now be kind of a flag or, like, a signal to me when that hasn't been done. And I can tell when I receive a ticket, and it's, like, maybe missing the business problem or doesn't have enough information. And determining whether that is information that I need to go and find out, or if there's someone else who I can work together with to do that analysis with, or having a better understanding of, like, what is within my realm of analysis to do, and what I need to encourage other people to do analysis for before the work is ready for me. JOËL: I think there is an interesting distinction between more traditional requirements gathering and analysis, where traditional requirements gathering is getting all that business problem information from product people, from customers, things like that. The analysis step is often a little bit more about breaking down a business problem into, like, what are the technical ramifications of that? But there can be a little of a synergy there where sometimes, once you start exploring the technical side of it, it might bring up a lot of edge cases that have impacts on the product side, on the business side. And then you have to go back to the businesspeople and say, "Hey, we only talked about sort of the happy path. What happens if payment is declined? What do we want to do there?" And now we're back in sort of that requirements gathering phase a little bit more rather than purely analysis. But it can come out of an analysis phase where you've done maybe some state machine diagramming to try to better understand how things flow from one phase to another. Or maybe you were building out a truth table for some complex logic and realized, wait a minute, there's an edge case I didn't handle. It's not a strictly linear process. The two kind of feed into each other and, honestly, into the implementation side as well. STEPHANIE: Yeah, I'm with you there. I'm thinking about a piece of work that I've been working on, where we were thinking of doing a database migration and adding some new columns to a table. But the more I dug into it, the more I realized that that was the first idea or the immediate idea that came from a need that I had limited information about. And what was nice was I was able to sit on it for a little bit, get some input from others. And I realized that there were all of these things that I couldn't answer yet. And someone, I think literally asked in a code review if you've already done this analysis, between knowing that these columns will be the kind of extent of what you need versus, you know, will the data end up needing more columns? And should the data model be a little more flexible to that potential change? And they said, "If you had already done this analysis, then, like, otherwise, it looks good to me." And I was like, "Oh, I didn't." [laughs] And that encouraged me to go back to some cross-functional members of the team and ask more questions. And that has taken more time. That was another challenge that I had to encounter was saying like, "Yeah, we started this, and we made some progress. But actually, we need to revisit a few things, like a few parts of the premise, before continuing on." JOËL: Are there any techniques or approaches that you particularly enjoy when it comes to doing an analysis or that maybe are go-to's for you? STEPHANIE: Reminding myself to revisit my assumptions [laughs], or at least even starting by being really clear about what I'm assuming, right? Because I think that has to happen first before you can even revisit them is having an awareness of what assumptions you're making. And I actually think this is where collaboration has been really helpful, where I've been working on this task with another developer on my team. And when we've been talking about it, I found myself saying, "Oh, I'm assuming this," right? Or, like, I'm assuming that the stakeholder knows what they need [laughs]. And that's why we're going to do it this way, where we were kind of given the pieces of data that we should be persisting. And the more that we had that conversation, the more I realized, like, actually, like, I'm not convinced that they have that full picture of, like, what they need in the future. And because we're making this decision now, like, we are turning, you know, literally from, like, the abstract into, like, a concrete change [chuckles] in the database, now seems like...now that we're faced with that decision, it seems like a good time to revisit the assumption that I was making. And that has proved helpful in making ultimately, like, a more informed decision about, like, which way to go technically. But I personally have found a lot of value in verbally processing it with someone else. It's a lot harder for me to identify them, I think, when I'm in my own head. JOËL: That's really interesting that you keyed in on the idea of assumptions. I typically think of assumptions being, like, so important mostly in debugging rather than analysis. In fact, I wrote a whole blog post about why listing your assumptions is so important as part of your debugging process. Now, like, my mind is spinning a little bit. I'm like, oh, I wonder if I could use some of those, like, debugging techniques as part of more of my analysis step. And could that make me better? So, I think you've put me on a whole, like, thought track of, like, oh, how many of these debugging techniques can I use to make my analysis better? So, that's really cool. STEPHANIE: Yeah, and vice versa. So, a few minutes ago, I'd asked you how you make time for that analysis. Because I was thinking that, you know, in my day-to-day work, I'm juggling so many things. I often find myself running out of time and not able to do all of it. And that, I think, leads us really well into our topic for this episode, which is productivity tricks and ways that we make the most use out of our limited time. JOËL: I think I may have a maybe a bit of a controversial opinion on productivity tricks. I feel like a lot of productivity tricks don't actually make me that much faster. Like, maybe I save a couple of minutes a day, maybe 5 or 10 a day with productivity tricks. And, sure, that adds up over the course of a year. But there are other things I could do in terms of, like, maybe better habits, better managing of my schedule that probably have a much more significant impact. Where I think they are incredibly valuable, though, is not directly making me better with my time management but managing my focus, allowing me to kind of keep in the flow and get things done without getting sidetracked. Or just kind of giving me the things that I need in the moment that I need them so that I'm not getting on to a subtask that I don't really need to be doing. STEPHANIE: Yeah. I really like that reframing of what helps you focus because as I was brainstorming ways that I stay on track for my work, I think I ended up discovering a similar theme where it wasn't so much, like, little snippets and tools for me, as opposed to how I structure all of the noise, I guess, in my day-to-day work and being able to see what it is that I need to care about the most right now. JOËL: I think one of the things that I've tried to do for myself is to make it easy to have access to the information and the tools that I need. Probably one of the most useful bits of that is a combination of the documentation viewer Dash and the...I'm not sure what it would be called– launcher, productivity manager tool for Mac. Alfred, with a CMD + Space, it brings up this bar I can type into. And then you can trigger all sorts of things from there. And so I can type the name of a language or some kind of keyword that I have set up and the name of a method. And then, all of a sudden, it'll show me everything like, you know, top five results. And I can hit Enter, and it will bring up the documentation for that. So, if I want to say, oh yeah, what is the order of the arguments for Enumerable's inject method (which I constantly forget)? You know, it's a few keyboard shortcuts, you know, CMD + Space Ruby Enumerable inject. It's fuzzy finding, so I probably don't even need to type all of that. Hit Enter, and I have the documentation right in front of me. So, that makes it so that I can get access to that with very little amount of context shifting. STEPHANIE: Yeah. I like what you said about how the tools are really helping you, like, narrow down, like, the views of, like, what is most important for you in that moment, and it's doing a little bit of that work for you. I think the couple of tools and apps that I actually did want to share are kind of similar. One MacOS app I really like is called Rectangle for windows management, which is really crucial for me because I don't enjoy like, swiping and tabbing between applications. I would much prefer just seeing, usually, just two things. I try to keep my screen limited to two different windows at once because once it gets more than that, I'm already just, like, overwhelmed [laughs]. And as I'm trying to focus a little bit more on just having, like, one thing be the focus of my attention at a time, Rectangle has been really nice in just really quickly being able to do my windows resizing. So, I usually have, like, either things split between my screen half and half. Like, right now, I have your face on my screen as we record this podcast, and then my notes editing software for taking notes about what we talk about. During my development workflow, it's usually, you know, just my editor, my terminal, and then maybe my browser ends up being, like, the thing that I tab into. But I'm able to just, like, set that all up, and as I need those windows to change depending on what my focus has been shifted to, to kind of make more space for whatever I'm reading, or looking at, or processing visually. The keyboard shortcuts that Rectangle...that I have now, you know, ingrained into my fingers [laughs] has been really helpful. It's like, I'm not fussing with just, like, too many things open. JOËL: I have yet to, like, dive into a window manager. I'm still in the clunky world of CMD tabbing. But maybe I should give that a try. STEPHANIE: For me, it has helped even just, like, identify the things that I need to give more space to on my screen and aggressively, like, cut everything else [laughs]. So, that's a really great MacOS app. And then, the other one is actually kind of a similar vein. It's called Meeter, M-E-E-T-E-R. And it has been really helpful for managing my meetings, especially my video call meetings where the video call software that's being used for the meeting may be variable. And also, when I have multiple email addresses that meetings are being sent to, you're able to sign into all of your calendar accounts. And it provides a really nice view of all of your meetings. It has a really, like, minimal, I guess, design in your toolbar, where it shows you how many minutes until your next meeting. And from that toolbar button, you can click to go to the video conferencing software directly for whatever meeting is up next. And you don't have to, you know, scramble to open Google Meet, or Zoom, or Webex, or whatever it is. And that's [chuckles] been nice, again, just kind of, like, cutting down on the amount of stuff that I need to remember and shift through to get to my destination. JOËL: I think I'm hearing kind of two themes emerge out of some of the things that we've shared. And I'd like to maybe explore them a little bit; one is the power of keyboard shortcuts. And I think that's maybe what a lot of us think of when we think of productivity apps, at least developers, right? We love keyboard shortcuts. And then, secondly, I think I'm hearing automation, right? So, you don't have to go through and, like, find that email or calendar link to find the Zoom link or whatever. It shows up in your toolbar. So, maybe we can dig into a little bit of the idea of keyboard shortcuts. Are you a person who like customizes a lot of keyboard shortcuts? And is that a part of your kind of productivity setup? STEPHANIE: Well, a while ago, we had talked about not keyboard shortcuts in the context of productivity, but I think I had mentioned that I was trying to use my mouse less [chuckles] because I was getting a little bit of wrist pain. And I think that actually has rolled into a little bit of, you know, just, like, more efficient navigation on my computer. I think my keyboard shortcut usage is mostly around window management, like I mentioned. I do feel like I have, like, a medium amount of efficiency in my editor. Sometimes, when I'm pairing with other people who use Vim, I'm, like, shook by how fast they're moving. And I have figured out what works for me in VS Code, and I don't think I need to get any faster. You know, I've just accepted that [laughs]. In fact, it's almost, like, the amount of speed and friction that I have, in my experience, is actually a little more beneficial for the speed that my mind works [laughs]. It kind of helps me slow down when I need to think about what I'm doing as opposed to just, like, being able to, like, do anything at my fingertips, and kind of my brain is just not able to think that fast. And then navigating Slack, which is where I also spend a lot of my time on my computer. Now, using Slack with my keyboard shortcuts has been really helpful because, again, I'm not, like, mindlessly browsing or clicking around. I'm just looking at my unread messages. One non-keyboard shortcut I really like with Slack is Command + K, which is the jump-to feature. And so, I'm using that to go to a specific channel that I know I'm looking for or my own personal DMs, where I keep a lot of notes as well. And, honestly, I think that's, like, the extent of my keyboard shortcut usage. I'm curious what your setup is in regards to that, though. JOËL: I think I'm similar to you in that I have not kind of maxed out the productivity around keyboard shortcuts. You'd mentioned the jump to in Slack. Several pieces of software have something kind of like that. It might be some sort of omnibar, or a command palette, or something like that, where you really just need to know...CMD + K, or CMD + P, CTRL + P are common ones. Then you can sort of, like, type a few characters to just describe the thing you want to do, or a search you want to make, or something like that. Just knowing that one keyboard shortcut for your one piece of software gets you, I don't know, 80% of the productivity that you want. It's kind of amazing. I love the idea of an omnibar. STEPHANIE: Yeah, I hadn't heard of omnibar as a phrase before, but that feels very accurate. I like that a lot, too, where it's, like, oftentimes, I don't do whatever particular thing enough necessarily for it to justify a keyboard shortcut, for me at least. I'm still able to be fast enough to get to, like I said, that final destination or the action that I want to take with a more universal shortcut like that. JOËL: In my editor...so I use Vim, and I got used to Vim's keyboard-based navigation. And that is something that I deeply appreciate, maybe not so much for speed but being able to almost kind of feel one with the machine. And the cursor moves around, and I don't have to, like, think about moving it. It's really a magical sort of feeling. And it's become so much muscle memory now that I can just sort of...the cursor jumps around, things change out. And I'm not, like, constantly thinking about it to the point where now, if I'm in any other editor, I really want to get those shortcuts or, I guess, maybe not shortcuts but a Vim-style navigation, keyboard-based navigation. STEPHANIE: Yeah, it sounds like it's not so much the time savings but the power that you have or the control that you have over your tools. JOËL: Yes. And I think, again, the idea of focus. Navigation has stopped becoming a thing where I have to actively think about it. And I feel like I really do just sort of think my fingers are on the keyboard. I'm not having to, like, do a physical motion where I switch my hands. Like, I'm typing, and I'm writing code, then I have to switch my hand away to a mouse to shift around or, like, move my hand off the home row to, like, find the arrow keys and, like, move around. I just kind of think, and the cursor jumps up. It's great. Maybe I'd be the same if I'd put a lot of time into getting really good at, you know, maybe arrow-based navigation. I still think the mouse you have to move your hand off. It breaks just in the tiniest little way the flow. So, for me, I really appreciate being fully keyboard-based when I'm writing code. STEPHANIE: Right. Being one with the keyboard. As you were talking about that, I very viscerally felt, you know, when you encounter a new piece of technology, and you're trying to navigate it for the first time, and you're like, wow, like, that takes so much mental overhead that it's, you know, just completely disruptive to the goal that you're trying to achieve with the software itself. JOËL: Yeah, it is a steep learning curve. So, we've talked about custom keyboard shortcuts in the editor. But it's common for people to augment their editor with plugins, maybe even some kind of, like, snippet manager to maybe expand snippets or to paste common pieces in. Is that something that you've done in your editor setup? I think you said you use VS Code as your sort of daily editor. STEPHANIE: Yeah, that's right. I actually think I almost forgot about some of my little bits of automation because they are just so spelled for me [laughs] that I don't have to think about them. But you prompting me just now reminded me that there are a few that I'd like to shut out. Snippets-wise, I mostly use them for when I'm writing tests and just having the it blocks or the context blocks expand out for me so I don't have to do any of that typing of the setup there. And since I do use a terminal outside of my editor...I know that some people really like kind of having that integrated and being able to run tests even faster without having to switch to a different application, but I like having them separate. There is a really great plugin called Go to Spec where you can be in any, you know, application code file, and it will pull up the spec file for you. I've been really enjoying that, and that is what helps my test writing be a little more automated, even though I'm having it in separate applications. JOËL: That is really useful. So, as a Vim user, I also have a plugin that does something similar, where I can switch to what's considered the alternate for a particular file, which is typically the spec, or if I'm in the spec, it'll switch to the source file that the spec is testing. STEPHANIE: And then, I do have one really silly one, which is that I got so sick and tired of not remembering how to, you know, type the symbols for string interpolation in Ruby that has also become a snippet where the hash key and the [inaudible 28:48] brackets can [laughs] populate it for me. JOËL: I love it. So, Stephanie, I'd like to go back to something you were talking about earlier in the show. When you were sharing about what was new in your world and, you mentioned that you subscribe to the Substack and that you subscribe to, actually, a lot of newsletters, and you said something that really caught my attention. You were saying that you don't want these all cluttering up your email inbox. And instead, you send all of these to an RSS reader application. What kind of application do you like to use? STEPHANIE: I use Feedbin for this. And I actually think that this was recommended by Chris Toomey back in the day on a previous Bike Shed episode before you and I hosted the show. But that has been really awesome. It has a just, like, randomly generated email address you can use when you sign up for newsletters. You use that instead. And I really like having that distinction because I honestly treat my email inbox as a bit of a to-do list, where I am archiving or deleting a lot of stuff. And then the things that remain in my inbox are things that I need to either respond to, or do, or get back to in some way. And then yeah, when I've completed it, then that's when I archive or delete. But now that we do have all this great content back in email form, I needed a separate space for that, where I similarly kind of treat it as, like, a to-read list. And yeah, like, I look at my unreads in the newsletter RSS reader that I'm using and go through that when I'm in a blog-reading kind of mood. JOËL: I really like that separation because I'm kind of like you. I treat my inbox as a to-do list. And it's hard to have newsletters come in and, like, I'm not ready to read them. But I don't want them in my to-do, or, like, they'll just kind of sit there and get mixed in and maybe, like, filtered down to the bottom. So, having that explicit separation to say, hey, here's the place I go to when I am in a reading mood, then I can read things. I think there's also I've sort of trained myself to only check my email during certain times. So, for example, I will not check my work email outside of working hours. But if I'm on the subway going somewhere and I've got some time where I could do some reading, it would probably be a good thing to be going through some kind of newsletter or something like that. So, I either have to remember to go back to it, or what I tend to do is just scroll Twitter and hope that someone has shared that link, and then I read it there, which is not a particularly effective way of doing things. So, I might try the RSS feed reader tool. What was it called? STEPHANIE: Feedbin. JOËL: Feedbin. All right, I might try to get into that. STEPHANIE: Yeah, I look forward to hearing if that ends up working for you because I agree, having the two separate spaces has been really helpful because I don't want to get distracted by my email/to-do list inbox if I'm just wanting to do a bit of reading, enjoy some content. So, one more theme around productivity that I don't think we've quite mentioned yet, but maybe we've talked a little bit around, is the idea that it's, at least for me, it's a product of time and energy. So, even if you have all the time in the world, you know, you can just stare into space or, like, stare at a line of code and not get [laughs] anything done. JOËL: I know the feeling. STEPHANIE: Right? I am kind of curious how or if you have any techniques for managing that aspect. When your focus is low like, how can you kind of get that back so that you can get back to doing your tasks or getting what you need to do done? JOËL: If I have the time, taking a break is a really powerful thing, particularly taking a break and doing something physical. So, if I can go outside and take a walk around the block, that's really helpful. And if I need a shorter thing that can be done in, like, five minutes or something, I have a pull-up bar set up in my place. So, I'll just go up and do a few sets there and get a little bit of the heart rate slightly up, do a little bit of blood pumping. And that sometimes can help reset a little bit. STEPHANIE: Nice. Yes, I'm all for doing something else [chuckles]. Even when you know that this is a priority or is kind of urgent or whatever, but you just can't get yourself to do it, I've found that asking myself the question, "What would make this task easier for me right now?" has been helpful during those moments. And, for me, that might be grabbing a friend, like, maybe I'm blocked because I'm really just unmotivated. But having someone along can kind of inject some of that energy for me. And then, there's a really great blog post by a woman named Mandy Brown. It's called Energy Makes Time. And she talks about how doing the things that fill our cup, actually, you know, even though it seems like how could we possibly have time to be creative, or, like you said, maybe do something physical, those seem, like, lower on the priority list. But when you kind of get to the point where you just feel so overwhelmed and can't do anything else, and you just go do those things that you know feel good for you, you kind of come back with a renewed perspective on your to-do list. And you can see, like, what things actually aren't that critical and can be taken off. Or you just find that you have the capacity or the energy to get the things that you are really dreading out of the way. So, that has been really helpful when I just am feeling blocked. Instead of, like, feeling bad about how unproductive [chuckles] I'm being, I take that as a sign of an opportunity to do something else that might set me up for success later. JOËL: Yeah. I think oftentimes, it's easy to think of productivity in terms of, like, how can I maybe eliminate some tasks that are not high value through clever automation, or keyboard shortcuts, or things like that? But oftentimes, it can be more about just sort of managing your focus, managing your energy. And by doing that, you might have a much higher impact on both how productive you feel—because that's an important thing as well, in terms of motivation—and, you know, how productive you actually are at getting things done. STEPHANIE: Right. At least for me, like, not all TDM is bad and needs to be automated away, but, like, my ability to, like, handle it in the moment. Whereas yeah, sometimes maybe I've just run the same few lines that should be just a script [chuckles], that should just be, you know, one command, enough times that I'm like, oh, like, I can't even do this anymore because of just, like, other things going on. But other times, like, it's really not a big deal for me to just, you know, run a few extra commands. And, like, that is perfectly fine. JOËL: I love writing a good Vim macro. Yeah. So, it's important to think beyond just the fun tools and the code that we can write. Kind of think a little bit more at that energy and that mental level. That said, there are a ton of great tools out there. We've named-dropped a bunch of them in this episode. For our listeners who are wondering or who weren't, like, necessarily taking notes, we've linked all of them in the show notes: bikeshed.fm. You can find them there. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.