Agile Mentors Podcast from Mountain Goat Software

AI can make teams faster. But it can also quietly make them worse. In this episode, Brian Milner and Hunter Hillegas dig into the risks no one wants to talk about—from eroding developer judgment to weakening team communication—and what healthy teams should do about it.   Overview AI tools are powerful. They can generate code, draft tests, and accelerate delivery in ways that felt impossible just a few years ago. But speed is not the same as effectiveness. In this episode, Brian sits down with Mountain Goat Software CTO Hunter Hillegas to explore where AI may actually be hurting Agile teams. They discuss the risk of losing junior developer growth paths, the illusion of productivity through inflated metrics, the danger of outsourcing judgment, and how AI can quietly create communication silos inside Scrum teams. This is not an anti-AI conversation. It is a practical one. You will hear what guardrails healthy teams should consider, why accountability still belongs to humans, and how to use AI as a tool without letting it reshape your culture in ways you did not intend. If your team is leaning into AI, this episode will help you do it with your eyes open.   References and resources mentioned in the show: Hunter Hillegas Blog: AI Doesn’t Eliminate Agile Teams — It Increases the Need for Great Ones by Mike Cohn #169: Building Practical AI for Agile Teams with Hunter Hillegas #82: The Intersection of AI and Agile with Emilia Breton #151: What AI Is Really Delivering (and What It’s Not) with Evan Leybourn & Christopher Morales Mountain Goat Software Subscribe to the Agile Mentors Podcast    Want to get involved? This show is designed for you, and we’d love your input.   Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.   Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.  Hunter Hillegas is the Chief Technology Officer at Mountain Goat Software. With over 20 years of experience in software development, product ownership, and team leadership, he leads the creation of tools like the AI Toolkit and Team Home to support effective, engaging learning experiences. Hunter lives in Santa Barbara, California, with his wife and their dog Enzo.

Estimating can bring out strong reactions, and for good reason. Mike Cohn and Brian Milner unpack why it gets misused, what “estimate responsibly” really means, and how to use planning to make better decisions without turning numbers into weapons. Overview In this episode, Brian sits down with Mike Cohn to talk about estimating and planning in a way that teams can actually live with. They explore why estimates became such a hot button topic, what the “no estimates” movement is reacting to, and how Mike’s thinking has evolved over time. You will hear practical guidance on story points versus time, why teams should estimate only when it helps someone make a decision, and how to keep estimates from damaging trust. They also cover where flow metrics help, where they fall short, and how teams build credibility with leadership through responsible planning. References and resources mentioned in the show: Mike Cohn Estimating & Planning in Agile - A 2026 Field Guide Accurate Agile Planning Course Blog: Estimating and Planning in Agile: Why They Still Matter in 2026 by Mike Cohn Blog: Getting Better Estimates Is Easier Than You Think by Mike Cohn Blog: What Are Agile Story Points? By Mike Cohn Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Hiring for Scrum roles is harder than it looks. Making the wrong call can derail an Agile transformation before it even starts. In this episode, Brian and Cort unpack what to actually look for in Scrum Masters, Product Owners, and Developers—beyond the job title and shiny certifications. Overview What makes someone a great Scrum Master? How do you spot the difference between a capable Product Owner and a glorified backlog manager? And what qualities matter most in a developer on a cross-functional Agile team? In this episode, Brian Milner and Cort Sharp dig into one of the most foundational (and overlooked) parts of successful Agile adoption: hiring. You’ll learn what to include—and what to avoid—in your job descriptions, how to interview for the “real” skills that matter, and why collaboration often matters more than technical brilliance. Whether you're filling new roles or leveling up existing ones, this conversation will help you build stronger, more resilient teams from day one. References and resources mentioned in the show: Cort Sharp Blog: 7 Questions to Determine if Being a Scrum Master Is Right for You by Mike Cohn #155: Preparing for Interviews the Agile Way with Tali Shlafer #157: What Teams Are Struggling With Right Now with Cort Sharp Agile Skills Video Library Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Cort Sharp is an Agile Coach, Trainer, and Scrum Master. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years.

Most agile transformations start with energy, and then stall out when things get complex. In this episode, Mike Cohn returns with a practical framework to help teams and leaders spot what’s missing, build lasting momentum, and navigate change with more clarity and intention. Overview Agile isn’t just a set of practices—it’s a mindset shift, a role shift, and a culture shift. And without the right support, even the best-intentioned transformation efforts can lose steam. In this episode, Mike Cohn joins Brian to walk through his Five Pillars of Agile Transformation—a practical structure for guiding change that actually sticks. Whether you're leading a single team or rolling out agile across the organization, this conversation will help you focus your efforts, spot common gaps, and use agile principles to strengthen your transformation from the inside out. References and resources mentioned in the show: Mike Cohn What Happens When One of the Pillars is Missing Graphic The Five Pillars of a Successful Agile Transformation by Mike Cohn #102: Communicating Agile Transformations with McCaul Baggett #110: Overcoming Organizational Dysfunctions with Lucy O’Keefe #152: The Five Pillars of Real Agile Improvement with Mike Cohn Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Most teams aren’t broken because of individual incompetence. They’re struggling because the group itself isn’t set up to thrive. In this episode, author and researcher Colin Fisher joins Brian to reframe how we think about team performance, conflict, and psychological safety through the lens of real science, real practice, and a little jazz. Overview Group dynamics aren’t fluff. They’re the operating system behind every Agile team’s success (or struggle). Colin Fisher, author of The Collective Edge, joins Brian to share what decades of research and hands-on observation reveal about high-performing teams. From ideal team size (spoiler: it’s 4.5), to avoiding the trap of blaming individuals for systemic issues, Colin offers a practical, thought-provoking look at how to build more resilient, collaborative, and human-centered teams. Expect fresh insights on team launch moments, role clarity, feedback culture, remote collaboration and how to keep your team “groupy” in the best possible way. References and resources mentioned in the show: Colin Fisher Collective Edge by Colin Fisher Colin's Free Newsletter LinkedIn YouTube #80: From Struggling to Success: Reviving Agile Teams with Mike Cohn #143: What Still Makes Teams Work (and Win) with Jim York Self-Organizing Teams Are Not Put Together Randomly by Mike Cohn Agile Skills Video Library Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Colin Fisher is a former professional jazz musician turned organizational behavior expert who now helps teams unlock their creative and collaborative edge. A professor at University College London and author of The Collective Edge, Colin draws on decades of research—and a bit of jazz improv—to help leaders understand what really makes groups tick.

What can Agile leaders learn from the Marines? In this episode, Tanner Wortham joins Brian to share how principles of military leadership—like building authority into the trenches, experimenting under pressure, and prioritizing shared mission over ego—map surprisingly well to modern Agile teams. Overview In this conversation, Brian sits down with Marine Corps veteran and Execution Architect Tanner Wortham to explore the parallels between leading Marines and leading Agile teams. Drawing from both military and coaching experience, Tanner unpacks how the Corps’ “rule of three,” mission-first mentality, and obsession with experimentation mirror the best of Agile thinking. They discuss how effective leadership empowers decision-making at the edges, why conflict shouldn't be avoided but navigated with curiosity, and how facing toward hard problems—rather than away from them—builds high-performing, resilient teams. Whether you're coaching a Scrum team or leading large-scale transformations, Tanner’s insights offer a fresh lens on what it really means to lead with agility. References and resources mentioned in the show: Tanner Wortham What the Corps Calls Leading Marines Others Call Agility #113: Influence Without Authority with Christopher DiBella #135: Leading Without Authority with Pete Behrens #132: Can Nice Guys Finish First? with Scott Dunn Get the Agile Skills Video Library Use code PODCASTSKILLS for $10 off Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Tanner Wortham is a former Marine turned leadership coach who helps teams and execs cut through the noise, lead with clarity, and actually get things done. With experience at LinkedIn, Salesforce, and beyond, he brings a no-fluff, human-first approach to growth, agility, and real leadership.

It’s not just about cool tools. Hunter Hillegas (CTO at Mountain Goat Software) joins Brian to unpack what it’s really like to build with AI—from hallucinations and context management to dev workflows, testing strategies, and where the humans still matter most. Overview This episode dives deep into the real work behind bringing AI into agile. Brian and Hunter trace the arc from early experiments to full-scale agents, sharing what it took to build responsibly on large language models (and what still keeps them up at night). They get into the weeds of context handling, trust and verification, dev productivity, and what makes a good AI coach actually helpful. Along the way, they explore how tools are changing—faster than most teams can keep up—and what that means for the future of learning, coding, and collaborating in agile environments. References and resources mentioned in the show: Hunter Hilligas AI Tool Kit Agile Skils Video Library Mike's Better User Stories Webinar #82: The Intersection of AI and Agile with Emilia Breton #151: What AI Is Really Delivering (and What It’s Not) with Evan Leybourn & Christopher Morales #161: Test-Driven Development in the Age of AI with Clare Sudbery #166: AI Isn’t Coming for Your Job, But It Is Joining Your Team with Dr. Michael Housman Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Hunter Hillegas is the Chief Technology Officer at Mountain Goat Software. With over 20 years of experience in software development, product ownership, and team leadership, he leads the creation of tools like the AI Toolkit and Team Home to support effective, engaging learning experiences. Hunter lives in Santa Barbara, California, with his wife and their dog Enzo.

It’s not a full episode this week—but it might be the one your heart needs. Brian Milner shares what he’s truly grateful for this year (spoiler: it’s not a new tool or framework), reflects on the human side of agility, and invites you to join him in a quick pause before the final sprint of 2025. Overview In this special solo episode, Brian Milner pauses to reflect on what he's most grateful for this year—and invites you to do the same. From a renewed focus on the human side of agility to the evolving nature of our roles as leaders and practitioners, this heartfelt message is a reminder that change isn’t just necessary—it’s powerful. Brian also shares his appreciation for the Mountain Goat Software team and a behind-the-scenes shoutout to Agile Mentors’ own Laura Kendrick for making the show possible. Short, sweet, and soul-centered, it’s a moment to breathe, acknowledge growth, and say thanks before we sprint toward the end of the year. References and resources mentioned in the show: Five Lessons I’m Thankful I Learned in my Agile Career by Mike Cohn #123: Unlocking Team Intelligence with Linda Rising #125: Embracing Gratitude in Challenging Times with Brian Milner #134: How Leaders Can Reduce Burnout and Boost Performance with Marcus Lagré Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Consultant and collaboration expert Evan Unger joins Brian to share practical tactics for leading more engaging, effective meetings that actually get results (and don’t drain everyone’s will to live). Overview In this episode of the Agile Mentors Podcast, Brian Milner welcomes longtime consultant and facilitation expert Evan Unger to dig into one of the most persistent workplace headaches: remote meetings. With decades of experience helping leaders shift from “presenting at” to true collaboration, Evan shares how a simple POPRA framework can change the game, why simultaneous chat might be your new secret weapon, and what leaders get wrong when they step into the (virtual) room. From deprogramming the HIPPO effect to humanizing remote collaboration, this conversation is packed with real talk, useful tools, and just enough snark to make you want to fire up your next Zoom meeting with purpose. References and resources mentioned in the show: Evan Unger Collaborative Leadership: A Virtual Immersion™ Program #138: The Bad Meeting Hangover with Julie Chickering #142: Communication Patterns Keeping Your Team Stuck with Marsha Acker Agile Skills Video Library Use code PODCASTSKILLS for $10 off Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Evan Unger is a collaboration expert and consultant who’s spent over three decades helping leaders turn messy meetings into meaningful progress—even in a post-pandemic, Zoom-fatigued world. As managing partner at Schwartz + Associates, he now trains leaders in the art of virtual facilitation and high-stakes collaboration, so teams can stop surviving meetings and start making decisions that actually stick.

AI is already changing how we work—and how we work together. In this episode, Dr. Michael Housman joins Brian Milner to explore how AI is reshaping team collaboration, decision-making, and the very structure of Agile teams. Overview We keep talking about AI like it’s something that’s coming. But as Dr. Michael Housman points out, it’s already here—embedded in our tools, shaping how we collaborate, and quietly shifting the makeup of our teams. In this episode, Brian sits down with Dr. Housman, CTO, keynote speaker, and author of the upcoming Future Proof: Transform Your Business with AI or Get Left Behind, to talk about what AI is already doing in Agile environments. From how it’s helping Scrum Masters level up decision-making to how it might literally join your org chart, they dig into what’s helpful, what’s hype, and what leaders need to pay attention to right now. References and resources mentioned in the show: Dr. Michael Housman #82: The Intersection of AI and Agile with Emilia Breton #99: AI & Agile Learning with Hunter Hillegas #151: What AI Is Really Delivering (and What It’s Not) with Evan Leybourn & Christopher Morales #165: Can Your Product Process Keep Up With AI with Cort Sharp Agile Skills Library use code PODCASTSKILLS for $10 off Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Dr. Michael Housman is the author of Future Proof: Transform Your Business with AI (or Get Left Behind) and the founder and CEO of AI-ccelerator where he helps organizations leverage advances in artificial intelligence. He is a seasoned technologist with over 15 years of experience architecting AI platforms in sectors ranging from hiring and fraud detection to customer communication and real estate lending. His research has been published in a variety of peer-reviewed journals and profiled by such media outlets as The New York Times, Wall Street Journal, The Economist, and The Atlantic. Dr. Housman received his A.M. and Ph.D. in Applied Economics and Managerial Science from The Wharton School of the University of Pennsylvania and his A.B. from Harvard University.

If AI is speeding up how fast we can ship, what’s slowing teams down now? Brian and returning guest Cort Sharp dig into the emerging friction between AI-assisted development and the still-slow art of product decision-making. Overview With AI accelerating software delivery, it’s no longer the developers dragging their feet. It’s the backlog that’s backing everything up. In this episode, Brian and Cort tackle the big shift: as coding becomes faster and easier, the real challenge becomes knowing what to build, why, and whether it’s worth it. They talk about feature bloat, the myth of productivity, the “good enough” curve, and why product owners are quietly becoming the most critical role on agile teams. Plus: short sprints, fake one-day sprints, and a healthy dose of “what even is a Sprint, anyway?” If you're feeling the tension between building faster and deciding smarter, this convo’s got your name on it. References and resources mentioned in the show: Cort Sharp #104: Mastering Product Ownership with Mike Cohn #3: What Makes a Great Product Owner? With Lance Dacy #164: Why Innovation Efforts Fall Flat with Tendayi Viki Get the Agile Skills Video Library Use code PODCASTSKILLS for $10 off Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years. Auto-generated Transcript: Brian Milner (00:00) Welcome back Agile Mentors. We're here for another episode of the Agile Mentors Podcast. I'm with you here as always, Brian Milner. And today I have back the one and only Cort Sharp with us. Welcome back Cort. Cort Sharp (00:11) Hey Brian, thanks for having me. Brian Milner (00:13) Yeah. Cort and I were chatting just in between engagements and things we were talking about going on. Cort's coaching a lot recently, and I've been coaching a lot recently as well. And so we've been kind of sharing stories and talking about kind of some of the things we've been experiencing. And you came across something really interesting recently that I thought we talked about might make a good topic. help us out. What was that that you came across? Cort Sharp (00:42) Yeah, so I've seen this idea pop up a few times actually on LinkedIn specifically, but I've seen it trickle out into other areas within the coaching that I've been doing recently, but also just in other pieces or parts of the internet as well. And it's this idea of like with AI being brought into organizations, brought into companies, helping out developers so much that AI has actually lowered that barrier. for the programming side of stuff, programming side of the development side of things, that the new blocker that is currently emerging, so the new piece that's been slowing everyone down now is actually the product management side of stuff itself, which I thought was just so fascinating because I've done a little programming, definitely more in the product management side of things now, but I kept seeing this pop up and I was like, man. I would love to just hear, you know, Brian's thoughts about this and the community as a whole, everyone's thoughts about this a little bit here too, but I have my own thoughts, but just quick little immediate reaction to that idea there, Brian. How does that make you feel? What do you think of that? Brian Milner (01:51) Yeah, I actually have been thinking this was coming for a while. I don't have this prepared, so please don't get me wrong in this. I know I always say data didn't happen. But there are three studies that I found at one point that were trying to determine the number of features in just your average software project that were rarely or never used. And it was three separate studies spread out over years. And one of them was like 48%. That was the low one, was like 48%. Then there was a middle one that was 64. And then there was another one that was more recent that said like 80%. And I mean, think about that, know, like I, even if you take the low end, And so, you know, 48, let's just round it up to 50 just to make it easier to have the conversation. But let's just say out of those three studies, we say it's 50 % of features that people are building are things that people rarely or never use. Now I get it that there are some rarely used features that are essential, right? Like admin functions and things. You may not use those all the time or it may not be a huge swath of users. that uses that, but you have to have them. So set those aside because that's not 50 % of what's being developed, right? And I think if that's true, if we even like go on the low end of that and say that it's closer to 50%, then that's an awful lot of productivity that's being lost. Not to mention just money and energy and effort. of developers to build stuff that no one cares about. Those studies were all prior to AI. So let that sink in, right? If those are prior to AI and we were seeing at the low end, 50%, you know, across those surveys of things that no one was using. Well, that's where I've been kind of forecasting this to say, if, if AI is speeding up our process to build things. the actual development of things, then what's going to become painfully obvious very quickly is that the bottleneck isn't developers. And it, you know, my point from saying that in classes is to say it's never been right. It's not been developers that have been the bottleneck to us being more successful. That's where the focus has been. But I don't think that was correct. And I think that the correct area to put it on is the product side. And if that's true, right, I know I'm doing a lot of leaps here, but if that's true, if it is the product side, well, I think that what that really translates to is the discipline of product management, of being able to recognize what's valuable. Cort Sharp (04:50) Mm-hmm. Brian Milner (04:54) to your customers to deliver that, to close the loop and verify that that's actually what was needed and to measure the impact of those things, that discipline, I think, becomes just all the more essential because that stat tells me there's a lot of bad product management going on. So that's my initial thought. That's a lot of thoughts, but that's my initial thought when you said that. What about you? What do you think about that? Cort Sharp (05:19) right there. I'll share my thoughts, but I do want to harp on or just go back to your first initial one of the callback to those studies there. When you first threw out those, because I've seen similar studies where it was about 50 % was kind of it. I haven't seen those studies that say like, know, what was the last one you threw out there on the high end, like 80 something percent. ⁓ Brian Milner (05:39) Yeah, actually I remember, so I remember two of them. The 64 % one was from a group called the Standish group. There's been some question about their methodology in that one. I haven't seen the methodology of the 80 % one, but it was a group called Pindo that did that one. And I don't remember the 48 % one. that's just off top of my head. Cort Sharp (06:01) Sure. But that 80 % one though, that one sticks out to me because as you were going through it, I was like, okay, well, I have Google Docs open right here just for some show notes or something. Just make sure I ask the questions that I'm supposed to ask or I want to ask. And I thought, wow, I'm looking at the menu bar right here. I use maybe, two or three of these consistently. And there's like 15 options up here. yeah, I could absolutely see a large majority of features that a product has that go widely unused by the vast majority of its users. And I think that poses the question then is, do we wanna go down the path of having one product be really good for, or like, really good at one thing and then kind of OK at everything else. The thing that always comes to my mind in this, and I've been going down this rabbit hole of kind of digital minimalism, is like the cell phone, right? Where it's a really great communication device. OK camera, kind of OK video, kind of OK speaker if you want to use it once in a while. It's kind of OK at browsing the web or doing some other things on there. Brian Milner (07:05) Yeah. Cort Sharp (07:21) Is it worth making those products that have an okay aspect to it on these other things that, you know, some people like to use, but not everyone will use all the time type deal thing, which is a totally different discussion here. But that's kind of where my memory went of like, okay, that 80 % plus isn't actually all that surprising to me. I would, I would probably throw out there, you know, for the vast majority of programs that I use, baby, aside from my banking. Brian Milner (07:35) Right. Cort Sharp (07:48) my banking apps, you know, I don't use, I probably only use 10 to 15%, maybe 20 % of the total features in there. and I, it is such a interesting point to the productivity side of stuff of, okay, are we just being productive for the sake of being productive? is it actually being productive? Are we just work

Tendayi Viki joins Brian to unpack the difference between doing innovation and delivering value, with practical takeaways for product folks, innovation teams, and anyone who wants to stop spinning their wheels. Overview Innovation theater. Experimentation theater. Value that never quite materializes. In this episode, Brian Milner sits down with Tendayi Viki—author, strategist, and partner at Strategyzer—to talk about why so many organizations look like they’re innovating… but aren’t. Together, they dig into what real innovation looks like (and how to measure it), how to escape the trap of cool ideas with no customer value, and why experiments only matter if they lead to decisions. You’ll also learn how to spot the difference between a small bet and a large leap, and what it actually means to “be a pirate in the navy.” References and resources mentioned in the show: Tendayi Viki Tendayi’s Books Get the Agile Skills Video Library Use code PODCASTSKILLS for $10 off Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Tendayi Viki is a globally recognized innovation strategist, author, and partner at Strategyzer, where he helps large organizations build real value—not just innovation theater. With a PhD in Psychology and a client list that spans Unilever to The British Museum, Tendayi brings deep insight into the human side of transformation, backed by frameworks that actually work. 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 always, Brian Milner. And today I'm very, very excited. I have Mr. Tendayi Vicki with us. Tendayi, welcome in. Tendayi Viki (00:13) Thank you. It's a pleasure to be here. Brian Milner (00:15) Very, very excited to have him here. Just to give you some background, if you're not familiar with his work, very prolific and very deep thinker here. He's a partner at a company called Strategizer, where he helps large companies innovate like startups. He's a regular contributor on Forbes, so you may have read some of his articles on Forbes. He's the author of three books, The Corporate Startup, Pirates in the Navy and the Lean Product Lifecycle. Pirates in the Navy is his latest one. Pirates in the Navy, correct me if I'm wrong, it's kind of about how to infiltrate via innovative presence in a large corporation. Is that correct? Tendayi Viki (00:55) Yeah, exactly. Yeah, how to be a pirate in the Navy. Brian Milner (00:58) I love it. I love the title. ⁓ But his books are really practical. They're on building innovation ecosystems that actually work. He's advised some big companies like Unilever, Amex, and Lutanza. He's been named to Thinker's 50 radar list for his influence and innovation and strategy. But his passion is really helping teams avoid Tendayi Viki (00:59) that. Brian Milner (01:22) what do you terms as innovation theater and focus on creating real sustainable value. So I thought maybe that's a good place to just start to kick off a conversation and say, Tendayi, talk to us about innovation theater. What does that look like to you? How would you define that? What does that mean? Tendayi Viki (01:41) Yeah, it's fascinating. It's a term that's kind of simultaneously coined by Rita McGrath. Steve Blank has used it a few times, and so has Alex Osterwalder. And it's really about... So the thing about the startup world is that the startup world is kind of a coolness factor. So everybody wants to be cool. And then the toolbox that startups use in that cool design thinking, deep school vibe of like sticky notes and... design and prototyping and all that. So everybody wants to do all of those things. I've even watched teams actually engage in agile rituals. Like they do the daily stand up, they do the demo day, they do the retro, right? But when you really look at the, when you dive deep into the focus, it doesn't seem to be a lot of value creation. So you're like, you're doing a... a retrospective as an agile team and you're not talking about what you learned from customers. You didn't do that during that week's sprint. yeah, you can do all the rituals, but if you don't understand the reason the rituals exist, then it's easy for you to kind of just spin and not create any value. And that's innovation theory. Brian Milner (02:42) Yeah. Yeah. man, I am with you a million percent on that and completely agree. These structures are there to help kind of be a pathway to that, but not the end result. If you don't understand, just like you said, if you don't understand the reason behind it, the why, then yeah, you could go through all the motions. And I completely get that term, It's kind of theater. It looks like it's actually happening, but it's not really happening. The culture underneath it is not really there. ⁓ So that brings the million dollar question then, right? If these structures like we do, like standups and everything else, aren't going to automatically generate that kind of innovation and it's more of a culture thing, Tendayi Viki (03:28) Exactly. Mm-hmm. Brian Milner (03:44) How do you then build a culture that is placing innovation as a priority? Tendayi Viki (03:53) So yeah, so just to answer your question, think one of the things that's really interesting about the way to create value is you have to authentically care about value creation first. You really have to understand this notion that innovation is this combination of really, really cool ideas, right? Together with a deep understanding of customers and their needs, and then a deep understanding of how to... use a business model that works to deliver that value to customers so you can get value back. Once you complete the entirety of that cycle, we say you're a successful innovator. If you complete the ideas or tech portion of that cycle, you're just an inventor or the ideas guy or whatever people call themselves, right? And so I find that companies excessively focus on ideas too much. And so too much focus on ideation and not enough focus on putting ideas on a journey towards value creation and actually value realization for the organization. So if you're going to build a culture for innovation, you have to understand what you're building it for. You to go, all right, we have to deliberately design our workflows and the way we interact with each other to discover what customers we need. Then we have to design the workflows to bring those customer needs into life through products. Then we have to test whether those products are really delivering that value. And then we have to figure out a way to scale that value and give value back to the moment of vision. you go, okay, that's the job. Now let's design the process, the culture, the toolbox, the artifacts, the rituals that allow us to actually do that. And I think that kind of understanding is probably more fundamental than anything else. Brian Milner (05:32) Yeah, absolutely agree. It's the structure for discovery, right? I mean, it's not the discovery. It's the structure that led you to the discovery that has to be repeatable that then can generate future discoveries. It's not how you found the island in the middle of the ocean. Or it's not the island you found in the middle of the ocean. It's how you found it. ⁓ that would lead you to find another one you know. ⁓ Tendayi Viki (05:55) Exactly. And that's the fundamental question is, can you find another island? Because again, innovation teams stumble a lot on good ideas. And so you can bumble into something good and then fail to do it again because you don't have a repeatable process. Brian Milner (06:01) Yeah. Yeah. So let's dive into that a little bit. mean, whether you're a startup or whether you're a bigger organization and you're working on a product in a bigger organization, I know that you can often feel like you're kind of, I was talking to someone this week about this, you kind of feel like you're drowning in a sea of opportunity. There's all these things that we could do and it's sometimes hard to find, well, which ones do we really Tendayi Viki (06:32) Mmm. Brian Milner (06:42) double down on which ones we invest in and really pour our time and energy and efforts into. So how do you talk about that in your book? How do you find the things that are worth really investing in? Tendayi Viki (06:54) Yeah. So I mean, mean, there's two ways, right? The one is the first one is a kind of like an art thing. It can be fed by data, but it's art and that's finding the direction of travel. So that's a strategy choice. We go, we think that an AI is big thing these days. We think that AI is going to do these various things to our business model. And that's really important, by the way, like when you think about AI. And Sharjee, Alex also has got one of my favorite all-time phrases, is AI changes everything and AI changes nothing. The fundamentals for business are still the same, even though the stuff that you can do is exponentially different. So you have to think which elements of the business model do we want to play with around here strategically. Brian Milner (07:26) Yeah. Yeah. Tendayi Viki (07:41) And t

Five years post-COVID, are we any closer to knowing what kind of work environment actually works best? Brian and Lance dig into the real drivers behind return-to-office mandates, remote productivity myths, and why "context beats location" every time. Overview The return-to-office debate isn’t over—it’s evolving. In this episode, Brian Milner welcomes back frequent guest and fellow Agile coach Lance Dacy for a wide-ranging conversation about remote work, in-office mandates, and the big question: what actually boosts team performance? Together, they explore what we’ve learned (and what we haven’t) in the five years since COVID reshaped the way we work. With studies offering conflicting conclusions and executives often leading with personal preference, Brian and Lance unpack how leaders can navigate decisions that impact morale, productivity, and long-term value delivery. From context-driven collaboration to psychological safety, this is a nuanced take on one of Agile’s most pressing modern challenges. References and resources mentioned in the show: Lance Dacy Excerpt from A Leader's Guide to Agile eBook Scrum, Remote Teams, & Success: Five Ways to Have All Three by Brian Milner #61: The Complex Factors in The Office Vs. Remote Debate with Scott Dunn Using a Task Board with One Remote Team Member Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We are back. Thank you for bearing with us for a little bit of a break there. If you notice, we have not been releasing episodes the past few weeks because we've been practicing sustainable pace, but we are back and we are ready to dive into some really, really gritty topics, some things that we think will be really beneficial. Who better to kick us back off to bring us back around than a friend of the show, Lance Dacey, who is with us today. Welcome in, Lance. Lance Dacy (00:25) Right now. Thank you, Brian. How was Hawaii, that big sabbatical y'all took in July? Brian Milner (00:34) Yeah, Hawaii is always great, right? Hawaii is awesome. Absolutely. Isn't that what everyone did in July? ⁓ Well, we're glad to be back and we're excited about what we're going to talk about today because we figured why start with something that was not controversial? Why not find something very controversial? Lance Dacy (00:36) My tie's on the beach. That's where you over. I mean, I didn't see y'all there, but yeah. Brian Milner (00:58) and just set ourselves up to receive lots of disgruntled emails that we're probably going to get this wrong. We're probably going to get awesome feedback too. But I'll just go ahead and start by saying, hey, we hope you give us a little grace on this topic. We're just talking from our experience, our opinions. And I know there's lots of opinions on this, but we wanted to focus on the fact that Lance Dacy (01:06) No, awesome feedback, Brian. Awesome feedback. We're going to get awesome feedback. Brian Milner (01:25) Hey, we're five years removed from the COVID outbreak. And when COVID happened, that was a massive disruption in work. We all had to learn how to do work in a different way, but five years in, what have we learned? What's changed? And now we're seeing lots of things like return to office mandates and hybrid working agreements. You must be here for this many days a week or other things. Lance Dacy (01:44) and Brian Milner (01:50) or companies that say, no, we're now fully remote and we're doing things this way. But I saw this kind really interesting question that made me think about this. If you were designing the workplace from scratch today, would anyone build cubicles? And I thought, well, that's a really interesting question. So Lance, what do you think we've learned in the last five years? Where do think we are today with this whole work from home versus return to office? Lance Dacy (02:16) I tell you what, Brian, I sit there and think, man, five years is a long time to have empirical data. And I don't believe we have data. Let me say it this way. We got the data. What does it mean? You know, so and I'm a data guy. You all know that. And I'm sitting there trying to look at it going, I don't know how much we've learned. think what we've learned is there's no right answer. Brian Milner (02:22) Yeah. Yeah. Lance Dacy (02:39) And everybody's, especially organizations, we're looking for the right answer. Just give me the answer and let's go for it. You and I, coach and consult and people hire us to tell them sometimes what they need to do. And sometimes we're like, no, we're not going to tell you what to do. We're going to learn what the issues are. And then based on that, what should we go from? And I find, you know, if I had to sum up what we've learned, remote can be great, right? Office can be great. neither is a silver bullet. That's what I want. So I'm going to go back to my coaching stance and say, well, let's define the outcome, measure with a multi-focus, multi-factor, multi-dimensional metrics of what we're trying to actually accomplish with our people, experiment, and then keep an eye on the team health. I still feel like that's what we're doing. Five years sounds ridiculous that we haven't figured that out. But I think it was so disruptive that five years isn't enough. And I think the work on top of that is changing so radically. have too many variables up in the air. So for now, if I had to make a decision, I lean toward co-location. When the work is ambiguous, when relationships are important or new, that's another one. If we've got a lot of new people together, working remote is going to be a very difficult thing for a while. So, you know, I'd say, hey, if I'm starting a company and the work is ambiguous, you know, kind like a software product company, the work we're not quite sure what we're doing and needs a lot of collaboration and and a lot of hands on, you know, trust with each other, then I'm probably going to say, let's let's be in the same area sometime. You know, I'm not saying every single day, but. That's how I'm gonna lean towards. And then I'm gonna say if your work is predictable, repeatable, doesn't require a lot of that, and you need intense focus, well then maybe remote is fine for you. So how's that for an answer? I don't know. Brian Milner (04:32) No, think that's a look. I don't think there's ever I don't think you're ever worse off by by being able to admit that right to just say, you know what? I don't know. And I think sometimes that's part of the problem with the way that we approach certain issues is that people are reluctant to say that right. They're reluctant to just admit, you know what? I don't really know. I don't really have the answer on this yet. And I think you're hitting on something that's really important is that there is Lance Dacy (04:39) Right. Brian Milner (04:59) You said no silver bullet. I also think there's no one right answer. I don't think that there is a right answer to this question of should you be in the office or should you be remote? think, right. Lance Dacy (05:12) confidence interval, right? I mean, it's like, there's no, it's not it's not binary. So I agree with you. Brian Milner (05:16) Right. Yeah, there are certain industries, certain products, certain job types that I think are better in the office. And there are others that I think are better remote. And I think what you got to do, and I think I love your return to kind of a coaching stance and looking at this. What's the goal? And I think that's what you have to try to distill it down to is what's the purpose? What's the goal we're trying to reach here? If it's productivity, then let's talk about productivity. If it's morale, if it's enhancing communication, it starts from there. Define what it is that we want as our end goal, and then we can start to find data. We can start to find empirical evidence that either supports or detracts from whatever hypothesis we think we have about this. And that should be what leads us. Lance Dacy (06:10) And it could change, you know, that's the other problem. One quarter, it may be better the stuff we're working on. We're in the office more often. The next quarter, maybe we agree too much. Now, the problem is you go survey people. Let's talk about productivity. You ask, let's say a programmer. Okay, I'm just going to say garden variety programmer, highly skilled. You ask them where they are most productive and most of them, I'm not going to indict everybody, most of them will say, Brian Milner (06:22) Yep. Yes, let's do it. Lance Dacy (06:39) I want to be left alone, no meanings, in silence, coding on my keyboard. They may be going a direction completely opposite of where we need to go, and we won't know that until they come together. And so the other problem with this is we

What happens when your brain loves puzzles… but struggles with where to start? Paige Watson shares how ADHD shapes his work as a developer—and how practices like TDD, mob programming, and discovery trees help him stay focused, move forward, and actually enjoy the ride. Overview In this episode of the Agile Mentors Podcast, Brian Milner is joined by Paige Watson, a technical coach, seasoned XP practitioner, and self-proclaimed “code crafter.” Paige shares his firsthand experience navigating ADHD as a software developer, and how practices like Test-Driven Development (TDD), ensemble programming, and visual planning (like Discovery Trees) have helped him find sustainable focus and flow. Together, Brian and Paige unpack how small, iterative steps and collaborative team dynamics can support not just neurodivergent developers, but everyone on the team. Whether you're navigating ADHD yourself, leading a diverse team, or just want to write better, more maintainable code—this episode is packed with thoughtful insights and practical takeaways. References and resources mentioned in the show: Paige Watson Paige Watson’s ADHD Blog Posts #76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell #123: Unlocking Team Intelligence with Linda Rising Scrum Foundations Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Paige Watson is a passionate advocate for “Quality Software as Craft,” known for transforming developers into high-performing, cohesive teams. With deep experience guiding software teams and leading workshops for global companies, he helps build elegant, scalable systems designed for longevity and real-world impact. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. I'm with you always Brian Milner. And today I have Mr. Paige Watson with us. Welcome in Paige. Really excited to have Paige here. We kind of crossed paths with Paige because of some posts that he had done. Paige Watson (00:11) Thank you. Brian Milner (00:19) He is a technical coach and has been in the development community for a long time and is an XP practitioner, right? Did I hear you correctly say that? Paige Watson (00:27) Yes, I like to use the term code crafter, but yes, a lot of the things I do are XP centric. Yes. Brian Milner (00:31) Nice. I love that, Codecrafter. Then the post that kind of got our attention was a series of posts, actually, that Paige had done about really ADHD and software development. And as people who have listened to this show for a while know, we've done a couple episodes around neurodiversity and neurodiverse traits. and how that bleeds into our work in the software industry. There's plenty of stats showing that there's an unusually large percentage of people in this profession that have some form of neurodiversity. The topics were how he manages ADHD and works. The first one I thought was an interesting title, talked about it being a bug or a feature. So tell us a little bit about what kind of got you started in exploring this. Paige Watson (01:21) Yeah. So I go to a three-day open space that we have in the Northwest. I'm in the Seattle area. And one of the sessions that we had was something, I forget the exact title, but it was around neuro-spiciness in the workplace. And the whole idea was let's get a bunch of people who are neuro-spicy. for lack of a better term, and find out what works for you at work. What are things you need? How do you make sure that what you need is being said out loud? how do you make your work better? So this was a great discussion that we had. And I came out of it going, a lot of the things that I do, a lot of the practices and processes that I use, are actually really helpful for me in my ADHD. So then I sat down and thought, well, first I thought this would be a great conference talk. So I wrote that. And then I was like, I bet this would be a great series of blog posts as well. So I wrote those. Brian Milner (02:24) Ha ha. Yeah. Paige Watson (02:32) It turns out it is a pretty good conference talk, if I say so myself. I get a lot of really good feedback. And honestly, the discussion after I do the presentation is almost better a lot of the time, because you're right. There is a lot of people that, whether they've been diagnosed or they self-identify, whether it's ADHD or autism or anything, there's a lot of that that Brian Milner (02:37) Hahaha. Paige Watson (02:56) that I think we see existing in our software. you know, area that we don't, I don't want to say it's more, I don't have like a definitive study or anything like that that says it's more people in software, but it seems like it. And I sometimes wonder whether that's just me, you know, seeing people because I'm in the software industry or whether there's a draw towards it. Brian Milner (03:22) Yeah, there was a study that I, because I did a conference talk on neurodiversity and software development a while back too, and there was a study that I found out at the University of Texas that basically the only correlation I could find was saying that young people who were entering college and choosing majors were choosing actually it was people on the autism spectrum of some kind were choosing careers in computer science at a rate that was three times essentially that of the general public. So it's not all the neurodivergent traits, but it is one flavor of that. I just don't, maybe there's just not a study on the others, but I... I agree with you. think just from my experience, working in software and managing people in software and developing myself, the people I've kind of been around and worked around, now that I'm more aware of neurodiverse traits, it seems like, yeah, that seems very much like this is going on. That seems like that's going on. And it just starts to make sense a little bit more. Yeah. Paige Watson (04:24) Yeah, yeah. And I wonder, you know, I kind of look back and like, I like to play board games a lot. you know, I like, I have a model railroad and I like the aspect of not just watching the trains go around, although there's probably a maim in there somewhere, but I like sort of operating it like a model railroad. How do I get these cars over there to the green elevator in the fewest moves? There's a puzzle solving aspect. And one day I was like, I like to do that in my work too. You know, and is that part of the the neuro spiciness? I don't know. But you know, it's definitely a draw as to why I like development. Brian Milner (04:56) Yeah. Yeah. Well, I want to dive into some of the things that you uncover in your talk and in the blog post that you wrote. What were some of the discoveries that you realized as you were looking into this? Paige Watson (05:17) So, like, first off, let me preface by saying I'm not a doctor, you know, and if you have, if you think you're, you know, if you think you have ADHD or want to know more about it, please talk to your medical provider. That's really important. Brian Milner (05:21) Yeah. Yes. Paige Watson (05:34) And I can only really talk for my ADHD because ADHD comes in so many varieties. Yes, there are certain things that happen together, but there's so many sort comorbid aspects to it that I only really want to talk about mine and touch on some other things I've seen maybe, but just that caveat. What was really interesting is that I used to think that I ADHD was about not being able to focus. But it's about not being able to control the focus. Because sometimes I can't focus at all. There's lots of things going on. That whole, squirrel, that sort of thing. And then there are other times when I can hyper-focus. And this is where my talk comes. My talk I call Focus Flow on Co-Coffee. Brian Milner (06:13) Yeah. Paige Watson (06:21) And the whole idea is that I go and sit down at my desk with a cup of coffee, and I'm ready to go. And I start typing, and I go to take a sip, and the coffee's cold. And I forgot to go to lunch again. So it's not really about not having focus. It's about not being able to fully control where that focus goes. In terms of the way I Brian Milner (06:32) You Yeah. Paige Watson (06:47) the way I work, there's a lot of things that I found I can get really overwhelmed by big tasks. I can get overwhelmed if I'm not sure where to start. I'll do that thing where I'm like, I have my work. I know my story. I've got all the requirements. I sit down at the IDE, and I start to think about how am I going to write a test. I don't know where to start. I know what I need to do. It's not that. It's picking a place to start. And that's really a tough one for me. And then I can get overwhelmed by that. Or I can get overwhelmed by a large task and not fully understanding all of it. And when I do, I sort of freeze and shut down. And so there's a lot of learning around this that I've found about myself, which has been really nice. Also, having to talk about it to people has been sort of forced me to be a little more circumspect. But there are some really great practices that I found that work really well as well. For me, especially, mainly colla

AI might write your code, but can you trust it to do it well? Clare Sudbery says: not without a safety net. In this episode, she explains how test-driven development is evolving in the age of AI, and why developers need to slow down, not speed up. Overview In this episode, Brian sits down with Clare Sudbery, experienced developer, TDD advocate, and all-around brilliant explainer, to unpack the evolving relationship between test-driven development and AI-generated code. From skeptical beginnings to cautiously optimistic experimentation, Clare shares how testing isn’t just still relevant, it might be more essential than ever. They explore how TDD offers a safety net when using GenAI tools, the risks of blindly trusting AI output, and why treating AI like a helpful human is where many developers go wrong. Whether you’re an AI early adopter or still on the fence, this conversation will sharpen your thinking about quality, ethics, and the role of human judgment in modern software development. References and resources mentioned in the show: Clare Sudbery Clare’s upcoming Software Architecture Gathering 2025 workshop Clare at GOTO AI Practice Prompts For Scrum Masters #99: AI & Agile Learning with Hunter Hillegas #117: How AI and Automation Are Redefining Success for Developers with Lance Dacy Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Clare Sudbery is an independent technical coach, conference speaker, and published novelist who helps teams rediscover their “geek joy” through better software practices. She writes and speaks widely on test‑driven development, ethical AI, and women in tech, bringing clarity, humor, and decades of hands‑on experience to every talk and workshop. 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 always, Brian Milner. But today, I have Miss Claire Sudbury with me. Welcome in, Claire. Clare Sudbery (00:13) Hello. Brian Milner (00:14) I'm so happy to have you here. is here with us because we wanted to talk about a topic that I think is going to be interesting to lot of people, and that is test-driven development, but not just test-driven development in light of AI and kind of the changes that AI has made to test-driven development. So why don't we start with just the base level test-driven development for people who have only heard kind of buzzwords around it and aren't as familiar with it, how would you explain test-driven development in sort of plain English? Clare Sudbery (00:47) Okay, so the idea of test-driven development is that you want to be certain that your code works. And I'm sure most people will be familiar with the idea of writing tests around your code to prove that it works. But that principle is considered so important in test-driven development that we write the test before we write the code. And that's why we say that the development is driven by the tests. So the very starting point for any coding exercise is a test. Another really important part of this is that that test is tiny. So what we're not doing, and people might have heard of behavior-driven development, which is where you start with quite a big test where you say, I'm going to write a test that says that my thing should do this and the user should see a particular thing happen in a particular circumstance. In test driven development, the test is testing not what the user sees, but just what the code does in the tiniest, most granular way possible. So if you have a piece of your software that does some mathematical operations and you expect certain numbers to pop out the end, then you might say, just in this tiny bit of this calculation, this number should be multiplied by four. So you're not even necessarily saying that given these inputs, you should get these outputs. I mean, you may have tests that say that, but you're just testing that something gets multiplied by four. And that's just an example. But what you're doing is you're thinking, what is the tiniest possible thing that I can test? And you write a test that tests that tiny thing. And you do that before you've written the code. So obviously, the test fails initially, because you haven't even written the code yet. And that's another important part of the process. You want to see it fail because you want to know that when you then make it pass, the reason it's passing is because of something you did. And that means that every tiny little bit of code you write is proven because it makes a test pass. And when you get into the rhythm of it, it means you're constantly looking for green tests. And there are lots of other things I could talk about. Like for instance, you never want those tests to fail. So if at any point any of them start to fail, you know that that's because something you just did made them fail, which also means that you want to run them consistently every time you make any changes. So you're getting that fast feedback. You're finding out not only whether what you've just written works because it makes its test pass, but also that it's not making any other tests fail. So not only does it work within its own terms, but it hasn't broken anything else. And that's actually really common when you're coding is that some new thing that you add breaks some existing thing. So you're constantly paying attention to those tests and you're making sure that they pass. And it drives the development in a very interesting way because you're always talking about what should work. You always think about what should work. You always think about how it should work. You're moving in tiny, tiny steps. So you're gradually, gradually, gradually increasing the functionality and whether it works or not and how it works is being determined by the fact that you're making tests passed. And the really interesting thing is that it actually helps you to design software as well as to make sure that software works. So hopefully that explained it. Brian Milner (04:10) That's an awesome explanation. really appreciate that. That was a great kind of practical, plain English explanation of it. I love it. So for the people who weren't familiar, now you have kind of a good idea of what we mean by test-driven development. I know with the advent of AI, there's been lots of changes that have taken place, lots of changes in the way that developers create their code. We now have these sort of co-pilots, assistants that help in doing our coding. But on the other hand, one of the things you hear quite often is that there's lots and lots of quality issues, that it takes a lot of effort to try to maintain that quality and make sure that it's still at a high level. So how does AI enter the picture of test-driven development? How is that helping? How is it changing the way that we do test-driven development? Clare Sudbery (04:59) It's a very good question and there are lots of different strands to how I can answer it. And I think it's probably important that I start by saying, I came to this from a position of deep skepticism. So I have been sitting on the sidelines for a long time, watching the AI explosion happen and not actually getting very involved. But what I did find was that It was becoming like a tennis match. I was like just going, okay. And they say that and they say that. And it actually became very interesting to me just how polarizing it could be. You know, that there were people within my networks, people who had a lot of respect for, who were very anti or who are very anti and who also are very pro. People who've been experimenting with it and having a lot of fun with it. But one of the big issues that I didn't even have to be told I could guess would occur and has occurred is exactly what you said that the code that is generated by GenAI coding tools is often not reliable. And it's not reliable for the same reason that when you ask ChatGPT a question, the answer you get is often not reliable. And that's because these things are not deterministic. They the way that they're constructed. mean, people might remember a long time ago, people used to talk about fuzzy logic. It's all a bit wibbly wobbly. It's not you can't you'll get this a different answer if you ask the same question. And the way that it's constructing those answers is not in the way that we're used to as software engineers. It's not a strict series of logic. It's not all nuts and ones. And hallucination is a real problem. And so it and then you also have to think about the fact so part of the problem is that AI is synthesizing new answers to questions that it's not answering on in a logical deterministic way. But also the place that it's getting his answers from is the results of years and years and billions of files and lines of human output, but with no way of discerning. which bits of that output are good and which bits are bad. And also whether this particular bit that it happens to have plucked from some random code base somewhere is really right for this context. So you're gonna get, when you ask GEN.AI to write code for you, you are gonna get weird results that don't necessarily do what you want t

What separates a solid Scrum Master from a great one? In this episode, Brian Milner sits down with veteran Scrum Master Brian Campbell to talk about the balance between being empathetic, staying grounded, and knowing when it’s time to move on. Overview In this episode of the Agile Mentors Podcast, Brian Milner is joined by longtime Agile Mentors Community member and enterprise-level Scrum Master Brian Campbell to explore the core skills every Scrum Master needs, beyond the textbook answers. Drawing from 13+ years of experience, Brian Campbell shares how flexibility, empathy, and situational awareness help Scrum Masters navigate real-world team dynamics, conflicting priorities, and tough leadership environments. Together, the Brians discuss how to support product owners without overstepping, when to gently push back with leadership, and how to foster effective teamwork even under pressure. They also dive into what it means to advocate for your team—especially during crunch time—and how to know when it’s time to walk away from an unhealthy engagement. Whether you’re just starting out or deep into your Scrum career, this episode is packed with practical insight from someone who's been there. References and resources mentioned in the show: Brian Campbell Rescue Your Daily Scrum videos #113: Influence Without Authority with Christopher DiBella #126: Mastering the Scrum Master Role with Gary K. Evans The Daily Scrum Meeting - a detailed breakdown Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Brian Campbell is a seasoned Senior Scrum Master with over 13 years of experience helping enterprise teams in healthcare, insurance, and tech deliver real results with agile. He’s known for his calm leadership, strong facilitation skills, and a flexible, coaching-first approach that meets teams where they are. Auto-generated Transcript: Brian Milner (00:00) Welcome back Agile Mentors. We are here for the Agile Mentors podcast. I'm here, Brian Milner, and I also have with me another Brian. I have Mr. Brian Campbell with me. Welcome in, Brian. Brian Campbell (00:12) Hi. Nice to be on the podcast. Brian Milner (00:13) ⁓ I was, yeah, we're really happy to have you here. I always kind of joke with, with other Brian's and, and, Brian is one of the other ones I can joke with here about this and say, thank you very much for spelling your name correctly. Brian is, is, someone who's a member of our agile mentors community and he's, he's shared a lot of really great, advice and he's mentored people through there. Brian Campbell (00:27) I do know people too. Brian Milner (00:39) So we wanted to highlight that, but he's an enterprise level scrum master. He's been doing this for a while. He's got over 13 years experience as a scrum master and has had some really insightful comments in our and post in the Agile Mentors discussion forums. We're going to link to one in particular that's really interesting that hopefully everyone here will find interesting in the show notes. But we talked about what we would. kind of dive into here and seeing as Brian has all this experience as a scrum master, we wanted to focus on some scrum master issues. in particular, one particular quality that Brian brought up that he felt was really, really essential, and I agree with him, for a successful scrum master, and that's flexibility. So maybe we start there and just define that for everyone. When you talk about how important it is for a scrum master to be flexible, What does that mean to you, Brian? Brian Campbell (01:33) Well, there's three things. You've got to work with a product owner at their level. So you may have a brand new product owner who doesn't understand how to construct a story with acceptance criteria or a bug with steps to reproduce. Other times you have a product owner who's really, really on their game and very established. And then you're going to be more hands off and just providing a little bit of guardrails according to the way the company works. You're going to be flexible with the daily standup. I've had teams rebel against the idea that standup has to be run cookie cutter scrum. So you may find that they prefer to go person by person. And that's fine. You may find they prefer to go issue by issue. You may find that you do it a whole section at a time. Dev, QA. going down a column on a board just to try and work with the team the way they want to be worked with. But my goal as a Scrum Master is to make it efficient and effective. I'm not trying to keep them sitting on a call for the sake of being a Scrum Master. But get familiar with how each company does things. Don't try to radically improve things. Suggest incremental improvements where merited. So don't come in guns a-blazing trying to change everything in the environment. Come in, observe for a while, make a little course correction here and there. Suggest things if they're above your station that might allow you to allow the teams to work more effectively. So those are three ideas. Brian Milner (03:02) Yeah, that's awesome. I agree with you on those. think those are really important. There's kind of this, starting with the last thing that you brought up there. There's kind of an idea that I've heard people say before. I've always subscribed to this as well. Kind of the evolution versus revolution kind of approach to doing things that you're going to be served better by trying to incrementally in small little doses change things rather than big bang. let's all of a sudden, Monday morning, everyone's going to be doing Scrum. It doesn't really work very well if you try to drastically change things. I know that's one thing with Kanban I've always appreciated is Kanban talks about start with where you are. And I think that's a good approach for us as Scrum Masters as well, is kind of start with where the team is, Brian Campbell (03:31) Yeah. Well, I've also done Kanban implementations and where people are doing scrim and they want to do Kanban and developers think there isn't a lot of, you know, I'm just going to be wild, wild west and do what I want. But Kanban has its own structure and way of doing things that you need to get the team, its own set of ceremonies, et cetera, that you need to get the team familiar with. Brian Milner (04:06) Yeah. Yeah. And you mentioned earlier as well, like trying to be flexible as you work with your product owners. I agree there as well. Product owners, you know, come in all shapes and sizes as far and all kind of levels of experience. maybe you'll get lucky and you'll have one that's really experienced and doesn't really need a lot of help. But maybe you'll get one that's brand new, that's never done this before. In which case you have to have a lot of patience and a lot of time to coach and help them get up to speed with what's really going to be valuable. Brian Campbell (04:38) Yeah, they need different kinds of support. I think the new scrum master may, new scrum master, new product owner may require, let's read, let's start that one over again. I think they will require different levels of support. The. Brian Milner (04:48) Yeah. ⁓ Brian Campbell (04:51) the new product owner needs to have have stronger agile guard rails in place. The biggest problem I have sometimes is there's a product owner that's very set in their waste. I had one product owner who decided that he was going to map out all the work for this quarter and tell a sign by developer and even story point the items. And I had to go to management and say, Hey, this guy's bad. We'll get into that later. You have a time to move on thing. This was one of my times to move on because management was not supportive and changing his viewpoint. ⁓ Brian Milner (05:30) Yeah. Yeah, I mean, that's part of just being agile that you expect the kind of same attitude towards being flexible from the product owner that, hey, you know, I'm going to grow and learn. And maybe that starts with kind of a humility of just saying, I may not be right. Brian Campbell (05:49) Yeah. I like to form a trika between, well, actually four people. I like to get the product owner, the dev lead and the BA all coordinating at the same time. So the product owner is not writing these stories blind. They're getting feedback from the dev lead and the BA. is learning how to support the product owner. It's kind of like that whole idea with Three Amigos where you get the product owner, developer and QA together and you just try and get them to work on an individual story. This is more like at the team level. Brian Milner (06:24) Yeah, if you do that, just have to make sure you don't kill the invisible swordsman, right? ⁓ Little three amigos reference for the listeners. Yeah, I agree. And I'm kind of curious there because you mentioned business analysts, mentioned dev leads, and that's always a hot button issue as well as we think about working with our teams because there's not really strong guidance from Scrum on Brian Campbell (06:29) That's it. Brian Milner (06:50) those roles and how they might interact or play with the Scrum team, what have you seen work well with those kind of roles? Brian Campbell

“Too many meetings” is one of the most common complaints in Scrum teams, but is it really the meetings, or what’s (not) happening in them? In this episode, Brian and Lance Dacy dig into the events of Scrum to uncover what works, what doesn’t, and how to make each one actually add value. Overview In this episode of the Agile Mentors Podcast, Brian Milner welcomes Certified Scrum Trainer and Mountain Goat colleague Lance Dacy for a breakdown of the four main Scrum events, and why so many teams struggle with them. They tackle one of the most persistent frustrations teams face: the sense that Scrum has “too many meetings.” Together, they explore how to reframe these as working sessions, clarify their purpose, and avoid the common traps that drain time without moving the work forward. From sprint planning that skips the plan to daily scrums that lose their rhythm, this episode is full of specific guidance for getting more value out of each event. Plus, hear why retrospectives and backlog refinement are two of the most underrated (and powerful) drivers of team improvement. Whether you're new to Scrum or looking to reset a struggling team, this conversation will help you re-center on what the framework is really designed to do, and how to help your team do it well. References and resources mentioned in the show: Lance Dacy #138: The Bad Meeting Hangover with Julie Chickering #156: Making Product Ownership Work in Shared Services with Kert Peterson Does Scrum Have Too Many Meetings? By Mike Cohn What Happens When During a Sprint By Mike Cohn Scrum Activities: An Overview Working on a Scrum Team Course Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away. Auto-generated Transcript: Brian Milner (00:00) Welcome back Agile Mentors. We're here for another episode of the Agile Mentors podcast. I'm here as always, Brian Milner, and I have with us friend of the show, once again, Lance Dacy with us. Welcome back, Lance. Lance Dacy (00:12) Thank you, Brian. Glad to be here. Brian Milner (00:14) Always happy to have Lance on. we thought we'd have Lance on. We were kind of doing this thing at Mountain Goat. We're getting ready for the launch of a new course here that's called Working on a Scrum Team. And Lance and I are going to be two of the people that teach that course. And it's going to deal with a lot of like basic stuff that the teams deal with, common problems, common issues, and really how to work together well on a Scrum Team. And one of the things that we always hear questions about is about the meetings themselves. There's kind of three core components there for the Scrum framework. There's the roles, the events, and the artifacts. And so the events, the meetings are one of the biggest kind of focal points. And there's lots of questions about it. So I guess let's kick it off that way, Lance, and just say, what do you most hear? people complain about when they talk about scrum meetings. Lance Dacy (01:06) Well, that's the big thing, right? It's like we call them meetings. And the first thing I like to do is try to explain to them that there really aren't meetings, right? So when you hear the idea that you're going to go to a meeting, that's not very exciting, right? You're like, I'm to sit there and not get a lot out of this. So what I would like to say about the, working on a scrum team, I'm going to say it's probably the first course I ever taught as a scrum trainer. And we've been actually teaching it for a very long time. It's mainly just a private. you know, that we go into organizations and help them learn this. So I'm super excited that we're making this available publicly because so often people say, well, I'm a, you know, I'm not a product owner and I'm not a Scrum Master and I want to learn more about Scrum and I don't want to kind of bend to one role. So I am just shouting for joy that we have this one now. And I really hope that a lot of people will benefit if you're a stakeholder or if you're a manager or leader or things like that. A lot of times you have to pick and choose, you know, which class you're going to go to. So Brian Milner (01:49) you Lance Dacy (02:00) "That's one thing, but it helps us address this idea. We kind of talk about it in Scrum Masterclass where people are like, well, we're practicing Scrum now, and now I feel like I got to go to all these meetings. Okay, well, first of all, they're not meetings. Let's get that out of the way. Let's quit calling them meetings. You called them events. I think that's an appropriate term, but I like to call them working sessions. No matter what process we use, you are going to have to get together with your team and collaborate on how we're going to approach building this thing. You have to collaborate on Brian Milner (02:11) Mmm. Hmm. Lance Dacy (02:29) understanding the needs of the users. Like that doesn't go away. Regardless of the process you use, Scrum just tries to focus us and allow us to get together in specific checkpoints throughout the process. And so if you boil it down, the Scrum framework itself has the four events of sprint planning, daily Scrum, review, retrospective. And then we have this activity, product backlog refinement, which if I had to choose... One of the top two problems with Scrum teams is we don't spend enough time doing product backlog refinement. So a lot of teams even misunderstand what that is. Is that a meaning? Well, not always. It's an activity as well. So I think probably some of the biggest complaints we hear about Scrum as we go to all these meetings. And so I typically like to advise people, you know, if you're going to implement Scrum, get rid of all the other meetings first. Okay. So you're going to do Scrum and Brian Milner (03:16) You Lance Dacy (03:19) We're gonna do sprint planning at the beginning of a sprint. Every day we're gonna check in on how we're doing against the work that we've collectively decided we could do. We're gonna show our stakeholders at the end and then we're gonna meet at the end and try to figure out how we can get better. There's nothing inherently wrong with that if you don't call it a meeting. Like plan the work we're gonna do for the next, let's say two weeks. Every day check in on it. Show our stakeholders at the end, is this what you wanted? And then what's wrong with getting together and saying how could we do better next sprint? Okay, so get rid of all the other meetings and try to build it into that cadence, if you will. Now, the other side to that is you're going to also have to get together and do backlog refinement, which is estimating, breaking large items down into smaller items. You're going to have to do some level of design on these items. And then, of course, adding clarity and detail to the work items is another big aspect of that. So those aren't meetings. Those are working sessions. So. When I hear most people complain about the scrum meetings, get rid of everything else, only do these. You're going to have to spend that time anywhere, anytime, know, whatever process you use. And if you want to get into the numbers, you know, I hear managers all the time or project managers going, I've got 12 people on a team and they're going to spend, you know, let's say a two week sprint maximum time box for sprint planning is four hours. And that's multiplied by 12 people. That's a terrible amount of time. It's like, yeah, but if you start doing all the math, And you spent the maximum amount of time, which we always would want to lead and coach and train them to spend half of that eventually. But you may have to spend all that time at the beginning, but you don't spend more than that. So, sprint planning kind of just boils down to about 5 % of a 40 hour work week for two weeks, daily scrums, about 3 % sprint reviews, about two and a half percent retrospective 2%. And so that's a total of about 12 % of your collective time going to these scrum events. Now. I would pay that any day if it's going to save us some mismatch, you know, further down the road. So that's really what I like to boil it down to is these are not meetings, first of all, they're working sessions, and it's not as much as you really think it is. So what do you think? Brian Milner (05:17) Yeah. Yeah. No, I agree. mean, I hear people say that all the time that there's, why are there so many meetings? And I mean, I think when people say that it's usually one of two kind of core reasons why. One is maybe they're doing it for like four or five teams. And if that's case, yeah, that's a lot of meetings because you're not meant to be on four or five teams. You know, that's kind of the your problem isn't the meetings, right? Your problem is something else. But the other thing I think is, I think it really can feel like there are more meetings than there are when the meetings don't really accomplis

Is your team dreading retrospectives, or skipping them altogether? Mike Cohn joins Brian Milner to unpack what’s really going wrong (and how to fix it) so retros don’t just take up time… they actually make your team better. Overview In this candid conversation, Brian Milner welcomes back Mountain Goat Software co-founder Mike Cohn to talk about one of the most misunderstood parts of Scrum: the sprint retrospective. Too many teams treat retros as boring, repetitive, or even pointless—and end up skipping them entirely. But retros are where the magic of continuous improvement actually happens… when they’re done right. Brian and Mike dig into the common reasons teams dread retros, how to spot the signs a retro isn’t working, and the practical ways to bring them back to life. They also share their own lessons learned (including how Mike once argued retros shouldn’t be part of Scrum!) and walk through the real reason retros matter: giving teams space to inspect, adapt, and improve together. References and resources mentioned in the show: Mike Cohn Your Fast Tract to a Fresher Retrospective Webinar #141: Cooking Up a Killer Retrospective with Brian Milner Overcoming Four Common Problems with Retrospectives by Mike Cohn Retrospectives Broken? Fix Them for Good by Mike Cohn Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian Milner (00:00) Hey everyone, welcome back to the Agile Mentors Podcast. I'm here with you always, Brian Milner. But before we dive in today, I wanted to let you know that we're gonna have a free webinar that I'm gonna be running here for you. It's gonna be on September 24th at 9 a.m. Pacific. So do your adjustments wherever you are. It's called Your Fast Track to a Fresher Retrospective. It's just gonna be a little short 20 to 25 minute presentation. And then there's gonna be some open question and answer that we're gonna have after that. it's perfect if your team's retros are feeling a little stale, or if you're looking for practical ways to shake things up. We're gonna put a link to it our show notes, but wanted to make sure right up top that you guys knew about that. It's completely free, September 24th, 9 a.m. Pacific. We're gonna have that webinar on retrospectives. And joining me here today, also is the one and only Mike Cohn. Welcome in, Mike. Mike (00:55) Hey, Brian's good to be back. Brian Milner (00:57) Glad you're here. We wanted to have a conversation because I think we can probably all agree that not all retrospectives, we might even say are worth having. When you look back on them and you look back on the content of it, maybe we'd say it wasn't worth having. If your team isn't getting value from the meeting and skipping it might feel rational. But skipping the point of retrospective, continuous improvement, isn't something high performing teams really can afford. It's a main part of what we do. So we're going to talk a little bit more. We're going explore that about why some teams end up dropping retros. Because I hear that all the time. People ask that in classes. Is it OK to? Should we? Should we do it less often? So we're going to talk about why some teams might drop retros. What that really says about the team health itself. and how you can bring retros back in a way that reconnects to their purpose so that it's not just a ritual. And with that then, I'm going to pull Mike back in. So again, Mike, thanks for being here. I really appreciate you giving us your time for the episode today. Mike (02:05) Yeah, I appreciate it. I'm glad to be here. Before you jump in, I do want to point out that we've been on for about 15 minutes before we got ready to record. Just kind of haven't talked to each other for a bit. And I just want to point out for everybody listening that Brian did a mini retro on his podcast before we got started, talked about how we can change some editing on that, maybe get episodes out more quickly and also to get them out in video. So I guess I'm saying that to. make us commit to the video part of it, but to also point out that Brian did a retro on his podcast, right before we got started. So Brian is walking the walk. Brian Milner (02:40) Yeah, mean, it's always good to inspect and adapt, right? I mean, if you don't do that, then you're not questioning why things are happening the way they are and things get stale and eventually fall off. So yeah, I'm a big proponent in that, stopping down to inspect and adapt for sure. Mike (02:56) Brian, one of the things that does come up with retros is teams feel like skipping them when they're not getting anything out of it. Do you think it's okay to skip a retrospective? Brian Milner (03:08) Well, I'm probably not going to shock anyone here in my answer, but I'm not going to be someone who would support that. I'm not a proponent of that. I think that's a mistake. I try to be very careful about saying, hey, this is always this way. I do think that that's the Agile Manifesto talks about periodically, routinely. kind of having this kind of inspecting and adapting moments where we retrospect on how things went. And Scrum has this meeting built into it to happen every single sprint. The thing that kind of jumps out at me when I first thought about this is we kind of take this attitude sometimes that, this thing isn't working great. And so maybe we should skip it. Or least that's, I guess, the mentality behind skipping the retrospective. Mike (03:55) When you say skip it, I think about the guy skipping leg day, right? Brian Milner (03:59) Right, right. Well, that's exactly where I was going to go. It's like, where else in life do we say, that's not working, so I just won't do it. You know, like, I'm having a hard time getting my passport renewed, so I guess I just won't get my passport. You know, like we don't do that with other things. There are things that are hard. There are things that take more effort. And it doesn't mean that if it's harder or it's not working right now that we just don't do it. We got to figure out why and... you know, fix it and, you know, get better at it. Mike (04:27) Yeah, there's a I'm a big fan of the Lego Batman movie. And in there, there's a song where this says Batman never skips leg day. Right. And, you know, skip something if it's truly useless, but don't skip something because it's hard. Right. I would agree that. Brian, I'm curious what you think about this situation. What suppose you have a team doing one week, one week sprints and one week is. Brian Milner (04:31) Ha ha. Right. Mike (04:51) Awesome. It's the right length for the team. It's a right length for the business. Everybody agrees. It rocks. One week sprints rock. But the team hates retrospectives. Like literally, they'd rather go to the dentist and have a root canal instead of having a retro. And at some point, somebody on the team goes, huh, if we switched to four week sprints, we wouldn't have to do these darn retros as often. That's a tough one. What do you think about that? Brian Milner (05:18) Well, there's some truth in that. You know, they're not wrong, as they say. You know, if you do longer sprints, then you have meetings less often and included in that is a retrospective. So yeah, that's not wrong. You would do it less often. But on the other hand, your retro is gonna be a lot longer. If you're retrospecting over the past month versus over the past week, Mike (05:28) Mm-hmm. Brian Milner (05:42) A weekly retrospective is going to be very short. A monthly retrospective is going to be very long and no one likes longer meetings. So that's the trade-off is, yeah, we can do it less often, but do you really want to have those meetings double and triple and link? Mike (05:46) Okay. in double and triple perhaps, but I I gave it the example where it'd be one fourth as often. So it'd have to be four times as long. And I doubt that it would truly be four times as long. See, this is a case where we probably disagree on this a little bit, because I have had teams that have made that argument. Hey, if we went to longer sprints, we wouldn't have to do this as often. And I don't want them to go to longer sprints. I doubt you do either. But what I've told them is like, look, the rule is do a retrospective often at least once a month. Brian Milner (06:20) Yeah. Mike (06:27) If you're going to do it every four weeks and you want to do two weeks sprints, for example, do your two weeks sprints. But I'd rather have you do the retro every other sprint, but take it seriously. Because what they do is they just go through the motions. They're going to go through the motions for 10 minutes. They're going to go through the motions in 10 minutes in a four week sprint too. Just show up. Can we get better or anything? No, we're good. Done. B

Scrum isn’t new, but the questions teams are asking about it are evolving. In this episode, Brian and Cort Sharp compare notes on what they're hearing in class, in the community, and behind the scenes. Overview In this episode of the Agile Mentors Podcast, Brian Milner welcomes Mountain Goat Software colleague and community manager Cort Sharp for a real-time pulse check on what’s top-of-mind for Scrum teams today. From overloaded calendars to misunderstood metrics, Cort and Brian dig into the patterns and questions they’ve seen across classes and conversations lately. They unpack common friction points like meeting overload, velocity confusion, misused roles, and daily scrums that eat the whole morning, and offer grounded suggestions for handling each one. Whether you're a Scrum Master trying to protect team time or a developer wondering how to work more collaboratively, this episode offers helpful context (and practical nudges) to help your team work better, together. References and resources mentioned in the show: Cort Sharp #143: What Still Makes Teams Work (and Win) with Jim York #152: The Five Pillars of Real Agile Improvement with Mike Cohn 7 Advantages of Scrum (Plus 1 Hidden Disadvantage) by Mike Cohn What Is a High-Performing Agile Team? by Mike Cohn Mountain Goat Software’s Working on a Scrum Team Course Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm here as always, Brian Milner. And today we have Mr. Court Sharp with us. Welcome in Court. Cort Sharp (00:10) Hey Brian, thanks for having me on again. Brian Milner (00:13) Yeah, Court has been a frequent guest of our show. If you've been around for a while, you probably remember some episodes we've done with him. Court works with us here at Mountain Goat Software. He is a producer and other things, community manager, other things. But he sits in on just about, well, not every class, but he sits in on a lot of classes and helps produce them and make sure that they work. We previously have had Court on with sort of this theme that, you know, Court has his finger on the pulse of things a little bit more because he sees the classes through multiple trainers. He hears the Q &As that take place in all the classes. You know, he even sees some of the emails and some of messages come through the Agile Mentors community from his work there. So Court just has some insight that maybe... a trainer like myself who only gets to see how people question in my classes that I might not have. So we like to have Kordon to get a broader voice of the people approach, if you will, into things. So we wanted to talk a little bit about what are people talking about now? What are the questions? What are the concerns? Cort Sharp (01:18) You Brian Milner (01:29) What are we hearing now in classes as opposed to maybe a year ago or six months ago? So I think probably a good place to start there, Court, is when people are talking to us about just the common, hey, here's things that's a problem, here's things that are a pain point, how do you deal with this? What are some of the more common things that you've been hearing across the classes and across the interactions with people who are in our our system. Cort Sharp (01:53) Right, right. Yeah, I guess I am kind of the collector of questions. ⁓ But even outside of our classes, I'm hearing a lot of questions about, I'm hearing a ton in our classes about this, but outside of our classes, whether it's on various social medias, various emails, of just questions in general to people who are newer to Scrum or I guess Agile as a whole, but specifically about Scrum. Brian Milner (01:58) Ha ha ha ha. Cort Sharp (02:18) organizations that are newer to Scrum is time management. So like how do we fit all of this new stuff? Like all this new stuff is great. All of what we talked about is great. All that we know about it is great. We were on the same page of like, hey, here's, it's a good time to check in daily with our daily Scrum, make sure we're all on the same page, right? We do need stakeholder feedback with the sprint review. It's good of us to kind of retrospect. and use our retrospective to check in on our team and our process and make sure we're doing the right stuff. But how do we fit all of that in with all of the other meetings and stuff that we already have? And you and I were talking a little bit about just kind of what we're going to talk about a bit more. But we were talking about this before we started recording. And I think I told you literally three or four days ago, I just had a conversation with one of my friends who they're working in a tech software, they're doing a software project in some organization and they're like, yeah, they're trying to get us to move to Scrum because they've heard about this thing. And I just, I don't know how you push this man. I don't know how you do this. I don't know how you live in this world because they got me in six hours of meetings a day and they expect me to get four hours of work done. And I'm not sitting at the office for 10 to 12 hours a day. That's ridiculous. So I think the biggest one is the the time management specifically with all of these meetings. And I know my personal take is I think all of these or a lot of these organizations, I can't say all a lot of these organizations are looking at Scrum as an additive to their current process, not a substitute or replacement. you do you see that, Brian? Do you agree with that? Brian Milner (03:53) Yeah. Yeah, I agree. mean, if they already have a huge slate of meetings that they're, I mean, there's going to be some things that Scrum isn't going to replace and shouldn't replace, for example, like, you know, one-on-ones with your manager, right? There's not a function inside Scrum for a one-on-one meeting with your manager, nor should there be, because that's not about how a team builds something. That's more general management and HR, you know? so those kinds of things, no, it's not going to replace and there are going to be other meetings outside of scrum. It's not intended for scrum to replace all of them, but it is intended to replace some of what you already did. and if you, so for me, it's all about purpose. You know, that's, that's where I think that you should start with everything is what's the purpose. And if you understand the purpose, Cort Sharp (04:46) Mm-hmm. Brian Milner (04:54) then you can compare, ask yourself what the meetings that you have now, what's the purpose of this meeting? And if you can't answer that, then I would challenge it. I think that an agile organization should be open to challenges for any part of the process. And you should be able to say, hey, I'm not sure why we're doing this. And if we can't really articulate, here's the purpose behind it, it should be gone. Cort Sharp (05:10) Mm-hmm. Brian Milner (05:19) We should get rid of it. So I think you're right. I think there is sort of this layering on top of, and if we don't allow the scrum meetings to replace some of the things that we've done previously, yeah, can be, it can seem like a lot more of a meeting heavy kind of system, but the meetings in the system, let's be clear, right? First of all, depends on how long your sprint is, but let's just go with the sprint that's the sprint length that's the average or most common, which is two weeks. If I have a two week sprint, first day of the sprint, I'm gonna have sprint planning. That is going to be a long meeting. There's no two ways around it. The official time box is up to eight hours if you have a month long sprint. Most people would half that if it's a two week sprint. Cort Sharp (05:45) Yes. Brian Milner (06:07) So maximum maybe of around four hours. So half a day, let's just say, right? Half a day of your first day is gonna be in planning your sprint. Then maybe you finish that meeting up with a small sort of mini daily scrum, but that's it for that day. So you have half the day on day one. Day two, day three, day four, almost all the days of the sprint that are remaining, you have 15 minute meeting. That's it. If you, if you layer on maybe a backlog refinement, maybe you have another hour long meeting in the middle somewhere, but there's no other scrum meetings every day. It's a 15 minute meeting until you get to the last day. So first day, last day, right? First day, four hour meeting last day, you're going to have the sprint review and the retrospective. So there's going to be some time probably in the first part of your day that you have a sprint review. It's going to be some time in the the back part of your day for a retrospective. But those two combined, they're not gonna, maximum I would say there, if you combine those two, would be the same as the sprint planning, maybe up to about four hours or so, maximum. So maybe half a day.

Shared services teams often wonder: Does product ownership still apply here—or are we the exception to the rule? In this episode, Brian and Kert Peterson explore how Scrum principles hold up when value isn’t always customer-facing and demand never stops. Overview In this episode of the Agile Mentors Podcast, Brian welcomes back longtime friend and mentor Kert Peterson for a deep dive into what product ownership looks like in a shared services environment. They explore the practical realities that differentiate shared services from traditional product teams, from endless stakeholder requests to the challenge of defining “value” when your users are internal. Together, they discuss the importance of proactive leadership, strategic alignment, and understanding who your real customers are. Kert also shares tools for improving intake, applying an experimentation mindset, and closing the feedback loop, even when your work is abstracted from the business’s end goals. Whether you’re a product owner in infrastructure, data, middleware, or internal tools, this episode will help you reconnect your team’s work to the outcomes that matter. References and resources mentioned in the show: Kert Peterson #9: Scrum Artifacts with Kert Peterson #12: Kanban with Kert Peterson What Happens When For Product Owners Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Kert Peterson is an experienced Agile coach and trainer who bridges the gap between business strategy and technical execution. With a background spanning engineering, marketing, and management, he’s helped teams at Amazon, NASA, and Capital One launch Agile practices that actually deliver. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you here as always, Brian Milner. And today I have one of my dear friends with me, Mr. Kert Peterson is back. Welcome back, Kert. Kert (00:13) Thank you, Brian. It's great to be back with you. Brian Milner (00:16) Love having Kert on. Kert is one of my mentors and actually first person I ever came in contact with when I was trying to become a CST. He kind of showed me the ropes and took a lot of time helping me to understand how to do this thing. So I have a huge debt of gratitude to Kert that I can never repay. But wanted to have... Kert (00:33) It's funny, Brian, let me just say I have the same debt of gratitude to Mike Cohn. So it's funny, it's coming full circle. Brian Milner (00:37) That's awesome. That's awesome. So, but we wanted to have Kert on because we want to talk about something that we I know I've heard a lot of questions about in class and it's a big topic of conversation. And that is, you know, when we talk about working in the area of shared services, you know, how does product ownership fit and work into that area? Does it fit and work into that area? Or do we find the exception? Is this the place where product ownership just all of a sudden is not able to provide any value? So Kert, that's a huge big ball of yarn to unravel there, but what comes to mind when you think about this? Kert (01:18) Well, I think back to the origins, what inspired the Scrum framework, which was Japanese product companies in the late 1970s doing things differently, using this sort of rugby approach and getting cross-discipline groups together and seeking to innovate and reduce time to market. So when I think about product ownership arising out of that context, it's very clear, right? There's a printer that I want to get better at. I want to take a Canon EOS Rebel and I want to make the next generation of it, or I want to take the Honda Civic. And I want to improve the way it shifts or whatever. And so there's a lot of clarity. And I think, I would say an easy vision to sort of begin to form and coalesce around the direction we're moving in. And the shared services groups I've worked with, whether it's middleware or data people or cybersecurity folks, they just experienced this constant deluge of requests from a variety of stakeholders, dozens, if not hundreds of stakeholders. And it feels like they're always operating tactically. helping those product owners that they're leading shared services teams to shift out of the tactical and begin to think more strategically and begin to get more, I guess, proactive about how they meet requests and what they're going to offer and how they're going to offer it is sort of a challenge that I think I see many of my customers and clients up against. Brian Milner (02:37) Yeah. I think one of the things I hear quite often about this is it's sort of, you know, cause and for example, a product owner class or something like that. We'll talk a lot about understanding your customers and, and mapping out kind of personas and other things and how that influences our idea of value. And then how you, kind of rank value according to your backlog. And that, that to me is kind of where one of the friction points here in shared services is you've got these demands coming at you. all day, every day from all these different corners and from everyone, it's urgent. From everyone, this is the most important thing. So how can you apply some of this product ownership mindset principle to scenarios where everything is urgent? Kert (03:21) Yeah, you those fundamentals, you know, when something's coming in, how do we weigh it against other opportunities? And usually we want to do so financially. How do we kind of begin to assess this particular request or opportunity against others? And when I teach product owner training in person, I hand out these little plastic covered pictures of currency. So I'll have like a yuan from China. I'll have a euro, I'll have all these varieties of currency and I won't, I make them kind of cryptic. Like I'll choose one from, you know, maybe one from Mongolia. And so I put this currency in front of them. say, okay, rank these in order of value, you know, translate it to U S dollars, which one's most to least important. And they struggle because I don't let them look at their phones and they have to, you know, sort of think or be creative. And at the end of the activity, they realized, wow, I don't have a system for translating this currency into the currency that's universal, which is US dollars. And it gets them, it sort of sets the stage for this idea of scoring, you whether you're using rice or some other scoring method, it sets the stage for that conversation, which is critical. How do you objectively assess what's coming in and make the choice on the next best thing to build? Yeah. Brian Milner (04:36) Yeah, that's a great exercise. I love that because it's a great picture there to understand as a product owner, you can't make those decisions in a vacuum. If you don't have the background, if you don't have the knowledge, if you don't have source information coming in, then no, I can't rank currencies. I've got to have expertise in those areas to help me understand those things. So yeah, I love that exercise. That's awesome. One of the other things I hear quite often in the shared services space is kind of the idea of, maybe this stuff is, maybe Scrum doesn't work as well in a shared services space because of the immediacy of all this stuff. And maybe we have to do Kanban versus Scrum. What's your opinion there? Kert (05:18) When I was at Capital One many years ago, shared services teams were adopting Scrum because that was the only game in town. This was 2005. really Agile was sort of very closely connected to Scrum because the Scrum and XP communities sort of were the members of the Agile Manifesto. And what Scrum teams end up doing is they say, you know, we're going to have a sprint planning session and we're going to plan 10 % of our capacity for something that is doable. And we're going to reserve 90 % for unplanned work. that's coming at us. And I see Scrum teams that retain Scrum and that want to leverage Scrum for shared services really just allow for a huge buffer of flexibility. But they also start to get curious about, you know, over the last two weeks, we left 90 % of our capacity open. We used all of it. And here's the top three, you could say offenders, right? Top three requesters, top three sources of demand. And they really begin to get good at tracking where their money's being spent as a team. So they can go back to those stakeholders and say, look, if you want us to continue to serve you, give us some more funding. So I think Scrum teams can excel in shared service. You're applying Scrum in shared services. I just think there's some nuance to it. That's been my experience. I'm curious what you see too. Brian Milner (06:34) Yeah, no, I think that's a great point. I think that 90-10 kind of thing, the thing that concerns me or that I always try to raise with people is the whole concept of transparency and trying to understand the reality of what's behind this. So you make a good point. If we have top three offenders of people who are the people who constantly requesting things from us, it's important, I think, to stop and look at those things and say, how many of these things w