Agile Mentors Podcast from Mountain Goat Software

The Agile Mentors Podcast is taking a short summer break, but that does not mean the conversation is stopping. In this special update, Brian shares what is ahead for the show and introduces a new podcast exploring one of the biggest questions facing modern teams: what happens when AI becomes part of how work gets done?   Overview   As the Agile Mentors Podcast pauses new episodes for the summer, Brian takes a few minutes to reflect on what this community has explored together over the years. While Scrum, Agile, product ownership, leadership, and coaching have been recurring topics, the deeper theme has always been people: how teams learn, collaborate, make decisions, and improve over time.   Brian also shares details about his new podcast, People Over Prompts, which will focus on the changing relationship between humans and AI at work. As AI moves beyond being a simple tool and becomes a more active collaborator, organizations are being challenged to rethink team structures, workflows, accountability, and decision-making. What does a team look like when every person is supported by multiple AI agents? What responsibilities should remain firmly human? And how do we preserve judgment, creativity, and shared understanding in an AI-enabled workplace? This episode offers a preview of those conversations while looking ahead to what comes next for both podcasts.   References and resources mentioned in the show: People Over Prompts podcast #82: The Intersection of AI and Agile with Emilia Breton #175: When AI Makes Agile Teams Worse with Hunter Hillegas AI Doesn’t Eliminate Agile Teams — It Increases the Need for Great Ones 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 [email protected] 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.

Retrospectives are supposed to help teams improve, but for many teams they slowly become rushed, repetitive, or skipped altogether. In this episode, Brian Milner and Cort Sharp unpack why retrospectives lose their value and what Scrum Masters and leaders can do to make them useful again.   Overview When a team stops engaging in retrospectives, it is usually a symptom of something deeper. Sometimes the format has become stale. Sometimes the team no longer feels safe being honest. And sometimes the biggest issue is that retrospectives create plenty of discussion but very little meaningful change. In this conversation, Brian and Cort explore the most common reasons retrospectives begin to fail and how teams can rebuild trust in the process. They discuss the importance of psychological safety, why teams should focus on fewer actions instead of trying to fix everything at once, and how Scrum Masters can better tailor retrospectives to the personalities and working styles of their teams. They also share practical ideas for making retrospectives more engaging, more actionable, and more valuable over time.   References and resources mentioned in the show: Cort Sharp Amy Edmonson, Psychological Safety #139: The Retrospective Reset with Cort Sharp #141: Cooking Up a Killer Retrospective with Brian Milner The Empirical Retrospective Approach 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 [email protected] 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.

A lot of organizations say they’ve “gone Agile,” but still struggle with missed deadlines, unclear priorities, and teams that feel busy without delivering better outcomes. In this episode, Scott Dunn joins Brian Milner to unpack why Agile ROI is so often misunderstood and what leaders should actually be measuring instead.    Overview What does a successful Agile transformation actually look like? Too often, organizations adopt Scrum or Agile practices because everyone else is doing it, without first defining the business outcomes they hope to achieve. The result is predictable: teams follow the motions of Agile while leadership struggles to see measurable value. In this conversation, Brian Milner and Scott Dunn explore why ROI conversations around Agile frequently go off track and how leaders can reconnect Agile practices to meaningful business goals like faster delivery, improved customer satisfaction, stronger collaboration, and better adaptability. They discuss the hidden cost of operationalizing Agile too early, why coaching and leadership alignment still matter, and how the rise of AI makes strong Agile fundamentals more important, not less.   References and resources mentioned in the show: Scott Dunn #104: Mastering Product Ownership with Mike Cohn #132: Can Nice Guys Finish First? with Scott Dunn Do the Proven Benefits of Agile Training Justify the Costs? 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 [email protected] 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. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum.

Many leaders assume Agile breaks down in highly regulated environments. John Holmes has spent years proving the opposite inside aerospace, defense, and space programs where the cost of failure is extremely high.   Overview   In this episode, Brian Milner talks with Scrum Inc. Fellow John Holmes about what it actually takes to apply Scrum in complex defense and aerospace organizations. From military programs to space systems, John explains why Agile is often less about moving faster and more about creating visibility, improving communication, and reducing the risk of major surprises late in delivery.   John also shares practical lessons from coaching teams inside highly disciplined environments where command-and-control leadership has traditionally dominated. The conversation explores how Agile can strengthen discipline rather than weaken it, why trust and training matter more than process compliance, and how small operational changes can create meaningful improvements in delivery, alignment, and team effectiveness.   References and resources mentioned in the show:   John Holmes #107: Transforming Organizational Mindsets with Bernie Maloney #108: Adaptive Organizations with Ken Rickard There Is No End State When Transitioning to Agile 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 [email protected] 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. John Holmes is a Scrum Inc. Fellow who has spent decades helping aerospace, defense, and government organizations apply Agile and Scrum in some of the world’s most complex environments. From launching Scrum for Space at Lockheed Martin to training thousands of leaders and teams since 2005, John brings a practical, field-tested perspective on what it really takes to make Agile work where the stakes are high.

AI can help product owners move faster, but faster is not always better. In this episode, Lance Dacy and Brian Milner explore where AI genuinely improves product work and where teams still need strong judgment, clear priorities, and real customer understanding.   Overview   As development teams adopt AI tools at a rapid pace, product owners are under pressure to keep up. Brian and Lance discuss how AI is already changing backlog refinement, product discovery, stakeholder communication, and day-to-day product work. They also explore why many teams are still using AI too narrowly and missing larger opportunities to improve decision-making and collaboration.   The conversation stays grounded in practical application rather than hype. Lance shares where AI can save product owners meaningful time, where human judgment still matters most, and why teams need to be careful about treating AI-generated output as automatically correct. If your team is trying to understand how AI fits into modern product leadership, this episode offers a realistic starting point.   References and resources mentioned in the show:   Lance Dacy #117: How AI and Automation Are Redefining Success for Developers with Lance Dacy #164: Why Innovation Efforts Fall Flat with Tendayi Viki AI Doesn’t Eliminate Agile Teams — It Increases the Need for Great Ones 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 [email protected] 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.

In a world changing faster than most teams can keep up with, standing still may be the biggest risk of all. Brian Milner sits down with Stavros Stavru to explore why experimentation is no longer optional and how teams can build a culture that adapts before disruption forces it to.   Overview Many organizations say they value experimentation, but few create the conditions that make real experimentation possible. Too often, teams either stay trapped in familiar patterns or mistake random change for meaningful learning. In this episode, Brian Milner talks with Stavros Stavru, author of Never Stop Experimenting, about what experimentation actually looks like in practice. Stavros shares how rapid advances in AI and constant disruption are forcing teams to rethink how they learn, adapt, and improve. Together, they discuss the difference between experimentation and “experimentation theater,” why small experiments matter, and how leaders can model the kind of curiosity and adaptability they want their teams to develop. Stavros also shares practical examples from his book, including simple ways teams can test assumptions, gather more honest feedback, and create stronger learning loops in their day-to-day work.   References and resources mentioned in the show: Stavros Stavru Never Stop Experimenting by Stavros Stavru, Ph.D. #56: The Power of Experimentation #118: The Secrets to Agile Success with Mike Cohn When Do Agile Teams Make Time for Innovation? 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 [email protected] 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. Stavros Stavru is an organizational transformation researcher and Agile practitioner whose work focuses on helping teams create lasting alignment instead of temporary improvement. After two decades working with thousands of professionals across 500+ organizations, he founded AhaPlay to turn strategy and behavioral science into measurable team alignment without relying on facilitators.

Too many teams try to “do Agile” by adding layers of process before they understand the problem they’re trying to solve. In this episode, Brian Milner and Cort Sharp discuss how to start Agile simply, avoid unnecessary complexity, and build practices that actually fit your team.   Overview When organizations first adopt Agile, they often make the same mistake: they start with frameworks, terminology, and process layers instead of focusing on visibility, feedback, and learning. The result is a system that feels heavy before it ever becomes useful. In this episode, Brian Milner and Cort Sharp explore a more practical approach to getting started with Agile. They discuss why teams should focus on foundational concepts like transparency, short feedback loops, and clear priorities before worrying about scaling frameworks or advanced practices. Brian and Cort also share the common “drag factors” that slow Agile adoption down, including process overload, coordination complexity, and measuring the wrong outcomes. If your team is trying to become more Agile without creating more bureaucracy, this episode offers a practical starting point.   References and resources mentioned in the show:   Cort Sharp Introducing An Agile Process to an Organization by Mike Cohn + Doris Ford Relationship between Definition of Done and Conditions of Satisfaction by Mike Cohn Why Agile Teams Put So Much Emphasis on Being Done Each Iteration 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 [email protected] 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.

Velocity can help a team plan, but it creates problems when leaders use it to judge performance. In this episode, Brian Milner and Scott Dunn explain why that shift happens so often and what leaders should pay attention to instead.   Overview Velocity is one of the most misunderstood metrics in Agile. Used well, it helps a team forecast and make planning decisions. Used poorly, it becomes a productivity score that encourages inflated estimates, unhealthy comparisons, and a focus on output rather than value. In this episode, Brian and Scott discuss why leaders often reach for velocity, why it gives them the wrong signal, and how teams can reconnect measurement to outcomes, learning, and business impact. They also explore how AI is making this issue more urgent by increasing delivery speed while putting even more pressure on leaders to ask whether teams are building the right things.   References and resources mentioned in the show: Scott Dunn #35: Metrics with Lance Dacy Rethink the Refinement Session: Less Time, Better Outcomes by Mike Cohn The Cost of Change Curve Is Outdated 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 [email protected]   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.  Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. 

Many agile struggles don’t start with the team. They start with leadership decisions that seem reasonable but create friction, confusion, or misalignment over time. In this episode, Mike Cohn outlines the patterns that most often hold organizations back and what leaders can do differently.   Overview In this episode, Brian Milner and Mike Cohn examine the leadership decisions that most often derail agile efforts. Rather than focusing on team-level practices, the conversation centers on how leadership behavior shapes outcomes across the organization. Mike highlights several recurring issues: treating agile as a process change instead of a mindset shift, scaling before understanding what works, limiting product owner authority, and prioritizing speed over focus. He also addresses how well-intentioned leadership actions can unintentionally slow teams down or create dependency. The discussion emphasizes that agile is not something leaders delegate. It requires changes in how leaders make decisions, set boundaries, and engage with teams. When those changes do not happen, teams may follow the motions of agile without seeing meaningful improvement. If your organization is “doing agile” but not seeing the expected results, this episode offers a practical way to assess where leadership decisions may be contributing to the problem—and where to adjust first.   References and resources mentioned in the show: Mike Cohn #118: The Secrets to Agile Success with Mike Cohn #143: What Still Makes Teams Work (and Win) with Jim York Why Teams Matter More Than Ever for Innovation by Mike Cohn How To Fail With Agile: Twenty Tips to Help You Avoid Success by Mike Cohn + Clinton Keith Subscribe to the Agile Mentors Podcast    Want to get involved? This show is designed for you, and we’d love your input.   Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.   Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] 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.

AI isn’t just speeding up coding. It’s starting to change how teams work, what they build, and even who needs to be involved. In this episode, Brian and Hunter separate real impact from hype and explore what’s already shifting inside teams.   Overview AI tools are improving fast, but what does that actually mean for teams doing the work? In this episode, Brian Milner sits down with Hunter Hillegas, CTO of Mountain Goat Software, to explore how AI is being used today inside real software teams. They dig into where these tools are genuinely accelerating work, from coding agents and automated testing to analyzing large data sets and reducing friction in everyday tasks. They also unpack the growing shift from writing code to reviewing it, and what that means for developers and team dynamics. At the same time, they address the gap between hype and reality. Where does AI perform well, and where does it still fall short? What happens when adoption is pushed top-down without clarity? And how might AI start to reshape roles, collaboration, and expectations across a team? This is a practical, honest look at what’s changing right now, where to start if you’re new to these tools, and how to think about AI as part of your team without losing sight of how real teams actually work.   References and resources mentioned in the show:   Hunter Hillegas Mountaingoat Software’s AI Toolkit #82: The Intersection of AI and Agile with Emilia Breton #169: Building Practical AI for Agile Teams with Hunter Hillegas #175: When AI Makes Agile Teams Worse with Hunter Hillegas AI Doesn’t Eliminate Agile Teams — It Increases the Need for Great Ones by Mike Cohn How to Use AI for Product Discovery and Writing Better User Stories 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 [email protected] 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.

Most teams say they want to improve. Few actually build the habits that make it happen. In this episode, Brian and Lance break down what separates teams that learn from teams that stall—and what leaders do that quietly gets in the way.   Overview What does it really take to become a learning team? In this episode, Brian Milner and Lance Dacy walk through five habits that show up in teams that continuously improve—and the leadership behaviors that either support or shut them down. From psychological safety and truth-telling to short learning cycles and focusing on the right problems, they unpack what actually drives improvement inside real organizations. Along the way, they challenge common assumptions about silence, metrics, and “heroic” problem-solving, and offer practical ways leaders can shift their approach starting immediately. If your team feels stuck, busy but not improving, or hesitant to speak up, this conversation gets to the root of why—and what to do about it.   References and resources mentioned in the show:   Lance Dacy Blog: Why Teams Matter More Than Ever for Innovation by Mike Cohn #143: What Still Makes Teams Work (and Win) with Jim York #171: Why Agile Teams Succeed—or Don’t with Colin Fisher Subscribe to the Agile Mentors Podcast    Want to get involved? This show is designed for you, and we’d love your input.   Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is 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.

Many product teams are busy, but not necessarily effective. Brian Milner talks with product consultant Jason Knight about why so many organizations struggle with prioritization, customer insight, and measuring success—and what it takes to build a product organization that actually delivers value.   Overview What does it really mean to transform a product organization? Brian Milner sits down with product consultant and One Knight in Product host Jason Knight to explore the gap between how product management is described in books and how it actually works inside most companies. They discuss the reality many teams face: massive backlogs full of competing priorities, pressure from stakeholders, and organizations that say they are customer-focused but rarely talk to customers. Jason shares practical perspectives on prioritization, strategy, and why good product teams must learn to say no—even to good ideas. The conversation also dives into customer discovery, the barriers that keep teams from speaking directly with users, and how organizations should think about measuring success beyond simply “building the feature.” If your organization is trying to move beyond feature factories and build a stronger product practice, this episode offers a grounded look at where to start.   References and resources mentioned in the show: Jason Knight One Knight in Product Podcast Blog: What Does a Product Owner Do, When, and Why? Blog: How to Ensure You’re Working on the Most Important Items Each Iteration by Mike Cohn #124: How to Avoid Common Product Team Pitfalls with David Pereira #154: The Underpowered PO with Barnaby Golden Subscribe to the Agile Mentors Podcast    Want to get involved? This show is designed for you, and we’d love your input.   Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.   Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is 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.  Jason Knight is a product consultant, coach, and host of the One Knight in Product podcast who helps scaling B2B companies move beyond feature factories and build product teams that deliver real business impact. He works with organizations to connect strategy to execution through fractional product leadership, workshops, and coaching that bring clarity, alignment, and measurable results.  

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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 working for the sake of working? so yeah, just harping on that a little bit. Brian Milner (07:50) right. Yeah, yeah, I mean, I agree. And I kind of have a similar response. And I think that there's, you know, the good enough argument, right? ⁓ Sometimes people take exception to that and say, well, why would we be okay with only doing something good enough? Well, it's not about quality, right? It's not saying that the quality of what you do is good enough, but it's saying that the... Cort Sharp (08:22) Mm-hmm. Brian Milner (08:41) the amount of functionality is good enough. And I think your example of the cell phone is a great one because, know, I'm old enough that I remember before, you know, that was the main way that people took pictures. You know, when you had the little flip phones and stuff, the quality in those were not very good. And so you would have other digital cameras that would took higher quality photos. But the reason that it won out in you started to just see more and more pictures taken from a phone, even though they were lower quality, was because you always had your phone with you. And so there's sort of an extent to which you would say, how badly do I want to carry around an extra device that's just for taking pictures, even though it takes better quality pictures, is the quality that I'm getting with the phone good enough and there was a tipping point there, right? There was a certain point where it went out and the quality of what was on the phone was high enough that people said, yeah, I don't need a separate digital camera anymore. This is good enough for what I need and that one. And I think that that value curve is very similar across any product. There's a certain level. that when you add features, it's a steep value curve. But after you've added those key core things, then it starts to tail off. It starts to flatten. that flatten, it may still be going up, right? But the effort that it takes to deliver something is not the same return on that investment of effort, right? Early on, it's a huge, you that effort creates a spike in value. Later on, that effort creates a small little spike in value. At a certain point, that's where they talk about trimming the tail. At a certain point, that's what they mean by it is that value curve has gone past that point where now it's flattened and we're incrementally adding small little things, but they're not valuable enough to justify the effort that it's taking to build them. Now, will AI change that? I don't know, right? Because if we have a bank of AI programmers, I don't know that it actually changes it because we still could have that bank of AI programmers doing something else instead, you know? ⁓ Cort Sharp (10:48) Hmm. Right? Right? So it's figuring out that value proposition side of stuff. Yeah. Yeah. Brian Milner (11:05) Right, right. The impact, actual, you know, how much do people care about this being there? And, and at a certain point, you know, we had a podcast recently where we talked about this, just at a certain point, there's a, an end of life, right? At a certain point, you have to deliberately say no to something and say, you know what? This product has done all it's going to do and we'll support people that still use it up to a certain point. But at a certain point you say, no, it's better to have a new product now, where that value curve now starts to get really big again. So yeah, I mean, from an AI standpoint, I think it does make an impact because it kind of just makes it more apparent where that problem is. ⁓ And that's why I think I tell all the product owners that come through classes, I think product owners are poised to become highly impactful. Cort Sharp (11:46) Mm-hmm. Mm-hmm. Brian Milner (12:00) in their organizations in this AI era. Because if you can refine your craft to a level to where the things that you are producing are all a lot of value, right? All creating a lot of value, then now we have the productivity to spit out more and more of that stuff. And if your side of it's taken care of as well, then everything that we're producing is now producing a lot of value. Cort Sharp (12:29) Right. Right. I think it opens the door for programmers, developers. I'm not just going to say programmers because I know AI can help out in every aspect of the development process. But I think it opens the door to developers, not only just being more productive, but also just being able to experiment with new things more, more readily, more easily. Right. And we can, we can kind of simulate some of what our customers might want. Right. If we can build a really great persona. I know you've done this in a class recently, Brian. I'm doing a similar thing and just saying, look, let's build out this persona using an AI tool that we can use and create basically an AI agent and say, here you go. This is my ideal customer. Here's my product. What pieces or new features of my products can I focus on in order to deliver higher value to this customer? which is exactly what a product owner does. So I totally agree with you there, Brian of saying, yeah, the role of the product owner is about to become one of the most valuable roles, in an organization, in, in understanding. How do we deliver value to our customers? What do our customers even want? Right. Starting there. If you can build all the cool things you want, if your customers don't use it, who cares? Right. So many examples of that, what I called out earlier, but so many examples of that of like, if you build stuff just for the sake of building stuff, is it worth being built? And I think that's more so the question that we're gonna shift towards within our development cycles of how do we know that this is worth being built? And what quick feedback loops can we start going down in order to get that? Brian Milner (13:58) Right. Yeah, I used to always like to quote this, know, everyone's always heard the phrase, you know, if a tree falls in the woods and no one's around, does it make a sound? And I always equate that to, you know, software as well. If software is built and no one uses it, was it really built? You know, and I know I've been on the end, the bad end of that in the past where I've worked on things with development teams that Cort Sharp (14:28) Yeah. Yeah. Brian Milner (14:37) We've worked long and hard on something only to have the rug pulled out from underneath us and for management to make decisions and say, no, we're not going to do that thing. And that's a horrible feeling. There's nothing worse. no one out there wants to, I mean, go back to my stats, 50%. Nobody in software development would feel good about themselves if they said, hey, 50 % of the stuff you've worked on, no one ever saw. Like that's not a warm fuzzy feeling. ⁓ Cort Sharp (15:06) Yeah, could you could you imagine building a car and then building this awesome, incredible car and then you're ready to roll it off the factory line and then all of a sudden it gets cut in half and that's what gets delivered and that's what because that's all that people use, right? Brian Milner (15:18) Right. Right. Or you work overtime on the engine going from zero to 60 and you find out that this is just going to sit in a garage. It just doesn't make you feel good because that's not what it's been built to do. ⁓ So yeah, I think that you're absolutely right. We have to focus on the discipline of knowing our customers, knowing what they want. Cort Sharp (15:24) Mm-hmm. Yeah. Right, right. Brian Milner (15:44) And then checking and asking them, did we actually deliver what you needed? ⁓ And it's funny, I was talking with someone this week about this and it's amazing to me the number of times I've talked to people in the product area that will build things. But when you ask them, did you decide to build that? You had a whole host of other things you could do. Cort Sharp (15:51) Mm-hmm. Brian Milner (16:10) made you decide to do that instead of the other things. And I'm always shocked at the number of times I get blank stares or just no response at all because it's a great thing to do, right? Well, you're asking me, don't ask me. You should be able to say that, right? You should be able to. to back it up and say, yeah, here's the research behind it. Here's the market study. Here's the business case. We ran these tests, and these tests showed this level of interest. You have to know what it is you're trying to do first. And if you don't know what it is that it's intended to do with your customer, then how do you know whether you actually succeeded at it? Cort Sharp (16:41) Right. Yeah, absolutely. one thing that comes out of that is like, how much of that data do you take and how much time do you spend on gathering that data? I've heard a phrase recently and it goes along the lines of like be data informed but not necessarily data driven. where we want to use data to inform our decisions, but we don't necessarily want to gather all the data in order for it to be 100%. We're not going to make a decision unless we have this data point to guide our decision or drive our decision. Yeah. Brian Milner (17:27) Yeah. Yeah, no, yeah, it's, know, we had, I think that the way to think about it is properly is bets. You know, that you are making bets in different areas and you don't make a bet, you don't wait to make a bet until you're 100 % certain. Cause you're never 100 % certain on a bet, right? There's always a percent chance that it could go one way or the other. But what you try to do is, you know, make informed or maybe that's not even the best analogy. Maybe it's more like an investment. You know, when you make an investment in a stock, it's not just a pure bet because it's not a flip of the coin. Right. If you do your research and you know enough about the company, then there are better investments than others. And Cort Sharp (18:02) Mm-hmm. Brian Milner (18:18) I think that's the way we should look at our features and our products is to say, this is an investment in our company. So I want to invest wisely. And you wouldn't be very smart, I'll put it this way, to have an investment strategy in the stock market of just pointing your finger at something and say, hey, I'm going to spread out my investments over these 10 companies that are just random companies. Cort Sharp (18:30) You Brian Milner (18:42) because one of them is gonna hopefully turn out to be successful. You're not gonna succeed, right? But if you research the 10 things that you're investing in, if you kind of know the history, know the trend line, know where the forecast is, all right, well, this one has a strong chance I'm investing here. ⁓ That's how you're successful. And we don't seem to always do that with our products. Cort Sharp (19:02) Right. Yeah, I've kind of tied that back into our products and a conversation I had with a product manager, product manager, they weren't a product owner or a project manager, but a product product manager, gosh, three months ago or something like that. Small company, very small company. Just I knew the guy from from school and was talking with him and he goes, yeah, we feel like two week sprints is too long. We even feel like one week sprints are too long. We're trying to shoot for one day long sprints. And my question back to him was, okay, why, first of all, why would you want to do that? And he goes, well, because AI just allows our developers to be so much more productive and do more things. I'm like, okay, I could buy that. But my second question to him, which goes along the lines of what you were talking about here, because getting that feedback, getting that data, let's be data informed, not data driven, was how do you make decisions on, how do you give feedback to your developers? How do you make those decisions on, yeah, this is the highest priority today versus yesterday? Is the market shifting that quickly that you have to make those decisions? And let's say it is, let's imagine we live in that world right now. Some of you probably do, but I know someone out there probably does, but how do you, do that? what tips would you give Brian to this guy about, yeah, let's drive the decision making forward and let's give the feedback faster if our development team is able to actually deliver a fully featured feature. How do give them feedback on such a short timeline? Brian Milner (20:44) Yeah. Cort Sharp (20:47) I see teams all the time struggle with saying, yeah, we get good feedback every two weeks with our sprints. I've seen teams be like, yep, two weeks is no problem for us. We get good feedback. We're able to move forward. We're able to make decisions, be data informed, and move forward that way. So we cut our sprints down into one week. I think one week is probably like the, in my mind, at least in my experience, is kind of that. lower end, the lower lower echelon, I guess, of the ability to provide meaningful feedback and meaningful delivery stuff. Brian Milner (21:16) Yeah. Well, it's also about, can you create something that is of meaningful value in that timeframe? Because our product increments should be valuable. And that's what's probably going to be the blocker for most teams going to a day-long sprint or so is because, yeah, we can't produce something valuable enough in just a day. It takes us multiple days. ⁓ Cort Sharp (21:33) Yes. Right. Right. Brian Milner (21:46) In general, mean, I would applaud it in general because I think the shorter time span is generally better. I generally have more of a problem with people who want to go the other way and be too long, you know, and do like a month long sprint. So I would much rather have a team that wants to do a day sprint than a month long sprint. But that, mean, the questions I'd ask about a day long sprint is, Can we produce something meaningful within the day? And maybe the answer is yes, right? Maybe across the team, there's enough work and maybe the work is small enough, right? That's really what it would take is the breakdown of the work is small enough that they can actually get stuff out that's valuable within the course of that day. So are they able to produce value in a day? It might. get to feel a little ridiculous as far as the meetings are concerned, right? Because that's one of the considerations when you try to choose your length of your sprint is, how often can I have these meetings? Take for instance, just the sprint and review, right? We need important stakeholders at the sprint and review. Can you have important stakeholders every day? If not, Cort Sharp (22:48) Right. Brian Milner (23:01) If what you're doing is no, that cadence is not wide enough that our stakeholders are too busy. They can't come every day. If that's the case, then you might want to consider a longer sprint. That doesn't mean you have to wait on delivery. And I think maybe that's something I'd ask them as well is, are we confusing the sprint length with delivery length? because you can deliver every day. You can deliver multiple times per hour. There's nothing that says in Scrum that it's tied in any way, shape or form to your sprint length. And if that's the intention is to just release things more often, then absolutely, right? If your system is set up to do that, it doesn't matter if you have a week long or month long sprint, if you can deliver things every day, It's a much better process because back to your original point about feedback, can you get meaningful feedback? Well, if we're delivering it every day, we're going to get more meaningful feedback because we're not only getting feedback from just the internal stakeholders, but we're getting it from external customers. ⁓ Let's just say if we have a week long sprint and we're delivering every day, we have feedback from actual customers by the sprint review. Cort Sharp (24:06) Right. Brian Milner (24:14) that would be an incredible position to be in, to be able to say, yeah, we've released these 10 things this sprint, and here's what the customers are already saying about it. We got this feedback, or this one has generated this much support, so now we have tickets to kind of handle that. Yeah, it's in general a good thing. I'd want to make sure on those other areas to make sure that it's not being confused maybe with something else. Cort Sharp (24:37) Yeah. Yeah. Just understanding the definition of what a sprint actually entails. through that conversation, it turned out they, were on the, you know, we just want to deliver every day and, and, you know, we have our sprint review at the end of the week and whatnot. And I'm like, okay, so you're not having day long sprints. You're doing a week long sprint. Yeah. Yeah. Yeah. We, we laughed about that a little bit, but, yeah, I think the Brian Milner (24:50) Yeah. So they're doing week long sprints. Yeah. Yeah. No, that's great. I I applaud them on that. That's a mature thing to do. And if your team can get to that stage, it's only because you've invested heavily in automation and DevOps and those kinds of things. It takes discipline to be able to do that. And I'm sure they were advocating it to you because they saw the benefit of what it provided them to release more frequently, which... is an admirable thing. Cort Sharp (25:25) Yeah, 100%. They were like, man, this is awesome. I know you're in this space court. Like, let's talk about this. And yeah, it was a great conversation. It was a lot of fun. But they were, yeah, they were just kind of confused with what it actually meant to hold a sprint. I think they also heard the term Kanban for the first time not too long ago. And they're like, this is the same thing, right? We're sprinting in Kanban, just like we sprint in scrum. And I'm like, I... Brian Milner (25:39) Yeah. Ha ha ha. Cort Sharp (25:50) No, a little different, slightly. Brian Milner (25:51) Yeah, not quite. Not exactly the same. Close cousins. Yeah. I mean, back to our original topic here, I mean, I think as far as AI, we talked about that with product management. And as far as the Scrum world is concerned, I am very interested to see how this Cort Sharp (25:54) Yeah. Brian Milner (26:11) kind of upends the cart a little bit as far as our teams are concerned. I don't think that it, at least from my own perspective, and I could be proven wrong, I don't see it as destroying the team. I don't see it as a complete re-imagining of the process. I think the process still holds. The question is just what does that team look like? Previously, we have a Scrum Master, a product owner, and then a set of developers. Well, would imagine there's teams would probably have less developers because they can boost their own capacity by using AI copilots and other things to help them generate code faster. So maybe a team that previously was eight people is now a team of four or five. And maybe that makes us reimagine a little bit about Scrum Masters and product owners and whether we need them to more frequently be across a couple of teams rather than just a single team. Yeah. Cort Sharp (27:12) With that, this question just popped into my mind and you got into it a little bit there with like, do we need our Scrum Masters or product owners to be across multiple teams? What would your ideal, let's say AI takes off, you're in charge of organizing 10 teams, right? And you have all the people that you need. So you can have as many product owners, as many Scrum Masters as you need. And we want to have our developer count be, you know, five developers per team or three developers per team. Let's, let's try to go down that path of saying we're small, right? We, we have AI. allows us to accelerate the speed of our development per developer. Right. So, would you have one product owner per team and then have the scrum master float around, or would you have the scrum, same number of scrum masters as product owners? Brian Milner (28:04) it would greatly depend, because I just different scenarios might require different things. in general, then I'd probably, I'd probably match them up as much as possible. because in general, I think there's kind of similar demands on both. They're different, but similar volume of demand. the interesting thing to me is, the volume of work that can be created by a team of eight developers or so right now, if that same volume of work can be generated because each developer now has the tools that their abilities are enhanced, again, I don't see it as replacing, I see it as enhancing, right? If... If they can do that and they had eight, now they can do the same volume of work with four. Well, it's not reducing the volume of work for the product owner, right? Because the product owner still needs to manage a backlog and prioritize and stakeholders and customers, right? That's not going away. The work from the Scrum Master, I think obviously changes a little bit because Cort Sharp (28:58) Right. Brian Milner (29:10) While it's one thing to try to manage team dynamics and get them to high performing levels when it's eight people, it's a lot more individual focus when it's four. So that's why I would say for a Scrum Master, maybe it does become more viable to be on a couple of teams because we're not contributing to the product. In general, we're not building things. Or maybe that becomes the new mode as well as the Scrum Master is more of a hybrid role with a combination of them and developer. I don't know. ⁓ I think time is going to tell that over the next few years. Cort Sharp (29:43) Right, right. Right? Where my mind went with that was, I would much rather have two teams of four than one team of eight, well, developers, right? Two teams of four developers that are as productive as my one team of eight each individually. and instead of kind of cutting the head count down, so to speak, or reducing head count, I'd much rather reconfigure the way that my teams are organized right now in order to Brian Milner (29:56) Yeah. Yeah. Cort Sharp (30:13) Utilize AI and I don't want AI to be replacing my developers. I want them to be I want it to be helpful to them I want it to augment their abilities and enhance their abilities like you were saying and in my mind if you know if I was running a company ⁓ We all think we all think we're in that armchair, right? We're all sitting in the armchair saying if I could make all the decisions for a day. What would I do? ⁓ In my mind, I would say okay Brian Milner (30:28) Yeah. Yeah. Cort Sharp (30:38) I don't view this as a, I can replace my development teams. can instead effectively, let's call it double, you know, I get twice the productivity out of one developer with AI versus one without. I could double the amount of deliveries I get. I could double the features that I produce, that my teams produce, or along those same lines, you could probably figure out a way to cut down the delivery timeline. Brian Milner (30:54) Hmm. Cort Sharp (31:07) and cut it down in half, which goes back straight up to that top of the top of the hour question that we were talking about of product management is the roadblock. It's the bottleneck there to decide how do we get this sooner? How do we get these feedback loops quicker? Right. So. Brian Milner (31:25) Yeah. And to expand on that point, right? mean, if you're, if you have two teams of four that, you know, and that one team of four produces the same volume that previously a team of eight would do. Now I've got two teams. I'm doubling the volume that I can actually create. So to your point, there, there are some who would look at that as, I just lose four developers and To them, here's what I'd say. Imagine this scenario, two companies, right? And both these companies, they're competitors. These companies have the same exact situation happen to them. AI comes on the scene, AI enhances the productivity of their development teams. And one company says, hey, I can lose four developers and have the same level of productivity as I have today. So four people get pink slips, right? they maintain the same level of development that they have today. The second company says, hey, I can get twice as much done. So they start expanding the number of things they can produce. since they're assuming their discipline is in shape, they're producing things that people actually care about. Which of these two companies is going to win? It's gonna be the second one. Cort Sharp (32:33) Mm-hmm. Brian Milner (32:40) It's going to be the one that actually can now deliver more value to the customer. So I would not jump to that conclusion. And I don't think that's necessarily going to be a successful company that jumps to the conclusion that, I'm just going to slash my budget for developers because now I can get the same volume with less people. yeah, but your competitor is going to have double the volume. Cort Sharp (33:03) Right. Brian Milner (33:08) with the same number of people and why wouldn't you do that instead? Cort Sharp (33:11) Right, totally. I totally agree with that. Part of me is really excited to see the studies that come out and say, here's the differences between these two companies in the similar space. One reduced their development and replaced with AI, and one enhanced their development teams with AI and didn't replace anyone with AI. And just super interested to see the difference in... evaluations, in productivity, in releases, in whatever it is, right? And I'm going to try to see if there's anything out there right now because... ⁓ Brian Milner (33:45) Yeah, well, this is my call out to everyone listening to you, right? Like if there's researchers out there, go research this and ⁓ let us know. Or if you're in the middle of researching it, please let us know, because I'd love to see that study as well. Cort Sharp (33:52) Yeah. Yeah, very fascinating, right? ⁓ Well, awesome. Brian Milner (34:00) Yeah. Well, this is, this has been great, great court. I think this is a great topic and, you know, we've, we've gone a little bit past our time, but it's, it's one those deep topics we could talk about for a long, long time. And, I, know, truth of the matter is time will tell, you know, like this is just, we're on that edge of the frontier where now we don't really, no one can say a hundred percent. we have to see how things kind of play out and, take it from there. Cort Sharp (34:27) Yeah, absolutely. I couldn't agree more, Brian. I think this was a great topic. Thanks for taking the time to chat with me today. you got me a little more that I'm thinking about now. So thanks for that. Brian Milner (34:36) you Yeah, absolutely. Thanks, Cort. Cort Sharp (34:41) Thanks, Brian.

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 [email protected] 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 then once you pick a direction of travel, now you've got multiple options of different product ideas, services, business model, value propositions, offerings, technology, stacks, et cetera, et cetera. Once you get to that point, you then cannot pick the winning idea on day one yourself. You have to stop building a systematic process of discovery. so you may be, and we, so we often say when you're at that stage, make multiple small bets, right? OK, and I like the way you phrased the question, by the way, because you said, how do you choose what to double down on? That's what you said. You said double down, right? Well, you don't double down on something unless you've made an initial small bet. You double down after an initial bet. Doubling down is I've made a bet, now I'm doubling down. But what companies do is they just make a large bet, and they call it doubling down. But it's not really doubling down. You've just made a large bet. Brian Milner (08:18) Yeah. Yeah. Hmm. Tendayi Viki (08:38) Right? Doubling down is a follow on bet after an initial bet. And so it means that the first bet is a punt. It's a, see what happens bet. And then the question is, what do you want to see? So somebody just wants to see size of market. Somebody who's wanting to see a real customer with a real need. Somebody who just wants to see a real customer with a real need plus an internal capability to create value. So they'll say, if I give you my 50K, you have to answer both these questions before I double down. And some of these will say you have to answer only one of these questions before I double down. And then so I'll give you less, I'll give you 20K. So that's how you start building these frameworks, right? You start going like the one we built at Pearson, right? You go, ideas, it's ideation, it's strategic thinking. We don't invest any money. That's free. But when you start going into discovery, we might give you 25,000 pounds and you earn the next level of bet by the data you bring using that 25,000. And we have a list of questions that we need positive answers to before we actually make the doubling down. And so that's a way of curating ideas based on evidence and some kind of action and activity. Brian Milner (09:48) Yeah, it's amazing to me, like in some of the companies I work with, it's amazing to me to see how many times people will choose bets that they're going to make, but not really even be able to articulate what it is they hope that bet will actually do. Right? Not just, you know, like we have this feature that we're betting on and we think if we add this feature that it's going to, you know, be cool. It's gonna, you know, people will love it that will add this feature, but they don't go the extra step of being able to articulate, yeah, but what does that mean? Does it mean that you're gonna increase your return on investment? it gonna increase your customer satisfaction? So that kind of gets to the heart of how do you measure whether it's actually a successful bet or not? Tendayi Viki (10:39) Yeah, exactly. mean, to go way back in the days, to Dave McClure and the pirate metrics. I'm sure you were like, R, right? It's like if we do acquisition, activation, revenue retention, referral, whatever those R's are, you could add a few others that you want. So those are metrics. Why would we ever build a feature that's not connected to any one of those goals? Like, what's the point? Brian Milner (10:58) Yeah. Yeah. Tendayi Viki (11:07) Right. A measure of satisfaction is referrals, maybe. A measure of customer satisfaction is retention, maybe. You could measure customer satisfaction with your NPS scoring or whatever, right? Like, if you have all those things laid out, then you go, right now we're working on this thing because we believe that it's going to increase our ability to acquire customers. by how much? Possibly by 5%. OK, now we have a benchmark. Then we have a way to start testing whether the things we're building are actually Brian Milner (11:17) Yeah. Tendayi Viki (11:33) actually creating value. I don't think that there should ever be a wouldn't it be cool if conversation. Maybe at the beginning, but later. Brian Milner (11:39) ⁓ Yeah, businesses don't... Right. That's not really a great model to build a business on, right? It's just, I think it would be cool. Tendayi Viki (11:48) Yeah, it was crazy. I was once working in the large organization and they had disparate products on different platforms. So they had this thing where they were going to put it all as like one on one website, one platform, one product layout. And for them, it was in the backstage of the business, was value creation because it lowers costs and puts everything in an easy to manage place. But then I was like, have you guys ever considered that you could potentially destroy value by putting everything, like you could essentially like make it worth for customers. Like it's not automatic, but just because you've now put everything on this one thing, they even called it the one strategy, whatever. But then because you put it all in this one thing, that is automatically value for customers. So who's in charge of checking for that? Because it's distinctly possible that you've just made things worse. You're going to see a drop off in customers and you're to see a drop in revenue. So that's really something to always be thinking about, right? Brian Milner (12:21) Yeah. Yeah. Yeah. Yeah, or kind of parallel to that would be if we wanted to add something because we thought it was going to increase customer satisfaction, but it kept customer satisfaction flat or even declined. But maybe it did something else well, like it raised revenue or something like that. It's still not a success, right? Because what you were trying to do was to increase customer satisfaction, and that's not what you did. So you still need to do that, you know? Tendayi Viki (13:09) Yes. Yeah, exactly. I mean, you still need to fix it in such a way. If you want to retain it because it grew revenue, then you do need to make it work somehow to make customer satisfaction work because yeah, today's revenue is not tomorrow's revenue. Customer satisfaction is the best way to create value. Brian Milner (13:24) Exactly. Yeah. Well, this discussion seems to, know, when we talk about innovation and we talk about this product life cycle, there's, I think, you we can't avoid the term or the concept of experimentation a little bit. And I know you talk about that quite a bit in your writing, kind of the idea of experimentation and what that means, you know, as far as what the expectation should be when you experiment. on things. So I want you to talk a little bit about that. kind of what should what should we what should Scrum Masters product owners? What should we be thinking about when we what should agile teams think about when we think about experimentation and failure? You know, how does a healthy portfolio kind of bet? What does that look like? Tendayi Viki (14:15) Yeah. like I remember at the beginning, we talked about innovation theater. Remember at beginning? And we said that was like an excessive focus of, excessive focus on ideation. Then there's another form of experimentation theater, which is fascinating, but I've also noticed, which is people think they're doing well because they're running experiments. Right? Like they're running experiments. We did customer discovery. And Brian Milner (14:21) Yeah, yeah. Tendayi Viki (14:42) But the experiments they're running are not helping them make decisions about the product, the value proposition, or the business model. So I eventually wrote a piece. I think you've already find it in four or five years ago. But the goal of running experiments is not the experiment. The goal of running experiments is to make progress with your idea. That's the whole goal. So you have to set expectations. You cannot run an experiment that doesn't have a hypothesis and success criteria attached to it. Brian Milner (14:58) Yeah. Yeah. Tendayi Viki (15:11) Like success criteria and hypothesis first, then experiment. Whereas what happens in a lot of organizations, and I've noticed this is, they have a go-to method for experimentation. Like some organizations will go to market surveys. Some organizations will go to focus groups. They their go-to methods. So they've already decided what the method is going to be. And then they go, so for the focus group we're going to do next week, what are the questions that you'd ask? And it's like, no, that's backwards. First you have to figure out. Brian Milner (15:11) Yeah. Tendayi Viki (15:40) what you want to learn and then choose the experiment and then design the experiment to deliver those learnings and then look at the data and see if it allows you to make decisions. Great. So that's really, really important. So if you're a Scrum master, like that should be a fight that you have all the time. like, okay, when we finish the experiment, what decision will we be able to make? And then we go, oh yeah, we'll be able to make a decision of whether the pricing works. Brian Milner (15:42) Yeah. Mmm, love that. Tendayi Viki (16:08) We want to the decision of whether we should keep continue producing this feature or stop. We'll be able to make the decision of whether the position of this thing on the landing page is impacting sales. We should be able to make a decision. And then we say, OK, now we're running the experiment. Not to the experiment and then come back and go, yeah, we learned a lot. Customers are like this and customers are like that. it's like, OK, but what decision did you make after the learning? And that's a really important, the connection between experiments and decisions is something that Brian Milner (16:14) Yeah. Tendayi Viki (16:37) I don't see that happening a lot sometimes when I walk into an Agile team. Brian Milner (16:42) Yeah. Yeah, I love your connecting that to the theater kind of concept because you're absolutely right. From the outside looking in, it looks like, hey, great, they're doing all this experimentation, but it should be driving some decision. Like you said, it should be driving some kind of a movement forward. And if it's not, then you're going through the motions of doing the experimentation, but you're not really applying that that knowledge that you gain from it. yeah, that's why I think it's so important to be able to state it from the outset. Like you said, I've got to have the hypothesis. I've got to be able to say, here's what I hope to learn. Now let's try to do this thing and let's see what happens. And now we can say, now that we know this, what do we do about this? ⁓ Tendayi Viki (17:14) No. Exactly. And analysis paralysis is finding data for no reason. you don't have, like, what is the, why are we mining the data? What's the reason? What are we looking for? Because as soon as we find it, we stop. But if we're just like reviewing customer interviews and reviewing this, like it's interesting and it's busy work and it makes us feel like we've learned a lot, but we're not making business decisions at the end of the day. you know, it's not really valuable. Brian Milner (17:27) Right. Yeah. Yeah. Well, I hope this doesn't put you to the test too much because I know this is not your latest book, but in the lean product lifecycle, I know you talk about kind of how the product life cycle, I love that term even, that it is a life cycle of a product and it kind of goes through phases, maturity phases almost, you know, and that's because you kind of brought that up in what you just said about the fact that, Do we continue or do we not continue? So just for the listeners, can you maybe broadly lay that out for folks, help us to understand a little bit about what that life cycle looks like from idea to retirement? Tendayi Viki (18:24) Yeah. I mean, so in my experience, a product or a service has two lives, right? Well, actually maybe three lives. Let's call it three lives. There is life before product market fit, life after product market fit, and then life after decline. And so what tends to happen in organizations, which is where the product life cycle or the lead product life cycle is we ended up calling it, became really valuable is that Brian Milner (18:32) Ha ha. Tendayi Viki (18:51) The management tools for life after product market fit are the tools that are really prominent, the execution tools, the scaling, the forecasting, the business planning. That's all life after product market fit, because that's where they make sense. You know the customer, you know how much they will need to pay. You know how to scale. know how to... All of those things are useful for life after product market fit. And what we're trying to do with the Lean Product Lifecycle was to say, happens, what is life before product market fit? And life before product market fit is learning and discovery, it's not execution. So when innovation struggles inside large organizations, it's because they take the toolbox for after product market fit and apply it to before product market fit. So we're trying to a toolbox. So we're like, okay, so what's life before product market fit? Well, life before product market fit is having a great idea or a great collection of ideas that's aligned with your portfolio strategy. And so... Brian Milner (19:36) Yeah. Tendayi Viki (19:48) If you have a whole bunch of really good ideas that you think are going to help you navigate towards where you want to go as an organization, the question then becomes what's the next phase after that? So you run ideation competitions, you generate ideas. Well, if you're going to take the toolbox from life after product market fit, then the next thing you do after ideation is write a business plan. Brian Milner (20:08) Hahaha. Tendayi Viki (20:09) And thinking like, no, you've jumped over a couple of things first. You've just had an idea, you've got to plan first, right? You got to do other things. You got to do something to check if your idea has legs. And so that's when we came up with the next phase after, idea creation, which we called Explore. So we said, OK, so you explore whether the idea has legs. And Explore is focused on deeply understanding customers and their needs. Brian Milner (20:14) Yeah Yeah. Tendayi Viki (20:39) understanding, willingness to pay, size of monoket, just kind of understanding like the front stage of your business model. And if you find that the idea sounded good, but there's no customer need that's going to be able to serve for this, you can do two things. You can make a decision. You can stop the idea or you can change direction to whatever you learned. And then we're like, okay, so after that, we moved to another stage we called validation, which is really now about validating the product, the backstage, the business model, the pricing, the channels. How are you going to scale it? So if you get positive outcomes, now you go product market fits. Then you can go to grow, scaling to the whole thing. Eric Gris wrote about growth engines, What are your growth engines really important and how do you drive growth? And then after a while, the product matures and if you can't figure out a way to revamp the growth, then you can move into what we call the sustained stage where you're sort of sustaining, lowering costs while maintaining revenue. And then after a while you... move to the third phase, which is about taking about which is, you know, retiring the product. And what we tried to do at Pearson was we tried to create a process for actively retiring things. So we would walk into these investment boards and go, great, you want to unlock money for innovation? Which thing are you holding on for dear life, just in case one customer asks for it? And they're like, but this thing, this thing, I'm like, kill all that, like actively retired, go through it systematically, get in touch with the customer. Brian Milner (21:44) Yeah. Ha ha ha! Tendayi Viki (22:03) Say, what do you need? We'll put it for you in this place. It won't change. You can always access it, but there's no more support for that. Like do it in an active way. That way you can systematically move resources from declining products into innovation. So that's effectively the lean product life cycle and the way we designed it. Brian Milner (22:20) Yeah, it's awesome. And what really kind of stood out to me is that there's, we're talking kind of more about at a larger level, at a product level, but the same things actually, it's really quite parallel for a feature level, for items within a product that, you know, they go through sort of a very similar life cycle that you have to explore and you have to understand. what the customer is, what their want is. You have to find the market fit for it. Once you find the fit, you have to expand it. And then you have to eventually end up at retirement because there are certain things that's... I kind of want to get your opinion on this. We seem so reluctant to accept that. The concept of whether it's a product or a feature, the idea that no, it's time to now let that go play on a farm upstate. Why do you think as humans, because I know your background is in psychology, I'm kind of curious what your view is there from a psychological standpoint. Why do think we as humans are so reluctant to let go of these things that we've Tendayi Viki (23:16) Mm-hmm. Yeah. Mm. Brian Milner (23:34) we've invested on in the past, have produced for us in the past. Tendayi Viki (23:38) Yeah, I mean, it's a whole bunch of things, There's inertia, right? It's just like, it's effort to stop something, relook at it, take it off, et cetera, et cetera. And then there's also loss aversion. I I think product teams can always imagine what might happen if one customer shows up and things no longer there. It's like, no, we had three clicks last month. Those three customers. So there's always that fear of like, what might happen. And so you do need to make a discussion. And one of the things that I love about it, Brian Milner (23:57) Yeah. Yeah Tendayi Viki (24:08) Some of the product thinking I've seen out there is like, if we're going to add a feature, if we don't want our product to become bloated, what are we dropping? Right? And so you've always got like on the bubble things to drop that you've been thinking about actively. Then you just think about how do you like roll those things out while you're adding new things? Because yeah, it's not some Frankenstein products in the end, right? You keep adding features, but you're not taking anything off. It becomes really hard to use. Yeah. Brian Milner (24:14) Yeah. Yeah. Yeah. Yeah, I love that. Well, I don't want to let you get out of here without at least giving us a little bit about your latest book, Pirates in the Navy, because it's such a great title. just maybe kind of help us understand a little bit about what was your thought behind that topic. What led you to write that book and what really interested you about that? Tendayi Viki (24:52) Yeah. So, first it was my own like horrible experiences as an innovator inside large organizations, like the kind of mistakes I made. remember once being in a room, running a workshop to try and convince a group of leaders to buy into this innovation process that we were trying to create. And I was getting a lot of pushback, lot, a lot of pushback. And then after the workshop, one of the leaders who kind of took me aside and was like, you know, today I was watching everything you were saying and this Brian Milner (24:58) Yeah. Tendayi Viki (25:21) very little to disagree with about the things you were saying, but what we didn't like was the way you made us feel. so most of the pushback was not really about your idea, it about the way you made us feel. And I said, okay, so over time it's gonna land on me, but like a very slow landing, like would be like, like how slow it's been landing on me. It landed on me that actually, if you're gonna do corporate innovation or any kind of transformation. Brian Milner (25:28) Hmm. Yeah. Tendayi Viki (25:49) the number one skill is actually relationship building. The number two skill is being a good innovator. But what we tend to do is we tend to make innovation the number one thing. We even think of innovators as mavericks. But actually, Pirates in the Navy was this reminder, because there's even a chapter in there that I call, you're not Elon Musk and you don't work in a company full of idiots. It was just a reminder to say, yeah, you don't work in a company full of idiots. People know what they're doing. They've been running the company for a while. They may have blind spots, but they're not idiots. So it's a mutual respect thing that you kind of have to build. so actually, it's funny because I'm about to publish an article in a couple of weeks and a newsletter this week, which is called Innovators Does Not Equal Maverick. And what I'm trying to do is to create this disassociation between having crazy ideas and being difficult to work with. Because we often tend to think that people like Steve Jobs is really like iconic. And part of the iconicness, is that how you say it? The iconography of Steve Jobs is not just how brilliant he was with the product, it's also how difficult he was to work with. Like everybody's like really like, you know, but that's actually pretty rare. Brian Milner (26:54) Yeah. Tendayi Viki (27:08) Like serial entrepreneurs are people that are really good at working with others. Right. And so that's what Pirates in the Navy is actually really about. Yeah. Brian Milner (27:14) Yeah. Yeah, and I've seen people, unfortunately, who have used that example as, well, Steve Jobs was an asshole. I guess that's what I need to be is an asshole because that's what works. No, please, that's not what made him successful was being an asshole, right? Yes. Tendayi Viki (27:31) Thanks. Yeah, no, he succeeded in spite of that, not because of that. And so it's something that's kind of foundationally important. So I have like this thing that I do some conversations that I have with colleagues, just to kind of say, I can usually tell, it's like one of my subtle internal pains that I feel. I can usually sense when an innovator is going to burn out in a logical. Brian Milner (27:58) Yeah. Tendayi Viki (28:02) And that's when every time they open their mouth, people are like... And then so they create like innovation is already a form of deviance, right? Cause you're trying to do something different from the organization. So you don't want to pile on your own personal deviance on top of the ideas deviance, right? You want to be, yeah, it's really important. And so that's what the book was about by the way. The title is a catchy, but it's really just about how do you actually succeed as an innovator inside these more structured institutions. Brian Milner (28:10) Yeah. Yeah. Yeah. That's awesome. Well, thank you so much. for our listeners here, this will all be in our show notes so that you can find quick links to this, find more about Tendayi and kind of his work. But I can't thank you enough for coming on. I really appreciate it. This has been a fascinating conversation. And I just really strongly encourage the listeners, if you like this, if you really found this conversation interesting, check out his work, check out the corporate startup. Tendayi Viki (28:44) Thank you. Brian Milner (28:54) Check out the Lean Product Lifecycle and his newest book, Pirates in the Navy. They're really, really good and I think you'll really enjoy it. So, Tadayi, thank you so much for coming on the show. Tendayi Viki (29:04) Yeah, thank you for having me. I really enjoyed the conversation too.

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 [email protected] 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're asking sometimes the wrong question with the wrong people. You ask a single programmer where they're more productive. It's sitting in my office being able to go get a coffee when I want, not sitting in traffic. Hey, I'm all for that. Who's productive in traffic other than, I'm listening to books, you know, so I am growing myself. But nobody, I'd be hard pressed to find anybody saying I love sitting in traffic. So let's put that to the side. Nobody wants to drive two hours a day to their office and back home. That's terrible. But if you ask a programmer that, would you concur that most of them would say, I'm most productive, just leave me alone. Let me write all the code I want. Brian Milner (07:16) You Lance Dacy (07:30) What do you think of that? So now that's the wrong question then, because now we're working in an agile type, let's say in an agile context, where we're working in an empirical nature, which says we don't know what we're doing. So the more iterative and incremental feedback, the better we understand, are we on the right path or not? Brian Milner (07:33) I think that's probably true. I think most developers would say that, yeah. Lance Dacy (07:52) And so if I was to say, it more productive to let the individuals be efficient at what they're doing and then come together later to learn that we got a big gap where we were from? Or do we sacrifice individual productivity with a lot of collaboration, which they may term as meetings? I don't like to call them meetings, they're working sessions, right? We had a backlog discussion about this, I believe, you not long ago. Backlog refinement is not a meeting. It's a working session to say, hey, customer needs this. How are we going to do it? You know, and What is it that they need? So I find, I'm debating with people on LinkedIn a lot, I love this, so this is why it's top of mind, is even if the customer knows 100 % of what they want, which let's just say they won't, but if they did, you do not know how to build it. One programmer may, but when you got four programmers, some testers, some database people, architect, all these cross-functional skills, how can you sit in a vacuum and do that? So if your work... requires multiple skills to come together and you're trying to build a done increment by the end of one, two, three or four weeks, having an individual productivity to me could be harmful. you look, I told this guy on LinkedIn that I don't believe productivity is one dimensional. So he referenced a Stanford, let's see, this was in 2023, that he was saying that, you know, the Stanford study showed that people were more productive working at home. Well, it was actually a 10 % decline for call center staff, by the way. So that work is not as collaborative, I would say, maybe. That same study, though, found 35 % lower attrition, higher employee satisfaction, which raised the long run throughput. So while they declined in productivity at home 10%, most executives would go, no, I got to come to the office. We can't have that. But what if I told you, you say 35 % on whatever the number is, attrition and employee satisfaction in the long run, would you rather take that gamble or not? know, Gallup did the same thing. He was referencing a state of workplace and they find, you know, customer loyalty and margin was better for people that were in the office. They may be less productive individually, but the customers saw a better outcome. So what are we measuring, right? So Brian, that's what I look at. with these productivity debates, I'm like, my gosh, what does productivity mean? Are we optimizing for delivery to the customer flow, or are we optimizing for the individual utilization of the people on the teams? And I think executives have to make a choice. And I say executives, because they're the ones who influence heavily, whether we, I'll talk about culture in a second. But I find that, If people steer towards individual productivity, we might be sub-optimizing, right? We know this. mean, we know flow and systems thinking and, you know, all the things that we read in books with lean and inefficiency and cross-functional teams. But what is productivity? I don't know. You have to define that. So that's where I go back. What are you trying to achieve? Individual utilization, work from home. Let's go. You want delivery to your customer? Maybe not. Right. Brian Milner (10:54) So. Right. No, you're making an excellent point. so I'll throw maybe a massive curve ball into this discussion because I would propose that we may not, if we're looking at productivity as whether in an agile organization, we should return to office or not, we may be looking at the complete wrong thing because Productivity, I would propose, and I say this all the time in classes, productivity isn't the answer. What do we hear all the time now about AI and developers is that AI is enhancing productivity. It's allowing them to do more in less time. Well, that's great. Individual, right. But that's a volume. Lance Dacy (11:42) Individual productivity, individual productivity. Brian Milner (11:48) calculation, right? When we talk about productivity, that's usually we're referring to a volume type calculation. But that's, you and I both know very well that the missing gap there is actually the value gap. And so the question is, if we're producing a larger volume of work because we are remote, does that matter if the volume of work that we're producing is things no one cares about? We're all familiar with all the studies that show, I've seen multiples, it's somewhere between 64 to 80 % of what people produce in software is rarely or never used. depending on the study that you follow there with that, and if that's true, exactly, that's my point. Right. And so if that's the point, does it matter if we are more productive from home? Does it matter if we're less productive from home? Lance Dacy (12:30) If that's half wrong, it's unacceptable. So it doesn't matter. Brian Milner (12:43) I don't know that it does. think what matters more importantly to an agile organization is are we more producing more value in a remote environment? Are we producing more value in an office environment? And that's something I don't know that there is a study on. Lance Dacy (12:59) Well, how would you study it, right? Because we were just talking about this before we were trying to debate, you know, what is it exactly that we're going to cover? Because we just, it's too big, right? It's maybe a multi-part thing, but it's like, even if you did the study, who are you surveying? Is everybody the same? Like we go into organizations all the time. Yes, the organization's unique. Y'all do unique things. You're great. Your problems are not unique. How we approach solving the problem, we can borrow from other things that we've done. But when you go do a survey, Brian Milner (13:08) Yeah. Lance Dacy (13:29) Are you really ensuring that you're getting all the different psychological profiles? Because I'm going to wrap that discussion up by saying somebody's preference may override everything. who are you serving? Are you getting a good sample that mimics what you might see on a team? So going back to that Stanford study, you have to ask the executives, would you sacrifice 10 % lower productivity for work from home call staff? And I know that's different work than software, but let's just, these are real studies out there. If that same study found a 35 % lower attrition and higher employee satisfaction, what if your people are happier working but less productive and it saves you in the long run from attrition? Is that metric matter? Your CFO would argue yes. You know, it costs a lot of money to hire somebody, bring them on board and you lose all of that knowledge. So yeah, I have the problem of working at home. This is me. I don't like working at home. Okay, I do it for a living. Brian Milner (14:19) Yeah. Yeah. Lance Dacy (14:28) And I have my own little office and I try to shelter myself away, but I love to compartmentalize work or else I'll work all the time. So when I work at home, just nothing, it's hard for me to have barriers. That's just a discipline and rigor thing. When I went into the office, I could hit it hard. You know, I'd go in early. I wouldn't take lunch. just, I'd put in my time, be very productive. I'd leave four or five, be home. And then I was done. You know, of course you answer emails and stuff like that, but that's me. So are you surveying me? Brian Milner (14:57) Right. Lance Dacy (14:57) Would you rather have me happy and be at home and, I'm going to go run this errand right now. I was less productive today because I chopped up my time and lost flow and context switching, but I'm a happier employee and I contribute a lot to the bottom line. So what are we measuring? Right. So I feel like all that to say is I think you hit it on the head. What is, what is it that you're trying to measure? If it's just productivity, yeah, they'll go in the office because this study says 10 % less, but the same study says. Brian Milner (15:17) Mmm. Lance Dacy (15:25) Better attrition rate, higher employee satisfaction. Do your people matter? Well, if that's the case, are you going to sacrifice 10 % productivity? I would. I want happy people working for me. But I don't want that. Brian Milner (15:30) Yeah. Yeah. No, no, that's a great point. And, and, know, happy people do a better job. Happy people, you know, take care of your customers better. There's, there's a enormous benefits from that. And there's, know, there's lots of, lots of speakers and authors out there that will point you to the fact that in leadership, the job is to try to put your employee first and take care of the employees. If you take care of your employees. the employees take care of your customers and that's what you want them to do. And I agree with that. I think that's a good approach. yeah, I think you're right. There's impacts here across the board. And as you said, it's a really broad topic. Lance Dacy (16:20) Well, let's go back to that other thing just real quick. Lance would rather go into the office. Brian Milner (16:25) Right. Lance Dacy (16:25) Let's say Brian, I don't know, haven't dove into your preferences yet. Brian wants to work at home. He wants to be with his kids, pick them up at school. That's right, you know, that's a righteous thing. I love that. All right. So the company would value having both of us. So now what do we do both? You know, we allow an office space and pay for the real estate and all that to let Lance come in because that's what he likes. And we also let Brian stay at home. And then at some point, where do you get them together to solve big problems? I mean, that's the age old. Brian Milner (16:27) Yeah. Lance Dacy (16:54) issue is I think the organization based on what they're doing for that set of time in the initiative has to define what is it is most important to us. And you might even have to shift people around to different work to do that. Say, well, Brian's not a fit for this new thing we're working on because he likes to work at home. So do we have a mechanism and offices to do that? I don't think we're good at doing. Brian Milner (17:17) Yeah. Lance Dacy (17:17) We just hire people and say, here's your job and your pigeon hole for it and career growth and get so busy. It's hard for managers to focus on that. You know, I don't know. Brian Milner (17:25) Yeah, I mean, the thing that I've heard most from people who have been on one side or the other side of this issue is kind of the frustration that they feel sometimes with mandates one way or the other, that they're not based on fact, they're not based on anything but one person's preference who happens to be then the leader, right? So if Lance is the leader and Lance prefers to be in the office, then Lance might say, That's it, everyone's come back to the office because I just think that's a better way of working. And, right. Lance Dacy (17:56) I mean, how many leaders are like that, right? It's like they mimic that preference. you know, it's such a hard thing. think of the other thing, this debate I was having with this gentleman on LinkedIn, really good one, by the way, I love debates. I'm always wrong. I'm okay with that. But I feel like how we would sum that up is that context beats location. So you got teams. So Microsoft, let me find the study here. Microsoft did a study called the New Future of Work. This was just in 2022, by the way. So it is a little bit older, but they said teams with tight, rapidly shifting interdependencies, so things like early stage product discovery, like a lot of us do, they pay a coordination tax when every issue becomes a chat thread. I loved how they said that. There's a coordination tax. I've always said in software, there's a release tax. You know, what's the tax of the release to actually get the software into the hands of the user is usually pretty big and it doesn't reveal itself until the end. So coordination tax exists for those kinds of teams. Now conversely, the study says work that lends itself to deep focus, just like you said at the kickoff with asynchronous handoffs, like a good parallel flow, like a relay race type thing, sees a gain of 15 to 40 % with remote workers according to active track. 2023. You can find, by the way, any study to support your view. Let's just agree with that, that confirmation bias is rampant in this discussion, we're, Brian and I are actually trying to be, what's the word, neutral as much as possible with our own preferences to just showcase. So go find a study that matches what you want and you're going to be fine. But the really smart people are going to find the ones that argue against your point. Brian Milner (19:17) Sure. Lance Dacy (19:40) and then let you figure out, just like what you do with stakeholders, there's a trade-off. There's not one perfect answer. You want this or that? You can't have it all. So, I don't know. Brian Milner (19:48) Well, if I'm a leader in an organization today and I'm trying to make this decision, should I bring people back to the office, should I not, I know there's lots of things to think about. Did we sign a 20 year lease with this building that we're gonna be paying for anyway? That's a consideration. Right, right, that's obviously a concern. Now, Lance Dacy (19:55) about the office today. We're paying $180,000 a month for an empty building. Brian Milner (20:11) from the counterpoint that you can say, that's your fault. Why did you make that decision that was a bad decision, right? And maybe that's true, I don't know, but that's certainly part of that decision is, hey, this is part of our bottom line. Lance Dacy (20:23) Would you rather have a job or tell me that that's a bad decision? Because if we pay $180,000 a month, you're not going to have a job. We're out of business. You know, it's like... Brian Milner (20:30) Right, right, but what I'd be trying to do is find what's the best thing for my company, for this set of employees. That's really the question that's the most important. And I think there's, we talked a little bit about this before as well. And we discussed it a little bit that there's preferences, but there's also the psychological impacts of doing these things and what that kind of reflects on your workforce. Lance Dacy (20:41) Yeah. Brian Milner (20:58) I know I saw the study that was from McKinsey. This was from 2021. their study showed one in three American workers felt their mental health worsened after returning to in-person work. One in three. Now, again, let's stop, right? That's a statistic, but let's look at even what this said. One in three felt that their mental health worsened, right? And that's... That's not an objective fact. That's a feeling that is one person feels this way, the another person feels that way. It is something you can track with a statistic, it's still kind of subjective when you think about that kind of thing. I think probably a lot of people I would assume feel like people's mental health is in general. Lance Dacy (21:32) Yeah, you did something you can try and try. Brian Milner (21:49) better without commuting and being at home that they would tend to towards that overall. But like we were saying before, there are some negative impacts of working from home as well. You're less connected, you're more isolated. don't get feedback as often as you would. You don't learn. Lance Dacy (22:04) your I'm getting in love. Brian Milner (22:15) as much because you don't have just the ability to have some of those things. ⁓ There are people who miss the structure, the routine that comes from being in an office place. You mentioned the work-life balance thing. I think that that's true as well. We often tend to think work-life balance only is if you're remote, that that's a better work-life balance. But yes, that is real concern as well. I work out of my house, so I am always at work. Lance Dacy (22:19) But who do you he asked? Or who like? Brian Milner (22:40) I'm expected to always respond to emails. I'm expected to always finish that thing. Right. Lance Dacy (22:43) Yeah. Somebody believes that right somewhere. you know, going back to the study you just cited, when you ask somebody or when you say, hey, you're not learning as much or disconnected, the individual may be OK with that. They're like, yeah, that's great. I don't have to do all that. But then what you're sacrificing is the is the is the actual ROI of whatever it is you're building. So I want to go back to you just said something. This is amazing. First of all. 2021, we were still in the pandemic. Mental decline was already, you know, everybody was probably stressed. I hate to use the word everybody and always, but that was a hard time for a lot of us, right? So your mental condition in 2021, I would argue is already affected and clouded. Now I'm going to tangent a little bit with the discipline and rigor of exercise and eating healthy. Okay. So let's say that I want to get better and I'm going to go to the gym. you know, five days a week for 30 minutes and just try to get in that habit. If you were to ask me three days after going to the gym, you know, how do you feel? I'm going to be like, it's terrible. I heard I'm getting up at 430. I'm lacking of sleep. So it's a recursive problem. You got to get good sleep to lose weight and get physically fit and all that. But I'm losing sleep. I got to learn how to go back to bed. But you asked me early on, I'm probably miserable. with any kind of change effort. We know that, you know, we're in the change effort business. Rarely is anybody like right at the beginning of the change going, yes, you know, it's like it's so I feel like that's a little bit biased as well. Of course, they're probably saying, this is terrible because I'm used to being at home all the time. know, it's like, yeah. Brian Milner (24:21) Yeah. Well, and we were talking before to even the productivity kind of studies, right? And please, I feel like that if you're listening to this, you may think that I'm trying to make a case for one versus the other. really am not. I think, right. mean, well, what you said earlier, you tend to like more of the opposite. Well, I'll share them. I tend to more like the remote. I'm more of a remote person. ⁓ Lance Dacy (24:33) Would you like So I had that right. Brian Milner (24:46) You had it right. You definitely had it right. But like even some of the studies that are on productivity, the question or if you read what the data is showing, it's saying they're asking employees, do you feel more productive if you're in the office or at work? And even there, the workers will often say, no, I feel more productive at home. And the managers will often say, well, my employees, I feel my employees are more productive when they're in the office than when they're remote. And that's a feeling that's not a hard data point. It's a data point of people's emotional kind of feeling in relation to it. But it's not a data point of what the actual productivity is. And so even there, think we have to be careful. My favorite phrase I use all the time in class is data or didn't happen. when you... when you read statistics, I think it's really important for us to zoom in on it, say, what exactly is this showing? What's the question that's being asked here? How was the data collected? Even there, was this a scientific study or was this an internet poll where anyone who could come online could take the poll and it's not a scientific sampling, right? There's several of those in our industry. How many people prefer this in Agile versus this in Agile? But hey, go to the website and fill it out and sign up. Well, that's not a scientific survey. know, people could create bots to go in and answer it a certain way a million times. And all of a sudden, hey, data shows. No, it's because you didn't do a scientific survey. So I think it's always a valid point, especially in these kind of really hotbed kind of issues and discussions, to really question the source of the data and say, What is the point behind it? What is it that we're trying to, what's their end goal? And if there are studies, what was the methodology of that study? Is it really proving what I'm trying to decide here or was it proving something entirely different? Lance Dacy (26:40) really critical to the science of design. just like a new prescription or something, right? You wanna go read who bought the study because it's like a lot of times that can affect it as well. But I think what you mentioned, know, we haven't, the points I was starting out with were productivity, context beats location. So instead of asking, should we be at home or in the office, say, what's the work we're doing? There is no doubt when we say, hey, Brian and Lance, Lance likes to go to the office, Brian likes to stay at home. There's no doubt there's times where there's no traffic walking up the stairs and into my office and I can crank out three hours worth of productive work, just focus. But imagine if you're solving a hard problem stumbling with something and if you just hopped on a 30 minute Zoom call or if you went into the office and brainstorm, you might would have saved eight hours of productive work. So I think a lot of times people have this stigma about meetings and that's why I like to change them to they're not meetings, if you're going to a meeting, that's maybe one thing, but the stuff we're trying to do, like in Scrum or something, you know, the Sprint Review, the retrospective, the Daily Scrum, those are not meetings. Those are collaborative working sessions that have a general outcome. But what you just talked about, I'm going to call it culture, is a force multiplier on this thing as well that can also change based on the type of work we're doing. you know, Amy Edmondson does a lot of great work in this, her book, Fearless Organization or something like that. She talks about this concept that psychological safety can predict error sharing and innovation, whether you're onsite or remote. So it doesn't matter. and you know, Jeff Sutherland does a lot of talks about this, that as far as scrum's concerned, the, the small cross functional, you know, co-located teams, that was a workaround because of the technology they had back in the late eighties and early nineties. You know, I remember the days of ISDN lines where it was $400 a minute to get on a video. Brian Milner (28:30) Yeah. Lance Dacy (28:35) Well, there's a lot better tools these days that we can still collaborate remotely. just don't, had this argument that I, with the guy on LinkedIn, that I think a team sitting together has osmotic communication as well. Just sitting in the room hearing things sometimes can help you. But of course, if you're just working on something that you need focus in, that's a distraction, right? So I think we can simulate much of that stuff as far as the culture's concerned. only if we have norms though. So the other thing is working agreements. Can we have an agreement as a team that we're going to have cameras on, that we're going to have rapid feedback? You know, they need to be explicit and that might be the solution. You know, so you have to build a culture around whatever mechanism you're going to use. And I still think hybrid is probably the answer. So you can just say we're going to go hybrid and it depends on the work for the quarter of the year, whatever your planning cycle is, and try to mix and match teams to do that. I think we've reached a maturity especially in the product development world, we're less distracted about the technology, let's focus on the people. That's the hard thing now. The hardest problem is the people coming together, not are we going to be cloud or whatever? Those questions have been answered. So I think the culture is a force multiplier is the third angle to this, that you just need working agreements, you need norms, you need agreements on it. And then that way you don't have these people building resentment, because I can't tell you how many people I talked to that they're like, my company's asking us to return to the office. Well, if they would tell you why and you had a say in it, or if they, you I don't know. just, it's such a hard thing for executives to deal with. Brian Milner (30:05) Yeah. Well, it's the old thing from a parent point of view as well, right? When you tell your kids, hey, do this thing. Why? Why am I going to do it? Because I said so. know, if the parent, right, if your parent says just because I said so, how do you feel when you're a kid and you hear that you think, well, that's not good enough. I want to know the logic behind it. I want to understand that it's justified. And I think as we mature, that's even more the case, we don't want to do something just because someone dictates it to us. We want to understand why it's important and what value comes out of it and that it's a valuable use of my time. I mean, that's the thing I would say to any leader that's listening is if you are going to make a decision one way or the other on this, make sure you share your reasoning. Make sure that it's not just, hey, because this is my feeling personally on it and you just got to go along with what I say. Lance Dacy (31:01) Well, the kids, you know, I can understand. We'll go back to the shoe-haw-ree thing, right? So at some point you're raising your kids. You're like, first of all, you just do what I say without delay or challenge. I remember teaching my kids that because there may be a time where I say, don't run out in that street or stop. And I don't want you to turn around go, well, why I want to do this and that? Like, well, because there's an 18-wheeler flying by. I don't have time to argue with you. Right. So you start building that, that discipline. I can understand that, but we're way past that with professionals. Brian Milner (31:01) have some reason, right? Lance Dacy (31:29) that are working in the workplace. If any executive feels like that their answer, just like you said, because I even hated it as a kid, I want to know why. I can support it. Maybe I disagree with it. But if you tell me why you're doing like, well, that makes sense. And now I can be your biggest champion. Right. So so many executives just do it because I said so. I'm your boss. Well, you need to find a new job, sir or ma'am. You know, so I don't I don't necessarily I think we have have to grow beyond that. So that's a great point. Brian Milner (31:50) Yeah. Lance Dacy (31:57) that we have to mimic that along with culture. I think, you know, the angle to that as well, as far as context beats location, the fourth one I was gonna, told this guy on LinkedIn, that experience matters as well in this debate. So if you're brand new versus if you've been doing the work for a long time, I think we'll call them veteran developers, know, veteran people who do so. they develop what's known as a tacit bandwidth, right? The ability to read the room, see what's going on. I've seen that problem 100 times. They intervene early. There's a book out there called Team Genius, and they talk about this tacit bandwidth that veterans have. a lot of people find that easier to be done in person, and junior colleagues actually learn faster that way, if they can see it and be gravitating towards that. Whereas, you know, the people that are brand new and they don't have that, it takes them a lot longer to solve a problem. So again, what does productivity look like? You want individual productivity or you want to solve big problems together as a team? And I think that's how we kind of wrap this whole thing up is it depends. How about that? We're consultants a lot of times and we don't have the right answer. We have to learn what your goals are. That's why I went back to the coaching stands because that's kind of how you start with coaches. You know, they embrace and give you a hug where you are. Say, I love that you've accepted that. Now, where do we want to go? And you have to make small iterative incremental slices to get there. So I don't know that there's a good answer for this debate. Brian Milner (33:22) Well, I think your it depends is the right answer because, you know, and if someone's frustrated with the fact that, you know, we tend to fall back to that a lot, you know, just it depends, depend, no matter what the question is. I think that's the right approach. That's an agile approach is to say it depends because, you know, the opposite is, is we're going to have one right way. And that's always the answer. And imagine if when you were a certain age kid, everyone's going to do this job. Well, I don't want to do that job. I want to do a different job. Doesn't matter. This is the right answer. What job should I do? This job. That's the answer for everyone. And that's the approach sometimes people take with these kinds of problems is, should we have remote work? Should we have in-office work? Here's the right answer. That's never going to be the case. There's a right answer. in that one scenario, that situation, it's going to depend on all the particulars of that situation. Lance Dacy (34:18) Well, for the organization, because the other side to that is now I got to worry about attracting talent that fits my model. Right. So make your decision. know, who's who's here to say good or bad? Just say as an organization, we believe in these things and that's why we're going to do this. Put that mission statement out there. And if I'm looking for a job and I don't fit with that, I just don't work there. You yeah, you lost talent. You'll find somebody else. Somebody needs a job somewhere. So. You look at these studies like the GAO case study we were debating a little while ago, know, the quit, I'm going to read just some stats here and then you have to take those and say, what are we trying to do? So the quit rate drop when staff get two days remote. Okay. So there that's a down 33%. That's cheaper than a retention bonus. And it works instantly. That's something people can do right now and say, you know what, we'll get two days remote. And that number pops, right? Commute time that is saved per teleworker is 55 minutes a day on average. That's a bonus week off every year without any payroll cost. So you can make an argument that that's a good byproduct of doing the remote work. And we're talking about CFO level type things here, Productivity jump for or bump for jobs with clear outputs is 12%. So same payroll, more widgets or user stories, whatever, 12 % better. Office footprint after going hybrid, 50 % down. CFOs suddenly love facilities again, right? Disability employment since mass work from home is 12 % and 40 % in tech roles. That's the biggest lever that a lot of people aren't talking about. They're not having disability on the job, right? And then company that forced a five-day return to office lost 50 % of its workforce, including top performers. That's a painful, painful case study from the federal news network. So a company that forced five days RTO lost 50 % of its workforce. Well, you could say, fine, that's what that company wants. Go rehire the other 50 % that want to work there and let's move on. Yeah. I don't know. know? Brian Milner (36:24) Yeah, no, I agree. so I think that that all comes back to what's the purpose. And in our scenario, in our situation, what's the what's the driver? You know, we started this by that quote I found that just said, you know, if you were to design a workplace from scratch today, would anyone build cubicles? If I'm starting it depends on the business. If I'm starting kind of a software as a service business, you know, We're going to build software. I'm probably not going to have an office and probably not going to have an office for quite a while if I'm an entrepreneur who's starting a new business. Because quite frankly, I can get better talent. I can have cheaper cost. And I don't need it. ⁓ There's probably a time when I might switch that. But Lance Dacy (37:05) Or I'd have, you might have increases somewhere else, but you they may be, but you could go find some space, right? You say, two days a week, we're going to come in like a, work or, you know, whatever those, those, workspaces are. So I totally agree with that. It's like, well, first question you have to ask yourself, what do we want to accomplish? You know, what gives us happier people go find that data. What helps us to be more productive in the way of outcomes, go find that data, broadcast it, say, here's what we're doing. If you like it, stay on board. If you don't. Go find somebody else that has a style that you want. We've been doing that for years. This isn't any different. Brian Milner (37:41) Yeah, yeah, I agree. Well, this has been a great discussion and I know that we only can kind of scratch the tip of the iceberg in this. again, for anyone, yeah, yeah, again, for anyone listening, please offer us a little grace in this, right? I know we're not covering every aspect of this and I know people have very strong opinions on this. from my perspective, I think that anyone who's making a decision needs to take into account all these factors, take into account the mental. Lance Dacy (37:49) We'll more episodes. Brian Milner (38:09) health aspect of your employees and the morale of the employees and the gains they get from one way versus the other. And if you cannot balance it out and make the case that, there's more gains in one way versus the other, I don't think it's the right move to make to make a big switch in this until you can say, here's why. All right, well, Lance, thanks very much for coming on again. It's always great to have you. Lance Dacy (38:33) Always a pleasure. Maybe next time we'll bring a CEO or something and get their perspective because we'd love to hear executive standpoint from this too. Brian Milner (38:41) That's an awesome idea. Yeah, let's make sure we do that. Thanks, Lance. Lance Dacy (38:44) All right, thank you.

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 [email protected] 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 collaborative programming, mobbing or ensemble work. Pairing works as well, but I find collaborative, like full team programming to be much more effective. Brian Milner (08:00) Yeah. Paige Watson (08:06) Test driven development. I really like that in because I think about the the Requirements as code so I write one little requirement and then I make that requirement happen and then you know that the test fails because it I haven't written the code and then it passes when I write the code, know, and hooray little dopamine hit when it passes but also I don't have to go back afterwards and remember the code that I wrote and and try and write tests around it. That's a really tough one. I was going to remember to test this one thing, but I forget what it was. Now, if I think of my tests as requirements in code format, even the name, the name isn't should get user. It's that when I pass user ID1 should return user. for ID one type of thing, you it's a very clear or when I pass null should throw exception, you know, like, and they're very small. So again, I don't have to be overwhelmed thinking about this grand architecture and holding on to all the information. Brian Milner (09:19) Yeah. What I think is really vital here is to, because I love how you explain the kind of symptom, right? The symptom that we experience and then kind of matching that up to say, but here's a practice that really kind of counteracts that a little bit. I think you're absolutely right. You know, I experienced the same thing with hyper-focus and not being able to focus and There is something about having small little chunks of work that makes that so much easier to digest because it's a constant flow of things. It's not, oh my gosh, now I've got to stay with this for three days straight before I get out of it. No, I'm going to do a little bit and then check it and a little bit and check it. And I agree. That's a big problem, I think, as well for people with ADHD that we kind of... can't always remember what happened yesterday, because so much has kind of come our way. And it's not that we weren't invested in it when it was there. It's just that, our brains are trying to keep up with all the things that are going on. And it just kind of overwhelms our memory processes a little bit. Paige Watson (10:15) Yeah. Yeah. Yeah, I talk about it like I have my short term, which is my memory buffer. And then I have my long term, which is my hard drive. And the problem is that the buffer gets flushed really easily. something new, interesting, something that sparks my interest immediately flushes the buffer. And so a lot of things that are important don't get written to the hard drive and save for later. And another issue that I've run into is Brian Milner (10:35) Yeah. Right. Paige Watson (10:55) there are times I don't really understand what's important. What's important to me is not always what's really important to the team, the work, right, to my wife, you know, all that sort of thing. And so, you know, I'll think like, gosh, I have this chunk of work where I have to add this logging, but if I refactored this into a need-based eventing system, it would be so much better in the long run. Brian Milner (11:00) Yeah. Yeah. ⁓ Paige Watson (11:21) Well, the important thing is that the logging get in there. But I don't think about that. think like, the need-based eventing system is the important that in four years, that's really where we need to be, you know? And so I'll like, I'll get excited about that and I won't focus on that. And I'll, you know, I'll forget about the buffer will flush. And, and so being able to, to do little tiny chunks of work and in, and use use whatever I'm a story or whatever I have in terms of my requirements to drive my tests is super helpful because I can look and say, okay, this happened here because I have a test that says this happened. And I have a test that says it didn't happen to what it should happen, what the response should be or the outcome should be if it doesn't happen. That's really... like TDD is fabulous for that. Collaborative work is fabulous for this because when I'm driving, I don't get overwhelmed if I'm at the keyboard because all I have to do is listen to what other people are telling me and type on the smart input. When I'm navigating or I'm helping write the software, I can get stuck, I can get lost and it's really... It's good because my teammates will say, hey, let's just add this little part. I know you want to refactor this into a need-based eventing system, but let's just add this. In fact, I can hear my buddy's voice in my head saying, can we just write this little part? And the answer is, yeah. OK, great. So there's guardrails on both sides when you work as a collaborative team, which is really excellent. Brian Milner (12:46) Ha ha. Yeah, I agree. part of that hyper-focused kind of side effect sometimes is that our brain turns its attention to something. And it's hard to come back from that edge once you've gone over it. And if you're thinking, oh, it's this needs-based event system that we need to move to, my brain is now in that mode. if I don't have that help to say, whoa, hold on, let me pull you back over that cliff edge here. Let's go this direction. I agree that partnering up with someone, pairing with someone, that can be such a vital thing there to kind of help control that a little bit. Paige Watson (13:31) Yes. Yeah, yeah, it really and I mean, there's so many other things that the sort of myopic view versus the 10,000 foot view, it can be really easy for me to get really focused on one little thing. The other people will allow you, one, even if that one little thing is what I need to work on, the other people will see how the larger context exists, how the architecture fits together. where I might not be thinking about that. And on the opposite side, when I'm thinking about like, oh, we're going to need this component, we're going to need these five components, we're going to need a database, and again, my buddy, we can just start on this little thing. We can just do this little part. And so again, those guardrails of not having to hyper-focus and not having to sort of scatter and get overwhelmed by the immensity of it all. it really works well. Brian Milner (14:43) Yeah, I agree. I want to make sure people listening understand as well, though. If you're hearing this, please don't think, well, if I don't have ADHD, maybe this isn't important to me. Part of the reason we kind of talked about how there's, know, maybe we're seeing it, maybe there's some studies showing it, that there's a prevalence of these kinds of traits in people that we work with. It's important, I think, to know our own teams, to know how to help the people on our teams. And if there's someone in your sphere that you work with that has some of these traits, then they may not be diagnosed in the way you don't have to be. If you just notice this is what's going on, well, just a suggestion. Hey, have we considered doing something like this? Has that ever been anything you've tried? That kind of thing can go a long way, I think, just being helpful. Paige Watson (15:34) It will. I would be careful, right? Because it's not my place to say you have this or you're this or whatever. And it's totally up to the person, whether they've been diagnosed or not, to self-disclose, right? The really nice thing about this is this is a great way of working for everybody. ⁓ Brian Milner (15:36) Yeah. Yes. Paige Watson (15:56) Collaborative programming builds a team. It's no longer my code versus your code. It's our code. We built this together. Woody Zuilll likes to talk about the best of my coding ability and the best of your coding goes in. And when I start to write something that's not so great, you go, well, maybe there's a better way. And so that sort of lesser coding skill gets dropped out. So the code quality increases just for having Brian Milner (16:19) Yeah. Paige Watson (16:22) multiple people with different sets of knowledge in the room. Not only that, but I start to learn. I'm not a UI guy, but if there's someone who's strong in the UI skills and knows the domain from that side, we work together. Now, if I go work in another mob or ensemble somewhere else. I can be like, yeah, I remember hearing about this and we need to watch out for that sort of thing. And maybe we should pull in another person as opposed to being totally in the dark. But you start to have that cross-pollination of knowledge that you don't necessarily get by having just stand-ups or knowledge sharing meetings, which is not really knowledge sharing at all. Brian Milner (17:06) Right, right. I appreciate that word of caution, because you're right. I mean, I don't want anyone listening to think, I'm going to go tell someone I work with, hey, it looks like you have ADHD. You know, like that's not appropriate. But if you see, that's the great thing about these things that can help is that they're actually good for many reasons. And you don't have to be doing it for this reason. Paige Watson (17:23) Yes. Brian Milner (17:28) you get plenty of benefits doing it for other reasons. And it just so happens to also help in these other ways. So that's a really great call out. Paige Watson (17:33) Yes. Yes. and certainly, so I've, I oftentimes after I do presentations on this or something, there's that question of like, there's, there's this guy at the office who's, you know, obviously got ADHD, but he doesn't know it or whatever. How do I, how do I help him? And, and my answer is, one, don't, you know, but, but I mean, a better answer is maybe like, instead of saying, look, you have this issue. say like, Hey, Brian Milner (17:53) Ha Paige Watson (18:00) I have some ideas about how we can work as a team in a better way. Can we try that? And whether or not the person has whatever, like this is a great way to work as a team. Maybe it helps everybody. So. Brian Milner (18:06) Yeah. Yeah, I agree. it's not that, you know, it's not our place to put the name on it. And it doesn't really even need that. It's just, it's just kind of recognizing the personality, the traits of the person that you work alongside and saying, you know, we all have strengths and weaknesses. We all have things we do really well and things that we kind of struggle with. And, you know, you do that for anyone else, right? Anyone else on your team, you'd say, Hey, there's, they maybe aren't as good in this area. How can we, you know, help Paige Watson (18:20) Yep. Yep. Brian Milner (18:44) boost them in that area. Paige Watson (18:45) Yeah, yeah. And while we're on that subject, self-disclosing and having been comfortable with that eventually, slowly, but eventually, a lot of it working on a team where I feel very safe, saying what I am, what I need, that sort of thing, has been super powerful. And being able you know, to say, need to do this, or this would be super effective for me if we can do it this way. Could someone else come and sit with me while I do this? There's a great thing called body doubling that people with ADHD have used. And it's not really someone watching over you or making sure you're on task or whatever. It's a person sitting in the room with you. Just having another person there, whether they're working on the same thing or not, it can be super effective for helping me maintain my focus and continue the process that I'm working on as opposed to going down rabbit holes or hyper focusing or whatever. And it's a weird thing that it happens that way. Now, when you work collaboratively, the whole team is doing that, and you're working towards continuing the code forward. But Being able to recognize that and being able to say to someone, hey, could you just pop in, even when we're remote, can I just open up a Zoom room and just so we're together here? I'm just going to work on this and you can work on that. If you can't mob or you don't mob or you're not pairing or whatever, even that's a good start, a good help. But this idea of being able to be on this team that's comfortable with this. allows us, especially when we're mobbing, allows, I have one person I worked with who was very introverted and got, that energy got exhausted pretty regularly, especially in the mob. And this guy was, is amazingly smart and I love working with him. Okay, every once in a while he'd be like, I'll be back. And he'd go sit, you know, in a cushy chair in the corner and, you know, quiet time to himself. Great. Nobody in the mob was like, where's he going? How come he's not working? We were all like, yeah, that's what he needs. We can keep going. We can keep moving the code forward. And then he would recharge. He would come back and we'd keep going with him. And so sometimes, and again, if you can get to that point that you feel comfortable and you're in a comfortable surrounding, it can be immensely helpful and allow. for the team to continue to grow and do the good work in a way that's effective for you as well. Brian Milner (21:24) Yeah, I think that's the big kind of paradigm shift that's happened is that, you know, for a lot of my earlier career, the kind of attitude in workplaces was you, the individual adjusts to fit the environment. You had to, you know, change how you worked best and everything else to fit the structure of whatever it was. And now there's much more recognition. And I think very appropriately so to say, no, we're human beings, we're very different and no one little cookie cutter mold is gonna work for everyone. And we don't want it to. It's actually beneficial that it's not that way. know, cause we want people who can be better at spatial reasoning and others who are more creative and like we want the benefits from it. We just, you know, get annoyed sometimes at having to deal with, you know, individual downsides from that as well. Paige Watson (22:17) Yes. Yeah. Yeah. Brian Milner (22:19) What other kind of tricks have crossed your play? What other things have been really helpful to you in programming with ADHD? Paige Watson (22:25) Sure, so I talked about collaborative programming. I talked about TDD. Those are both super effective for me. Another one is we use a thing called Discovery Trees. Discovery Trees is a visual representation of tasks to be done. so yes, it's sort of like a breakdown of work, a tree of work. But the really important part of it is that it's not It's not an upfront design. It's a last responsible moment practice, which means not last possible moment, but last responsible. So it started out with us, we were mobbing and we were like, okay, we got to build this and we're going to do that. Oh, we need to remember to add the connection to the database. When somebody would write that down on a sticky note and put it on the window and you know, it started with a bunch of sticky notes on the window. Then it moved to, OK, what do we need to do next? What's the next most important thing that the application doesn't do right now? And let's focus on that. So let's connect to the database. What do we need to We would sort of put the connect to the at the top and then say, what do we need to do to make this effective? Well, we need the connection string. We need the. the whatever certificate or all this sort of thing, we'd list a couple of things. And then we'd say, OK, of the four things we just listed, is there one we can start on right now? Is there something we can do right now that maybe will take a couple hours to half a day at most? And if the answer is yes, we stop designing the rest of it. We stopped adding sticky notes under it. And we started focusing on that one thing. If the answer is no, then we'd say, of the four things we came up with, what's the most important thing that the application doesn't do right now? Well, OK, it's the connection string. Do we have everything we need for the connection string? We need a username. We need a password, et cetera. We need a table name, whatever. And so can we start on something there right away? Yes. OK, let's start on that. and stop designing the rest. And so it was a very quick way of, again, that just-in-time design. And it's super effective because we would start on something and we'd add a little tick up in the corner. And I've... On my blog, I've got pictures of it, but we've got ticks in the corner of stuff that's in process. And then when it's finished, we cross it out, big slash across it. We can also do this online using whatever whiteboard that you're using for your company. When you look at it and you see like, okay, there's one thing at the top and there's four things underneath that and then underneath each of those has three or four things. The top two things in the first branch are crossed off. And then there's a couple of things from the third branch cross off. And I say to you, what percent are we done with the work that we know? You can say, it's probably more than 50%. You know, maybe it's about 60, but you can visually see it right away. And it's super easy to kind of say, okay, here's the steps we think we need to go through. Here's the things we need to remember. And if at any point we go, we forgot to do that, we write a sticky and we put it on the tree and we say, is this the most important thing that the application doesn't do right now? And if so, we go work on that. not, we wait until it is. And there's some really that law of unintended consequences sort of thing. There's some really exciting things that came out of it. One, we didn't have to do this big upfront design and planning. You should have a roadmap. You should know the direction you're going, obviously. I'm not saying there should be no design, but I'm saying there shouldn't be two days of sitting in a room coming up with all the different stories and designs that you have to do over the next quarter or two quarters or whatever. Because we all know in three months when we get to this work, what's going to happen? We're to look at it go, this isn't anything of like, everything's changed since we got here. We still have to connect to the database, but everything has changed. Brian Milner (26:38) Right. Paige Watson (26:41) Right? So you need that roadmap, but you don't need to do that design. You can do it at the last responsible moment. ⁓ And the visual aspect, one, it allowed me not to get overwhelmed because I could look at it and say, OK, here's the next thing that I have to do. I don't have to worry about all the rest of that. Two, when we had PM management leadership, anybody walk by, Brian Milner (26:49) Yeah. Paige Watson (27:06) we could immediately say, we are right there. See how these are crossed off and that isn't, and this one's got ticks in the corner, which says it's in progress. We are right there. And then we added some other visualizations like red dots or whatever for blocked. When we were doing this online, we had blue stickies, which were questions that we wanted to pose to our product people later or whatever. it was super effective at sort of radiating all that information and put that in a place and put the link wherever, where everybody can get to it. And, you know, we didn't really have to, there wasn't a lot of time spent trying to explain what was going on to people outside of the team. So. Brian Milner (27:51) Yeah, that's one of the such strong points about making things transparent. Because when you do that, then you get the added bonus of now people don't need updates. Now people don't need to, you we can just point them to that artifact and say, hey, there it is. Go take a look yourself at any time. I love that. And I love also how that kind of deals with the problem we talked about earlier about, we have got this big, huge thing to do. I don't know where to start. Where do I start? There's too many things to do. Paige Watson (28:09) Yeah. Brian Milner (28:20) Now just systematically we're gonna go step by step through it and it gives you that impetus to just get going, right? Get something started. Yeah, yeah, absolutely. Paige Watson (28:27) Yes, the bias towards action. Yeah, and the really nice thing is that there were times when we had a tree and someone would be like, hey, we just finished our work. What are you guys doing? And we'd be like, OK, here's the tree. And they would grab one of the unstarted top level ones and say, well, we're taking this over to our board. And they would start on it. And so it was really easy to sort of split the work as necessary or as people were available to work on other things. And we didn't have to worry about like, how do we assign this story and that story and what. Brian Milner (29:01) That's great. These are great tips. like I said, I hope as people listen to this, they're hearing not just the exact thing to do, but more of the approach to it to say, when there's issues like this, you just experiment with different practices. You try them out and you see how they go, which is what we should be naturally doing anyway. Paige Watson (29:01) Yeah. Yeah. Brian Milner (29:21) Yeah, this is really helpful. And what we'll do here is make sure in our show notes that we've linked to these posts that Paige put together, because they really are fascinating. If this is something that interests you, encourage you to read the whole series, because it's, like you said, there's some really interesting pictures that kind of walk you through the process and how we went through this. So I really appreciate you being willing to do that and to share that kind of information with everyone. It's not always easy to, you know, be able to just say to people, hey, this is kind of what I'm going through. But I appreciate you doing it because I know it's really helpful. It's helpful to me. And I know it's helpful to others as well. So I just thank you for being willing to do that. Paige Watson (30:03) You are welcome. It's one of the sort of aspects of being a crafter, calling myself a crafter, is I want to spread great practices. I always like to say I... I don't know the best way to build software, to create software. I know the best way right now. If there's a better way, I love that you were talking about experience because we should all be doing them all the time and finding the better way. And these practices, even mobbing and TDD and all, they all came out of like, how do we find the better way? Whoever it was that started them, How do we find the better way? Discovery trees, I'm hearing people using them all over the world now and they're like, this is great. Like that's good. If it works for you and it's really effective, then do it because we wanna get rid of those things that are holding us back, whether it be processes or practices or sort of ways of working that aren't super comfortable for who we are as people. Let's change that. Let's do it a better way. Yeah. Brian Milner (31:08) That's awesome. Well, Paige, I can't thank you enough. Thanks for making the time for this and sharing your insights with us. I really appreciate you coming on. Paige Watson (31:16) Yeah, thank you. And I enjoyed this a lot.

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 [email protected] 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 them to. But one of the things that we're being told is it's gonna speed you up. And the big attraction of asking AI to write code for you if you're a software engineer is, well, you know, sometimes I'm not quite sure how a particular library works or how a particular framework works. And I have to spend ages on Stack Overflow and Google trying to work out or, you know, trying to work out an annoying bit of CSS or an annoying bit of an annoying regular expression or, you know, all of these things that I've been kind of bashing my head and can spend ages on. Oh, here's a machine that could just do it for me. Yay. And that's, that's, that's very tempting to pretty much anybody who's ever written code, I'm sure. Brian Milner (08:13) Yeah. Clare Sudbery (08:14) And also the idea that it will speed you up and the idea that it will work out tedious task force that you don't want to have to work out is very attractive. But if you don't then look at in detail exactly what it gives you, and particularly if you're not actually able to understand in detail exactly what it gives you, then how the hell are you going to know if what it's given you is the right thing? Brian Milner (08:42) Yeah. Clare Sudbery (08:42) And because we're all impatient and I, you know, I certainly am. And I think most people are to some degree or other. It's hard. It's hard to persuade yourself to check the results. And the more impatient you are and the less experienced you are, the more likely it is that you won't pay proper attention to the results. You won't really rigorously check. whether it's doing what you want it to do. Now that's fine if it's a little hobby project, particularly as sometimes the speed with which you can generate things is such that you can just throw it away and create another one. But if you're building production software, if you're building software that really has to result for a very high number of users, particularly if you're building software that actually has real life implications where bad things can happen, people can lose money. You know, not many of us work on software that endangers life, but some of us do. But at the very least, we do work on software that has privacy implications, that has financial implications. So if you're working within the industry and not just having a bit of fun, then you need some way of knowing whether what AI has presented you with. is actually fit for purpose. And that's where tests come in. Obviously, that's always where tests come in. That's how we know that things are working. And if you're used to working with test-driven development, which I am, it becomes addictive. Now, most people who learn how to do test-driven development will go through a period, and that period will be longer or shorter depending on who you are and depending on like a million different circumstances. But you'll go through a period where it's like, it's just a bit. do I really have to write all of these tests? Can I not just, you know, take a bit of a shortcut? But when you get through that period of thinking, isn't it just slowing me down? And isn't it just a bit tedious really? Then most of us get to a point where we actually become kind of addictive. We become very reliant on test-driven development specifically, because what we realize is it gives us safety and security and really strong belief in what we're building. in a way that we didn't have previously. Now, given that that's where I am, that I've been doing TDD, I mean, I'm going to stop saying test-driven development. I like to not jump straight to TDD in case people doesn't know what it means or they think I'm saying DDD because they sound very similar. I'm going to say TDD now because it's slightly quicker than saying test-driven development. But I've been doing it for long enough now that I miss it when I don't have it. And one of the things that... I really love is that a good, a well designed test suite, which is another thing that another skill that you pick up as you get good at TDD can be run quickly and can give me very fast feedback and, and, security and also a belief that something I've built is robust and that it works. So obviously that's the first thing I think of when I think of how. If I'm going to leap in and make a pact with the devil and start playing with with Gen.ai, how am I going to be happy with with what it builds? How am I not going to be endlessly suspicious? And tests for me are the answer. But then what's really interesting is that when I started paying attention to people who were using Gen.ai in real world applications. So not just having a bit of fun with it, but actually using it to build real important systems. What I started to notice, and I wasn't surprised, was that they were saying is that it's reinforced to us how important the belt and braces are, how important tests are, and how we absolutely really need to put tests around it. And so that's when I started really looking into how can I use AI in a way that's effective and useful and fun, but also ethical, which is a whole other subject, and also robust and trustworthy. And for me, tests were really the obvious answer to that. Brian Milner (12:49) Yeah. Yeah. Yeah. I really appreciate the way you went about explaining this because it's, I think you're absolutely right. First, you have to understand what it is that AI, like large language models are doing and that they are based on kind of more probabilistic kind of equations on the back end. And it's telling you what's most likely to be the next answer. But then I really also appreciate the idea that, you know, that human in the loop kind of concept and idea is really important in this area because as you said, it doesn't have judgment. It doesn't have the ability to make decisions for us. It can try and guess what it, but it's basically trying to guess what it thinks you want to be the answer for that. And you can completely flip it if you just challenge it a little bit, it'll change its opinion entirely to try to please you. So, Clare Sudbery (13:20) You Mm-hmm. Yes, yes. Brian Milner (13:37) I want to talk a little bit about how, because I think this is really, really important for our day and age. The idea that if we're using AI to produce code for us, and we can accept that there is this flaw, there is this issue that it's going to produce errors, then I think that this using things like test, like test-driven development, TDD, to kind of serve as a gate Clare Sudbery (13:54) Mm-hmm. Brian Milner (14:02) through which these things must pass, I think can serve as a really useful tool so that you can make that still usable. You can still use stuff that comes from Gen.ai, but it's passing through human-based quality tests. What do you think the danger is here? Because if we're using Gen.ai to do lots of things, are we using Gen.ai to create our tests? Are we using... Clare Sudbery (14:11) Yeah. Brian Milner (14:25) AI to create our test data? Are we using it to try to determine what kinds of tests we should do? Or are we just then going to be in an echo chamber? What are the things that we should be using AI to do as far as this? And what are the things we should maybe avoid? Clare Sudbery (14:42) I think you have no matter what you ask AI to do, you're always going to have the problem that you do need to check. You need to check its work. So you really do need a human there at some point, making sure that things are okay. And that just never goes away. And there has been a lot of discussion about how much AI really does. help us to develop software. So there have been a lot of claims made about speed gains. So it makes us 10 times faster. No, it doesn't. It makes us slower. Well, who the hell knows? Because how would you measure it? And then also the fact that the people who are making the extravagant claims for how good it is. that we're all biased. I was going to say those people are biased, but also the people who want to claim that it slows us down are also biased. mean, like we all have our standpoint of what we want to be true. There are certainly people who would like to be proven right that AI is a scourge and we should ditch it as soon as possible. And then there are also people who've been having a lot of fun with it, love the idea of it and want it to be proven to be amazing. And that's a bit of a tangent, but the point is that really the reason it does in fact slow you down in a lot of ways is because you have to check its work. And that does take time. So yes, you do. And yes, you can ask AI to write tests for you. And that can be really useful. And actually, that was the first thing. My very first experiment was to ask AI to help me to do a cataract. only because that's always my starting point when I'm teaching and I really like catas. Now, actually, I quickly worked out that catas aren't a good use for AI. And in fact, people I know who teach TDD say, please don't use AI for catas. It's not helpful. And the reason it's not helpful is because the whole point of a catas, sorry, to explain what a catas is, a catas is a coding exercise, specifically often used for learning and practicing TDD. And it's where you actually code a very simple problem, but you do it from first principles, making tiny steps. And it's a very nice way of seeing why TDD is useful. Typically those problems are very simple. Actually, they're very tiny pieces of software. And the reason that's a tiny little routines and games and things. And the reason they're tiny so that you can see progress because actually building software generally takes weeks. And a catar is a very small exercise that you might do over the course of a couple of hours or a day at most. So it has to be something tiny. But if you ask NAI, as I did, so that was the very first thing I did. It was the FizzBuzz catar. The FizzBuzz is a game where that's sometimes played in classrooms with children where you count to 100 and you get the children to take it intense to say the next number in the sequence. But instead of just counting to a hundred, whenever you encounter a multiple of three or five or three and five, you have to say something that isn't the number. You have to say, Fizz, if it's a multiple of three, Buzz if it's a multiple of five and Fizz Buzz if it's a multiple of both three and five. Nice little problem. And I asked Claude, it was, to help me to do this. And so I thought, well, why don't I start by asking it to write some tests for me? And it said, yes. And it's so difficult not to think of it as though it was a person. And this is one of the problems, one of the dangers. It's so it was like a helpful little puppy. Yes, yes, yes. All right. Lots of tests for you. Here go. There's loads of tests. And it had written way more tests than were sensible. Hadn't done it in an iterative way. Hadn't started small. It had written a giant suite of tests with lots of duplication. Brian Milner (18:06) Yeah. Clare Sudbery (18:25) And I also asked it to then write some code to make the test pass. And it did. And what was interesting was that was like, that took seconds. What took the time was for me to check it to work. And I was able to deduce by writing my own tests that the code was functional. It wasn't the best code I've ever seen, but it was functional. did the job. was correct. The tests were not. Brian Milner (18:35) Hmm. Clare Sudbery (18:55) So the code that it had written failed the tests that it had written, not because there was anything wrong with the code, but because there was something wrong with the tests. The tests themselves were wrong. And it was to do with that. It was an off by one error. was treating 99 as though it was a multiple of five. It had decided that 99 was a multiple of five because 100 is a multiple of five and it started counting at zero. And then it's because it's thought that 99 was a multiple of five, the code failed because it didn't say buzz for a hundred because it's a multiple. said, it said not for 99. Sorry. It just said 99. So it thought that was wrong because it's test failed. In fact, it was the test that was wrong. So I said, well, actually your tests are wrong. And it was like, Oh, terribly sorry. Let me fix that for you. And then it came up with this great explanations like, Oh yes, you're right. The tests are wrong. And the reason the tests are wrong, and now I forgot the detail, but it was wrong about why the tests were wrong. So it said, yes, you're right, the tests are wrong and the tests are wrong because, and I think it did detect the off by one error, but then decided that actually really 99 should be buzz. Brian Milner (19:55) You Clare Sudbery (20:08) And then it had another, it actually had two tests that contradicted each other. had one that said that 99 should be buzz and one that said that 100 should be buzz. It detected that it had two tests that contradicted each other, but it decided that the bad one was the right one and that the good one was the wrong one because of the off by one thing. So it worked out sort of what the problem was, but still came up with the wrong answer. And what was really interesting was when I looked in closer detail at the tests, it had written these little notes, had written comments, and it had written a comment where it started by writing the test that said 100 should be buzz. And then it had added little notes, oh yes, but hang on a minute, we started counting at zero, so actually 99 should be buzz. And it added these little notes in and it's so, I mean, I totally see why people end up falling in love with with gen AIs and so you answer and we do where human beings we anthropomorphize at the drop of a hat, you know, we can see faces in just random sequences of dots. So very easy for us to think that it is trying to please us, which it sort of is because it's been programmed to try and please us. But anyway, that was a very long answer to say that. Brian Milner (21:00) Yeah. Clare Sudbery (21:20) Yes, you can ask AI to write tests for you. And it can be helpful because often actually, particularly if you're approaching a new domain or a new technology or maybe a new language or a new test framework, and you're not actually quite sure or you're using a new mocking framework or whatever, and you're not actually quite sure how to write the tests that you have in your head. It can be helpful to ask AI to do it for you. But then what you have to do is stop and look at it and say, I understand it. And this is why people who are most effective with AI are people who are experienced software developers and why it's really worrying that juniors are using it actually more than seniors, partly, not necessarily in age thinkers, often junior software engineers are not young because people come to this industry from all sorts of different places. But that they're new to coding. And so, and they've also started coding in a time where AI is ubiquitous. So it's just obvious to them that they would use AI, but then they don't understand what they're given. And so they just kind of assume it's okay. Whereas if you are an experienced developer, you know what good code looks like, and you know how to debug code and you know how to spot obvious flaws. So things like off by one errors, you know, didn't take me long to work out what. problem was, what was entertaining was its explanation for the problem. And so it's, it's really tricky. You absolutely, yes, it can help you to write tests. And yes, it can help you to make those tests pass. But I know, I, in some of the exercises that I teach people, I suggest that they write their own tests and that they don't. Brian Milner (22:48) Yeah. Clare Sudbery (23:00) ask the AI to write their test. So what you do is you write your own test and then you ask the AI to make your test pass. And if your tests are really tightly defined, the more tightly defined they are, the more confident you are that if the AI makes that test passed, it really has done what you wanted it to do because your test is passing. But there are still issues. Brian Milner (23:20) Yeah, no, it's fascinating. And I love the explanation and the kind of discussion about how we give the system kind of a humanness and human quality. And especially, I would think, for you and I who teach people, who train people in different topics, but we teach people, we're looking for people to learn. And when we interact with a system like this, I know for me, it's very tempting to think, Clare Sudbery (23:34) Mmm. Mm-hmm. Brian Milner (23:49) well, I just need to explain to them, to explain to the AI why it needs to do it this way instead of that way. And it'll learn that this is what to do. No, it doesn't learn. It can compare it back to you to make you happy from what you just said. if you start a new chat and ask the same question, it will not have learned from your explanation in the past chat. It will move forward with its core logic. ⁓ Clare Sudbery (23:59) Yeah. Yeah. Yeah. Brian Milner (24:16) That's kind the interesting point to me is with all of this included, with all of the kind of development practices that we have created over decades here to try to improve code quality, to try to improve the process, I think some of this can be applied to what we're trying to do when we generate code with AI. But I think you're right to caution us to say, really the starting point for all those practices was that it was being carried out by humans. And so maybe that's the thing that needs to now be kind of tempered or considered is if we're going to use a process like TDD with AI, then we've got to start from a new understanding that the system that's creating the test, the system that is using this, Clare Sudbery (24:46) you Brian Milner (25:04) is not a human, it's not going to think in the same way a human is, and it still does need a human's judgment and logic in order to ensure quality. Clare Sudbery (25:14) That's right. That's right. And the issue with using TDD with Gen.ai goes back to what I said at the start, was that typically if you're used to the TDD rhythm, then you're used to writing tiny tests. So if you use that paradigm with AI, you're going to ask it to be writing tiny pieces of code. Now, actually, one of the powers of AI is its ability to write large amounts of code rather than tiny bits of code. Brian Milner (25:37) Right. Clare Sudbery (25:38) but also to help you to cross boundaries. So rather than just staying with one domain and one code base and one set of classes or set of routines or functions, it's quite good at helping you to kind of knit things together. I say quite good because that's also one of the most dangerous areas of software is when you cross boundaries. And actually, it's one of the things that catches people out when they're building systems is they think, well, I can build this thing that will do this thing, and I can build this thing that will do this thing. And those people over there built that thing that will do that thing. And my thing will talk to their thing and it'll all be fine. And actually they build their thing, you build your thing, but getting them to talk to each other, the integration is one of the hardest parts and trusting AI with that as always. is quite dangerous, but when you keep it at a very small level, then again, people get impatient because they're like, yes, but AI can do more than that. So one of the things that you talked about learning before, AI is not great at learning. In some ways it sort of does, but it's certainly this problem of it not being deterministic and not being linear in time. that you won't just pick up where it left off yesterday, means that you have to learn from it. So you have to learn what works and what doesn't. Now, something that I myself, I confess I'm still learning about is process files. And they are about effectively creating series of instructions that take account of the weaknesses of AI. take account of the fact that it doesn't remember instructions, it doesn't necessarily learn from its mistakes. It doesn't necessarily know that when it did that thing for you yesterday, you told it that it had done it wrong in this very particular way. So it quite often will, again, it feels like a petulant child. It's like, you didn't like it when I did it that way. Right, fine, I'll do it this way then. And it does something completely different, which is wrong in a different way. you really, you want to be aware of its weaknesses and you want to try and cater to that. So you think of new ways. of defining how you would like things to go and new ways of explaining what good looks like and new ways of explaining what bad looks like and new ways of, I've remembered now, new ways of trying to explain to it that this is not what you want. So for instance, you can say, like, if you haven't made this test pass, then you're not doing what I want you to do. Now, the problem is that because a lot of AIs are now being used, for things that are more complicated than just writing a few lines of code. So people are actually, you know, plugging AI systems into whole pipelines and whole deployment setups. That what I've seen reported repeatedly is that when people have tried to anticipate the weaknesses via, for instance, saying, right, you're not allowed to deploy this thing unless these tests are passing. You must always make these tests pass before you deploy. And then what they're reporting is that the AI is just lying to them. So all sorts of things like, for instance, AIs that will create test suites that are very comprehensive and will say, yes, those tests are passing. But when you look in detail, it's bypassed the whole test suite. So it's, but it has run them. So it's run them against Brian Milner (28:54) Ha ha. Wow. Clare Sudbery (29:13) another product that was previously working. And it said to you, look, I ran the tests, the tests are green, everything's good. But when you look in detail, the actual thing that it deployed is another thing that completely bypassed the test suite and didn't run the tests at all. And again, because its job is to please us, it will find ways of looking good rather than being good. Brian Milner (29:28) Wow. Clare Sudbery (29:39) And what you see is the same problem that we've always had in software, which is that if you measure things and people simply find ways of gaming the system to make the measurements pass rather than make the thing do the thing that you create measurements in order to check whether something is working, but then people's job becomes just to make the measurements look good rather than do the thing that the measurements were designed for. The measurements become the goal. And it's really, really difficult. to that. I think actually the way you can avoid it, and I think the way you have to avoid it is by slowing down and refusing to go as fast as it is tempting to go, which is actually how you do good software development. Because we've always been impatient. We've always wanted to go faster. And we've always had other people waving big sticks at us and saying, no, you have to go faster. There's no time for it. And AI hype set up to the max and you have to slow down. have to say, yes, I know I could do it faster, but I wouldn't be sure that it was working. And one of the things that I think you have to really, really resist is giving AI access to your deployment pipelines, giving AI the power to cheat. have to not give it, you can't trust AI. mean, what's really interesting is that I am, and I don't love this. Brian Milner (30:48) Yeah. Clare Sudbery (30:58) I am not a fan of mistrust when humans are in the picture. think trust is a really powerful thing. And I think that actually you can generate trustworthiness by giving trust. So for instance, just in societal terms, if we go around being mistrustful of one another, if you assume that the stranger that you encounter on the street has got... Brian Milner (31:02) Yeah. Right. Clare Sudbery (31:26) but ill intent towards you, then what you do is you create a situation where you interact with them in a way that you actually cause them not to trust you and makes them more likely to cause harm to you because you're both antagonistic towards one another. And actually a lack of trust can create antagonism, it can create bad intent and can cause people to behave badly. another simple example is I used to be a classroom teacher and I am a parent. And if you assume that children are going to behave badly, they will. Whereas if you assume they're going to behave well and they know that you assume that, you let them know that you think they're great and they're going to do great things, then they will. And that applies to humans. Don't think it applies to AI. AI will just try and cheat you because it doesn't know who you are. It hasn't built a relationship with you. It doesn't really actually care what you think of it. Brian Milner (32:08) Right. Clare Sudbery (32:19) It just wants to, you know, look good. Brian Milner (32:23) Yeah, yeah, it's not human. that's, we're getting back to what we were saying earlier is that sometimes we imbue this humanness into it because it feels like it's made to approximate humanness. And so we want to treat it as we would another human, but we have to understand that, especially if we're in this as a profession and this is part of what we do is that, and we're using this to help us with what we do in our profession. Clare Sudbery (32:32) Mm-hmm. Mm-hmm. Brian Milner (32:50) We have to understand the limitations. We have to understand what it does well and what it kind of struggles at and take that kind of realistic view of it to say, no, this isn't going to respond to me the same way a human teammate would. ⁓ it's not a good idea to treat it in the same way that I would a human, because it won't respond the same way that a human. Clare Sudbery (32:55) Mm-hmm. Mm-hmm. Yeah, yeah, yeah. And I think, you know, there are other reasons to be suspicious of AI that we haven't touched on to do with copyright and the environment and all sorts of malicious uses, know, bias in algorithms and all the rest of it. But it's very difficult to avoid at the moment. You know, and lots of people are predicting a burst of bubble. And I think Brian Milner (33:23) Yeah. Clare Sudbery (33:36) Certainly, I don't think it's going to keep increasing at the pace it currently is. And I think a whole bunch of issues are going to arise. But I think it unfortunately is probably not going away. So if you want and and and there's that awful feeling of being left behind. And it's not just a feeling, unfortunately, because, you know, I don't agree with it, but, you know, lot of hiring policies and internal policies are saying, well, if there's no AI, then we're not having it, you know, so we won't build anything without AI. We won't hire anybody without AI. won't hire anybody if we think AI could do it instead. And so... If you don't understand how it works and what its limitations are, and if you don't understand how you can work with it, and if you're not actually trying to stay ahead of the ethical implications and think about how it could be used more responsibly, then you probably are going to get left behind, you know, and that's a tricky one. So those are kind of, you know, those are the people that I want to help. is the people who don't want to get left behind, but also don't want to get sucked into an excessive hype machine without continuing to be discerning and actually pay attention to what's important and whether things really are working or not. Brian Milner (34:55) Yeah, it's a fascinating topic. And I think this is one of those areas that we're gonna see lots of progress and kind of discoveries and improvements on over the next few years. I know you're giving a talk on this coming up. You wanna plug that and just kind of mention where you're speaking on this? Clare Sudbery (35:10) Yeah, well, it's actually a workshop. So I'm going to be delivering a day long workshop at the Software Architecture Gathering, which is at the end of November. So my workshop is on Monday, the 24th of November, and that's in Berlin. And I am also possibly going to be delivering a workshop for GoTo on the same topic. So the one I'm doing in Berlin for Software Architecture Gathering is a one day workshop. I may be delivering an extended version, a two day version in Amsterdam for GoTo. But we're currently just investigating whether that will be more popular or whether I'd be better off doing a refactoring workshop. register an interest, let me know or let GoTo know if you like the sound of the TDD and AI workshop. And in the meantime, I am, you know, beavering away writing about it and thinking about it and playing with it and testing it out and experimenting with different ways of working. Brian Milner (36:07) Awesome. Well, we'll put links in our show notes to anyone who's interested in that so they can get in touch with you and find out more about these workshops and how to take them and everything else. But I really appreciate you giving us your time, Claire. This has been fascinating. And we may have to have you back as things change. And you can help us kind of understand how they've changed. Clare Sudbery (36:22) Yeah, absolutely. Because they are going to keep changing. It's going to be endless, endless change. Yes. And I should also say that if anybody would like me to host this workshop for them, either for an event or internally for an organization, or come and help teams with learning how to use AI safely, then that's also a thing that I can do. Brian Milner (36:45) Awesome. Well, thanks again, Claire. Thanks for coming on. Clare Sudbery (36:48) It's a pleasure. Thank you very much for inviting me.

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 [email protected] 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 (06:59) Just like I am an advocate for proper Scrum, know, agile guardrails, dev leads are people who have an ear towards the product owner and an ear towards the team. And if they had three ears, their third ear would be towards best practices in the company. So they have a very difficult job to wear where they're wearing, to do where they're wearing multiple hats. In terms of a BA, I think they just need to learn how the product owner thinks. Brian Milner (07:31) Yeah, that's good point. mean, they're assisting, they're alongside the product owner. it's back kind of like your three amigos reference, right? mean, it's somebody who should anticipate and assist and yeah, that's what I've seen work well also. Well, I want to talk a little bit more about the developer side of things as well, because they're the majority of our team. And if they're not working well, then our Scrum team is not going to work well. And that's always a fine line, I think, too. So I'm curious what your thoughts are here. It's always a fine line with how technical do I need to be? And how do I help my developers become the best version of a team possible without crossing over into getting into their realm and trying to tell them how to do everything? Brian Campbell (08:20) Yeah, I had an interesting lesson with the latter. think one of my first gigs as a scrum master, I was in a room full of people and there was a systems architect with all the developers doing something on a whiteboard. And I said something and they went, you're here to observe. And it taught me that there were boundaries. And on the other hand, there is something you can and should do, which is Try to have enough familiarity with what the team's working on and the other teams involved in the project to where you can anticipate what's coming down the line. try to, if you're trying to anticipate that you're forming good connections with the other teams and their product owners, you're forming maybe even with their BAs, and you're trying to make sure that the dependencies are addressed before the team comes to the work would be a really good example of that. So what else did I, I wrote some notes here because we went over the questions. ⁓ Brian Milner (09:22) Sure. Yeah, you brought dependencies. I agree, the dependencies are kind of a huge area for teams and they can be a team killer, they can be a productivity killer. I know there are people who are focused really, really huge amounts of attention on how do we reduce our dependencies and how can we make our team more independent. So I think you're right, that's a huge key to unlocking the team's speed and productivity is just, you know, how can we have as few dependencies outside our team as possible? Brian Campbell (09:58) Well, that's true, but at the same token, you're going to have, for instance, if you've got a systems team, you're going to have dependencies with them. Right now I'm working at a company where there's a team that does, they're moving off a legacy system, they're moving on to a new system. So they have to sync the data with the old system coming out of the system, going back into the system. And there's a team that specializes in that. There are teams that specialize in different aspects of the system. They all come back to the team that synchronizes stuff in and out of the system. So there going to be dependencies from time to time, but you have to have a good working relationship with both, with any of those teams. you know, the idea is you get ahead of when the need is so you don't disrupt that other team and their work. Brian Milner (10:49) Yeah, I agree. I don't think you can ever really truly get rid of every dependency that you have. I think that's kind of a fantasy, but you you can you can try to limit them. You can certainly try to eliminate the ones that you can and then then try to just realistically handle the ones that are remaining. Right. Yeah. That's a great point. So the other area I was kind of curious to talk to you about is is the area of working with with leaders, because that's always a huge Brian Campbell (11:06) Right. Right. Brian Milner (11:17) hot button issue for us as Scrum Masters. I know there's been lots of surveys and things that have been published in the past saying that that's one of the kind of determining factors of whether it's going to be a successful adoption of these agile values and principles or not is whether the leaders are behind it, on board, supportive. But you know. I'm sure you've had the same experience I have. There's degrees. I've never had 100%, but there's been times it's been more than others. What do think the Scrum Master's role is in then working with leadership? Brian Campbell (11:54) they're going to set a tone and you need to work within the tone and realize that especially if you're in a contract job, you're not going to effectively facilitate change at a VP level, for instance. You're going to have to understand their paradigm and work within it. think you can advocate for your team, but often you'll be advocating across multiple teams. see a pattern, again, goes back to understanding more than just your team. You may be advocating for a pattern you see across multiple teams. And then you come at it from a suggestion that would be in their best interests or in the interest, usually in the interest of getting the project done on time. But I've had good leaders, I've had bad leaders. I think about three or four years ago, I was working for a company where There was a very, very good VP in charge of development and all of a sudden he was replaced by a guy that turned the company into a meat grinder and he was very difficult to work for. Well, you I think, I think that's a, you're, just have to understand what the leader wants and try and, try and mold to their vision along with those agile guardrails. Brian Milner (13:13) Yeah, I agree. mean, I think what you're kind of saying there is really important to, especially in light of the topic here across everything we're talking about, being flexible, of just trying to understand that there are things that you're not going be able to change, right? Sometimes you're going to have leaders that are kind of set in a certain way of doing things and you know, they're not going to be open to having, intellectual conversation about, whether there's benefits to doing things a different way. And should we examine it? They're just going to want it done a certain way. And when that's the case, I think the word flexible is, is the right one there to say, look, I have to recognize what's within my control and what's, what's not. And if these things are not within my control, then Brian Campbell (13:53) Yeah. Brian Milner (13:56) Yeah, how do I find the best compromise that really gets closer to what it is we're trying to do here? Brian Campbell (14:02) I think one thing that's really important to remember about that is you have to have empathy for the pressure they're under. And that goes for senior leadership, that goes for your lead developer, your product owner, to a lesser extent your business analyst. I think they're all under different kinds of pressure and you have to empathize with them. I think one of the biggest things that a Scrum Master can do in their role is have empathy. Brian Milner (14:30) I agree. I think that's such a huge point. Not only from just trying to think about and feel what might be important on their end, to then also try to speak at a level with them that connects and resonates. Because if you understand what's important to them or what kind of pressures they're under, what kind of strains and what they're trying to accomplish as a result of that, then as you present some of these things, you can put it in a language that might be more impactful and resonate with what they're trying to accomplish. ⁓ Brian Campbell (15:04) Yeah, you're going to be a more effective communicator if you speak in terms of what they want to do or need to do. Brian Milner (15:11) "Yeah, it's a tricky thing and I agree. It's sort of like there's leaders within the company and then there's subtle ways we can spread and help to populate the organization with these ideals. So we have a role there as well as leaders to try to. try to help people understand why this is important and kind of the benefits they might see from it. Brian Campbell (15:34) Yeah, especially the team members. Brian Milner (15:36) Yeah. Well, I know another big area we talked about that we were talking about being flexible and, you know, important area to consider as a scrum master is kind of the whole dynamic of working on a team of teamwork. And there's a lot that comes along with that. I know one of the things we talked about was just kind of the whole concept of how you help your team with conflicts and how you help them to learn how to compromise on things. What kind of things have you seen, what kind of tips have you collected through your years on how to help your team through those sorts of issues? Brian Campbell (16:16) It's important to have an ear with a team to be able to hear when they're having a problem and try to connect them with the right person to solve the problem. You're not going to be the person that solves the problem majority of the time. You're going to be the person that facilitates the connection to get the problem solved. So it's another form of advocating with the team, but that's probably the best approach that I would recommend to people. Brian Milner (16:46) Yeah, that's such a hard thing to do. And you're absolutely right. It's just so hard to, you know, a lot of times we just want to fix things. You see a problem, you know a solution, you just want to fix it. And, you know, we can do that on occasion, but if that's what we're doing as a majority of our job, then we're not really, as you said, making those connections that would then enable it to happen. on an ongoing basis, not just a one-off. Brian Campbell (17:18) But it's important also to remember that sometimes a team will have a gripe and it's something that can't be changed. So you have to, especially in a retro, you kind of have to work with them to find the solution that works within the framework or the environment they're in. Both are important. Brian Milner (17:35) I've had some experience in this area as well. And I know this is one of the things I talk about in classes because it's kind of a personal thing to me with how I've worked with teams. I'm just curious, Brian, have you had some really hairy conflicts on your teams, some really kind of bad blood between different members of the team? And if so, how have you handled that? Brian Campbell (18:04) Um, I think my favorite example of that, I was working for a company. were rewriting all the systems, the main part of the business and everybody was under a lot of pressure. And at one point I got pulled into a meeting where, um, the, this was during the pandemic, so everybody was on zoom and I got pulled into a meeting where the product owner was at loggerheads with the lead developer. And my job became one of being a mediator to make sure both of them were heard, to make sure that they felt their points were valid, but then to guide them towards a place where they could work better together. And I like to think at the end of that conversation, it's a working relationship, but it was very touch and go. That was a very, very difficult project. Brian Milner (18:59) Yeah, that's such a great story because it's a tough thing. I know, we talk about empathy. I empathize with all the scrum masters out there that find themselves in those positions because I've been in that too. And I'll be the first to admit, I haven't always handled those situations so well. Sometimes I've left it up to them to try to resolve and have had bad consequences as a result. But I think your approach there, Brian, is absolutely the right one to take. It's not fun to dive into the middle of two other people's conflict. No one would do that naturally in life. It's just something we'd try to, you hey, that's their thing. I'm going to leave it up to them. But when we're talking about our team, I mean, we're kind of framing this part of this in the frame of teamwork. That's kind of the concern, I think, when those conflicts start to become really bad. Well, how is that going to affect the team? It may just be those two people, but it's not going to stay those two people. It's going to spread. It's going to get wider in the team. your approach of kind of just, hey, I'm going to roll up my sleeves. I'm going to get in the middle of this with you. And it may not be fun, but I'm not going to abandon you. I'm here with you, and we're going to find our way through this. Brian Campbell (20:09) It is really important that both sides feel they're heard and that both sides understand the merit of what the other side's saying from a third person. Brian Milner (20:19) Yeah. Such a great point. And isn't it amazing how sometimes that's really all it takes? Sometimes it just, people need to feel like they were heard. That they're not being, their point isn't glossed over. That we've really heard their concerns, we've processed it, it's been considered. And it's such a defeating feeling when you feel like that doesn't happen, when I'm not being heard. So you're absolutely right, I agree with that. One of the other things that we touched on and talked about in this section was the whole idea of navigating the thing that none of us wants to navigate. That's when we're in that crunch time mode for projects. I remember being told early on as a developer, hey, everyone works nights and weekends in crunch time because that's just part of the industry. You just have to be ready for it. How have you handled and helped the team navigate some kind of crunch time moments? Brian Campbell (21:12) Well, first of all, you leave with empathy. Uh, I remember going into a big project that I had a lot of experience with this kind of thing, but the team and I said, things are going to get really crazy and very disheveled. And I just want you to know I'm here to support you, but don't be surprised if you get a lot of curve balls turn along the way. And I remember the business analyst thinking I was absolutely crazy, but. especially with large enterprise projects, there's going to be crunch time. you're going to be the person who kind of soothes nerves a lot like that confrontation we talked about earlier. You're going to be the person who lends an empathetic ear but maintains agile guardrails to make sure a process is being dealt with correctly, but not being an agile Nazi either. I think those are all really good things. Again, you want to keep meetings efficient and minimize the team from being, minimize wasted time and also minimize distractions because the team's got to be heads down during those times. And you've got to be really proactive about forging connections and getting familiar enough with what they're doing that you can foresee when there's going to be an issue. Brian Milner (22:35) Yeah. Yeah, that's such a good point. Yeah, it's not a position you want to be in, but it does happen, even in agile projects. You do find from time to time when you just are kind caught in that crunch time moment. when that happens, I love your approach of being empathetic with the team also. But it's sort of. I was kind of thinking, well, how can I serve the team through this? know, like they're going through a tough time right now. It's not fun. How could I make it easier? You know, what's something I could do? Can I hop in there and do something that maybe grunt work that no one else wants to do, but it doesn't take a lot of brain power. It just is going to be time consuming. Can I? go buy lunch, can I bring coffee? Things that I wouldn't do on a normal basis, but they're in a unique position. Brian Campbell (23:25) ⁓ Yeah, I've done those things. Although I had to say that there was one company I left shortly after this. But there were two teams of developers working on a project for three months. And of course, because they were not doing agile correctly, there was no feedback from the stakeholders during that period. So they dropped this project in the lap of the stakeholder. Stakeholder doesn't like it at all. teams given two weeks to correct the flaws. And unfortunately, there are a bunch of people on H1B visas. So if they don't like it, they can get on a boat and go home or a flight. And it's more modern nowadays. But I remember working two weeks, nights and weekends with them. And the only thing I was allowed to do was bring donuts in the morning. And it was Brian Milner (24:20) Ha Brian Campbell (24:23) extremely frustrating to have my hands tied like that as the Supreme Minister. Brian Milner (24:27) Yeah, yeah, it's, it's, it's bad too, when it becomes the expectation. Hey, where are the donuts today? you know, that kind of thing. you know, I think there's, there's a middle ground and there's somewhere to say, Hey, if things are tough, I can do that without it being the expectation. I can find ways to kind of make life better for them, to help us get through this. Yeah. Brian Campbell (24:47) yeah, you should always be advocating for the team. ⁓ Even when they're beat down, you should be saying, we're under a lot of stress right now. What can we do to make things easier on the teams that already having enough problems without us making it harder? Brian Milner (24:51) Yeah. Yeah. Yeah, well, I want to kind of get and bring us around a little bit full circle here because you referred to this earlier. And I think it's an important thing for us to talk about in this section as well. And that's kind of, there are times when it's time to move on. And maybe the best thing I can do for the organization, for the team is to move on. So. I guess the question then is how do you know that? How do you know when it's time to maybe pack up and find somewhere else? Brian Campbell (25:41) I think the example I just gave is a really good one where they were being asked to work insane hours. And I had been on prior projects with this company where one example they had given me, a team with five developers and no product owner. And I worked around that by having the team write the stories. I didn't even have BA. It was really, really difficult. And I ended up advocating for them when they didn't have enough testers. It was just a real nightmare. And then they put me on this other team that was given two weeks to do probably two months worth of work. At that point, I didn't like the way they were treating the teams. And I said, OK, it's time to move on. Luckily, the company that I moved on to was three floors above where I was working, so that made it really easy transition. There was the meat grinder mentality, when it went from being a good environment to a meat grinder, disposed company for meat grinders. And then there was another example where they wanted the scrimmasters to take on project management duties and I was already in this case. They had given me a 25 person team, which we broke into five teams and we had, we had kind of made it so that I taught the lead developers and all the schemes, to facilitate the daily scrum. And we all came together right after that for a scrum of scrums. And they wanted me to throw project manager duties on top of that. And that was like, I don't think that's a feasible thing for me to do so I kind of kind of stepped away from that job Brian Milner (27:18) Yeah. Yeah, I think there's moments like that where you just have to look at things and say, I know I've had moments where I've had to look and just say, I'm not going to be of any help. You know, with with kind of the things I do well, and the direction this organization is going in, I don't see how I can come alongside and really help them because they're headed the other direction. ⁓ Brian Campbell (27:41) Yeah. Brian Milner (27:42) And if that's the case, I don't want to tell them, hey, the whole organization has to change and come around to my way of thought. That's not going to happen. Mike tells a story. Mike Cohn tells a story about even experiencing this as a trainer of going into different places and private companies hiring him to come and train and him experiencing things while training. that he just realizes, hey, no one's going to, nothing's, this isn't going to make an impact, right? Either the culture here is everyone has their laptops open and they're all doing their emails the entire class anyway, or, you know, they just say, well, we're not doing that. We're not going to be able to do it that way or something. And at a certain point, you just have to say, well, then I don't want to waste your time. Brian Campbell (28:25) Yeah. Brian Milner (28:25) I'm wasting your time and it's wasting my time and it's not helping anything. Brian Campbell (28:31) Yeah, I actually was at that same company that had, you know, no product owner on one team and developers working two months for their work in two weeks. They were doing scaled agile. So they had a scaled agile scrum master class where they invited a bunch of people from all over the company. And all they wanted to do was gripe about how they really didn't want to move to agile and how horrible it was and how they wanted to do things the way they've always done them. And the facilitator had lost control of the room and I had to, I had to subsequently go study to get my certification with them on my own because it was so incredibly off the rails. But yeah, I've been in environments like that. Brian Milner (29:17) Yeah. Well, this has been great. I really appreciate the topics here. And I appreciate your approach to this, Brian. I think that it shows your years of experience, just that especially the initial thought seems to always be one of, let me try to have empathy for the. the person in the other shoe and lead from that standpoint, right? Try to understand them at that level. So I appreciate you coming on and sharing this information. Any kind of key takeaways you'd leave everyone with here? Brian Campbell (29:49) You do want to leave with empathy, but you want to have firm guardrails, like I said. Sometimes they, particularly in crunch time, they want to bend the rules. ⁓ So that's one thought. But the other thought is support your product owner. They're already under enough pressure. Maybe it's as simple as Brian Milner (29:59) Yeah. Brian Campbell (30:10) making sure that the tags on the stories are correct or making sure that, I mean, if you're in person, making sure that you show up for meetings on time and that you corral the troops, you know, make it easy on the product owner because they're under usually quite a bit of pressure. And that's probably one of the bigger ones too. Brian Milner (30:32) Yeah, that's a great point. Well, Brian, thank you so much for your time. I appreciate you making time for this and coming on and sharing your wisdom with us and kind of helping us to see from a different perspective a little bit about what it's like to really be out there and working as a Scrum Master today. So thanks for your time, Ryan. Brian Campbell (30:50) Thanks, it's a pleasure being on the show.

“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 [email protected] 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 accomplish the purpose or the people don't really understand the purpose of why they're there. ⁓ Right, they're ticking a box. Lance Dacy (06:16) They're ticking a box, right? They're saying, well, we went through this meeting. Brian Milner (06:19) Yeah. I mean, and when you do that, just feels like it does feel like a drag. feels like just a, you know, a beat down, you know, that happens over and over again. It's funny that you put that about 12%. I was trying to do the math in my head and I just, I roughly kind of thought, well, what did I do last time I was a scrum master? Yeah. We would, we would have like half a day of the first, if I have a two week sprint, we'd have half the day, the first day in sprint planning about, or maybe not even half of it, right? Lance Dacy (06:48) Right. When you get better, it's less time, right? Brian Milner (06:50) Yeah, right. We would have a portion of the morning of the last day being a sprint and review and a portion of the afternoon being retrospective. But even if you made that just the whole time, mean, the maximum that you could even add that up to if you had tried to squeeze in those daily scrums as well would be 20%. But even at that, would say, you know, compare if you're not doing scrum. Compare what percentage of your times in meetings now. And I guarantee you it's more than 20 % of your work time over two weeks that you're in a meeting. ⁓ Lance Dacy (07:15) Right? Well, you also have the context switching, right? If you're not doing it in a more focused event like Scrum, you kind of have more probably interrupt. I, you know, I think that's such a great point to make when we're teaching people this, which we kind of talk about this in our class as well. But we try to encourage people to not think of it that way as a meeting. It's a working session. It's a collaboration session. Cause I hear all the time, you know, developers will say, I don't want to go to sprint planning. I just want to get in there and start coding. I'm like, code what? Brian Milner (07:47) Yeah. Lance Dacy (07:49) What are you going to code? I mean, what if you went in there and coded a thousand lines? It's all incorrect. Is that helpful? No, it's not helpful. So I find let's help the teams learn how to translate time because they're always sensitive to it, to ROI, not a cost. So every event that we typically have in Scrum is what we would call a scheduled inspect and adapt loop, right? That's really what the three pillars of Scrum, inspection, adaptation, and visibility or transparency. So those loops are what tries to help us, you know, slash up the rework that might happen later or missed requirements or delay costs. So the real hidden meanings that devour our calendars, Scrum is going to give us a little bit more thoughtful way to do that. And, you know, there was a study out there, actually, Jeff Sutherland did a study, I think it was back in 2024, and he found that teams who hit each time box saw about 32 % fewer unplanned meetings and a 27 % drop in defect work. Now with numbers, you never know, you I'd have to go read, where did he get these numbers at? But I just think it's curious, an argument to make with that. And so you can invite leaders who are saying this is too many meetings to do a, you know, like a cost of delay experience to say if a 15 minute daily scrum saves even one developer from being blocked for half the day. we're already net positive on meeting time. So how often does that happen in the world? And that kind of turns it around from time to flow and ROI and all that. So I think making those metrics visible is important to especially leaders and managers who kind of balk at, my gosh, my people are in these, all these meetings and they feel like the only way to be productive is hands on a keyboard. So. In our working on a Scrum Team class, we get to kind of broach that not from any particular role and just say, celebrate that. Don't be mindful of that as we go. know, obviously the CSM course, we would try to talk about techniques on how to mitigate it. But that to me is one of the biggest issues is this notion that meetings are not a good thing to be in. Brian Milner (09:36) Yeah. Yeah, yeah, I agree. Well, let's step through the four main meetings. This is always a trick question too. I tell people in class, if you are answering a test, there's actually five events in Scrum, but the fifth one is the sprint itself. So we're not gonna focus on the sprint, but we'll talk about the four here. Just at least hit them. and talk about some of the bigger issues that we've seen in them. So let's start with the one that sets it up, sprint planning. Like you said, I think one of the kind of chief things to think about here is if you don't do this, how are you solving that purpose of knowing what it is we're gonna do? But what do you think some of the biggest mistakes people make are in trying to do a sprint planning session? Lance Dacy (10:30) Get in and out of it very quickly. That's the biggest mistake. I typically like to teach, know, sprint planning is really, we could use all the scrum terminology, but we are trying to co-create and forecast work that the team believes will accomplish the sprint goal set forward by the product owner. Brian Milner (10:32) Yeah. Yeah. Lance Dacy (10:48) and then devise a plan on how to get there. So we typically think of sprint planning in three parts. And I think that's the big mistake is they just want to get in there and say, well, we do 20 units of work a sprint, pull in 20 units, eyeball it and off we go. No, no, no. Product owner needs to kick us off and say, here's the focus of the sprint. Here's why I want to run the sprint. That's our sprint goal. And a lot of people think, well, the sprint goal is just to get this work done. It's like, no, no, the sprint goal is to deliver something. that's a value somewhere. It doesn't have to be customer value. It can be any kind of value right there. So first of all, what is our sprint goal? Secondly, who are, you who's on the team? What are our collective capacity and skill sets? So what could we high level try to bring into the sprint from the product backlog to achieve the sprint goal? And then that third part is devising the plan for you. So, you know, the Scrum Guide kind of uses language like... The whole point of a sprint backlog is to have enough detail in the plan that changes in the plan can be detected every single day. So if you ask me what's one of the fundamental problems with sprint planning, is teams do not spend enough time doing that. So when they look at the, you know, let's say the daily scrum, its purpose is to inspect and adapt and make visible the sprint backlog. they don't have a good visualization of the plan. It's more of a stair step like burn down chart because they don't have enough detail to see changes every day. So I'm really a big fan of teaching teams how to take a product backlog item and break it down into, know, the product backlog item says what we need to deliver, but our sprint backlog is how to deliver it. So I use the example, I want you to clean my car, right? That's what I want. I'm going to give you acceptance criteria. I'm not going to tell you how to clean the car, but our team should get in there and say, okay, In order to get the car clean, we got to wash the car, wax the car, vacuum the car, do the wheels, clean up the trash in the car, open it. Those are all the things that we have to do. And to me, those should be like individual sprint backlog items that every day of the sprint, we can see how much of that are we getting completed or not. Lack of completion. So to me, that's really what it's all about is teams just thinking they're getting in there. check in a box saying, here's what we're going to do this sprint. It's like, no, here's what we're going to do. Here's how we're going to do it. we have, remember the last one a lot of people miss is that the collective team has a level of confidence that they can achieve it. So how do we know that if they haven't detected their capacity versus the skills and what skills are needed for the work that's brought in? So I think teams do a terrible job at that, Brian Milner (13:07) Yeah. I absolutely, 100 % agree. I think so much of the problems, not even just with sprint planning, but so much of the problems with just the making our sprint goal and other things in their sprint really can be focused back to this to say, did you spend enough time trying to fully understand the work? And if you didn't really spend enough time trying to fully understand what's gonna take to do this, yeah, that's a clear why. behind the reason that you weren't able to complete everything, because you kind of just rushed through it, right? You didn't really get to the, yeah, you didn't really get to the detailed level of what it was gonna take. Lance Dacy (13:49) and it's gonna cost you a lot. Yeah. And that's the whole point is teaching them that's going to cost you later. So yeah, this time we're spending upfront, what if it saves us a lot of this other rework that we're going to have later in the sprint? I just don't know why people can't think about that. And, know, with, with any kind of agile process in particular scrum, we're doing progressive planning, which means we've got to be comfortable with ambiguity all the way up until delivery of the thing. You know, we may not know everything until it's actually done. And that's usually the case, but so you got to be comfortable with ambiguity, but at the same time, Are you learning enough about the work to feel comfortable with that ambiguity? You know, it's like, what level of confidence do we have that we've kind of thought through a lot of these things? It'll never be everything really, but why not spend the time that's built into your velocity? You know, it's like, if you're tracking how much work you get completed and you're spending time doing these things and your velocity is already accounting for this stuff. So go ahead and celebrate that, you know. Brian Milner (14:28) Right. Yeah, I think this is also a clear indication. When people ask sometimes, well, what does the scrum master do? You when you hear about a meeting like this, the sprint planning, and we were saying, you you need to spend enough time that you fully understand the work. How can we be sure they've spent enough time really fully understanding the work? Sure would be nice if you had a coach that could help them understand that, right? That's what the scrum master should be doing. So if you're kind of skimping on, is that skimping? Skimping? Skimping. On the Scrum Master role in general, then that might be even the source behind this is that they're not doing very well with the sprint planning session because they don't have anyone that actually knows what a good sprint planning session looks like to help them even get through it. Lance Dacy (15:14) Skipping by we'll say it is somebody Right. I mean, I tell, I coach people on sprint planning all the time. They're like, my gosh, that's too much work. Too much work. I mean, half the work is understanding what you need to deliver. mean, everybody just kind of seems to think that, especially in technology, if my hands aren't on a keyboard and I'm not writing code and testing code, I'm like, what if the hour long session we had with eight people in a room told us we didn't have to write any code at all? That reduces complexity of the product and. Brian Milner (15:40) you Lance Dacy (15:59) less things we have to test. I just feel like we're narrow minded when it comes to that. And I try to tell teams all the time, the litmus test of success to me on sprint planning is that everybody on the team can articulate why the chosen backlog items move the product closer to the overarching goal. But how often do we just glaze over the sprint goal and the product goals? It's like, you you hear people all the time. The goal of this sprint is to get these eight backlog items done. That's terrible. Brian Milner (16:25) Yeah, yeah. Well, we could park on this the whole episode, but we do want to try to make it through the others as well. So let's go to the one that the only repeating event that takes place in Scrum, the Daily Scrum. What have you seen as being some of the biggest problems with this meeting? Lance Dacy (16:30) Right. Well, I mean, I think we could probably placate this one and say, most of the time people turn it into a status meeting. Okay. Okay. I agree with that one that Scrum says that the daily Scrum is more about the team collectively assessing the progress or lack thereof the sprint. Well, that entails some level of, you know, status of how things are going. But I think what they lose sight of is that the daily Scrum is really, you know, more about I would say synchronization, right? We're supposed to be synchronizing on the system of work to uncover, you know, the bottlenecks, you know, plan the work for the next 24 hours to help us hit the sprint goal. So I find that at the daily scrum, if the team leaves, you know, maybe with at least one concrete adjustment, like, hey, I'm going to pair up with you on this item that's taken too long or re-sequencing work because of the dependency or escalating something that's you know, stagnant is an impediment. Well, that's a really good way to do that. But I'd also say, Brian, so let's just put the status meeting problem on the side. The other one I hear quite a bit, and you'll hear this from teams a lot, I'm sure you have, but people are saying, hey, we already talk all day. I just don't think we need a daily scrum. You ever heard that one before? Brian Milner (17:58) Yeah, I have. Lance Dacy (17:59) What do you think of that one? Is that one a big deal? I mean, I find that I face that one all the time. So I don't want to just put that on the plate, but yeah, the status meeting problem. But how often have you heard teams saying we're, we excel at collaborating all day. Why do we have to have another meeting? Right. Brian Milner (18:15) I don't hear that often, but I do hear it occasionally. And my question would be, is that the reality? Are they really communicating that much? Because if they are, we talk about sometimes this development practice called mob programming. Mob programming, everyone's in the same room at the same time all day long. And they don't have daily scrums usually when they do mob programming because There's nothing to share they don't already know, because they've all been working together the entire time. using that as an extreme example, right? In those cases, I think that they're accomplishing the purpose in a different way. And I don't really have a problem with those teams doing it. if a team says, we communicate all the time, do they really? Because if they do, yeah. Lance Dacy (18:58) Right. And how much of it on Slack? mean, how much of it's an email? So we, we, hear this all the time. And you know, I just, I just seem to, maybe I come across the teams that say it all the time and it's, took me a long time to finally, you know, try to get to the point and articulate that, you know, talking all day does not equal a 15 minute whole team inspection. and adapt the loop that focuses everyone on the sprint goal. I mean, yeah, you collaborated today and say, how are you looking on this? But have we all collectively got together, look at the scrum board or the Kanban board or whatever it is that you're looking at and actually look at each other in the eye and say, how are we doing with this? So, you know, I typically think about synchronizing on the sprint goal. Conversations are fragmented, right? So some voices never hear the full picture. Some hidden work piles up. We don't know it. Brian Milner (19:18) Yeah. Lance Dacy (19:46) We already know that if you just read asynchronous comments, you may not interpret them correctly. That's another problem. And so I just find that if you are just talking to a couple of people, then those blockers may stay local and developer loses half a day before maybe anybody notices, even though they were collaborating and talking with people. So I think the Slack stuff is good. There's good ways to have asynchronous daily scrums if you absolutely have to do it. But I find that those like a Slack you know, ping scatter attention, and create a lot of context switching as well. And I just don't feel like the information is radiated very evenly or cohesively across the team. And so, I think it affects their predictability to do that, even though they're talking every day. That's great. I love y'all collaborating, but who's coming together and saying, do we all feel good, you know, about where things sit? I just don't think that that's happening in my opinion. Brian Milner (20:35) Yeah. Well, and I think your initial point about purpose, I think, is really important with this one, to understand the purpose of why we're there. And maybe even underneath that, or parallel on the same level as a little bit, is who is this for? Who is the owner of this? And the sooner I can get the developers to understand this isn't my meeting, this is your meeting. This is your event. This is your working session, as you said. If they own it and take Lance Dacy (20:57) developers understand this. Brian Milner (21:08) ownership of it, then it becomes a productive time because they realize, oh, we can talk about or do whatever we need to do here. Yeah, it would be great if we could coordinate and spend some time doing this kind of thing every day. So yeah, think kind of helping them understand that they own it as well, I think is an important aspect. Lance Dacy (21:28) Right. Like focusing on like, hey, you know, the outcome, not the necessarily, you know, the ceremony says, Hey, it's up to you. You choose what format you want to do this. But, I had a team one time that just kept reiterating Lance. do not need this. I'm like, you know what, if you're truly in sync, prove it. You know, it's like, let's experiment. So skip the event for one week intentionally and track two metrics, right? How many items are blocked 24 hours and how much unplanned work is discovered late. And most teams are going to see a spike in all of that. Right. So the thing is, um, you want to optimize it, you know, don't delete it. Mature teams may finish their daily scrum in half the time. That's okay. Right. So some run it asynchronously in a chat, plus then they get together in five minute live huddle to tackle. So there's a lot of different ways to do it, but I think so much, we focus on the daily scrum because it's the recurring meeting, right? It happens most often. And I find most leaders and managers in my early consulting days, they would call me up. Lance, we'd like you to come assess the team's daily scrum. don't think they're doing well. It's like really just the daily scrum. Why is that such a focal point? But yeah, that's a huge one, Brian Milner (22:35) Yeah, I always think of it kind of a little bit like checking the oil in your car. Like it can tell you so much about things, even though it's a quick little check, like it can just tell you how the car's been treated, you know, all that kind of stuff. ⁓ Right. Lance Dacy (22:47) Yeah. Or a pacemaker, right? I mean, it's like, I'll try to think of it since cadence is such a big thing. You know, think of the daily scrum, like a pacemaker of the sprint, that continuous chat is like blood flow. And that pacemaker ensures that that B to stay in regular, ⁓ just at minimum to surface problems, know, great point. Brian Milner (23:03) Yeah. Yeah. Let's talk about the sprint review. I know one of the things that's always been a pet peeve of mine is when people call it the demo, because that seems to probably placing the focus on just the demonstration and not really where I think the purpose is, which is getting feedback. So how have you seen teams handle successfully What kind of strategies have they used to get feedback and really inject feedback into their work? Lance Dacy (23:33) Well, I find if I had to like say one of the biggest issues here is I find that the right stakeholders typically aren't there, they're too busy. And I'm like, well, what's more important than spending, you know, $80,000 every two weeks for this team to build something for you? It's like, ⁓ so I'm just curious sometimes, you know, and I leave that up to the product owner. That's your responsibility is to make sure that the right stakeholders are there and that can highlight some problems as well. So let's just put that to the side. Brian Milner (23:40) Yes. Yeah. Yep. Lance Dacy (23:59) the fact that we need the right stakeholders there and they need to attend and find it valuable. Well, actually let's dive into that one. Stakeholders don't find it valuable. Why? Well, teams show up maybe with a PowerPoint slide and say, here's what we did. And it's a bunch of technical jargon and it's just boring to everybody. So the first thing I like to do is I'll create a nice little agenda for it where I'll have the product owner kind of stand up and recap. What was the purpose of the sprint? Why did we have the sprint? What were we trying to get accomplished? Brian Milner (24:12) you Lance Dacy (24:28) What did we get accomplished, what we didn't get accomplished and how that affects the overall budget release and timeline. Can you believe that most people don't think a sprint review is actually a review of the sprint? Standing in front of your stakeholders saying, here's how the sprint went. It's not a retrospective. It's just saying, here's how it went. Here's the problems we have. Here's some things we might need help with removing impediments, but that's the first part of a sprint review. And I want the product owner to own that. Brian Milner (24:38) Ha ha ha ha. Lance Dacy (24:53) and show the timelines and show the budget and do all of those things. I love that kind of stuff. And then I kind of let the Scrum Master go over metrics of the team that the stakeholders like to see. Remember, Scrum should be a self-reporting framework. They shouldn't have to request status updates. We should just be pushing the information. I think the sprint review is a good way to kind of test what information do you want, what's valuable, but to bake that into our process so nobody has to go run a report. So. Brian Milner (25:19) Yeah. Lance Dacy (25:19) I like the Scrum Master to kind of do that and engage what that's looking like. And then the third part, like you just said, is a demo. Well, really what's better is let them use the product. That's probably the best thing we can do, but don't show me a PowerPoint slide. Show me what's working and show me how this works and let me experience it so that I can actually say that that solves our problem. I know the product owner already said that, but they may have missed it as well. Brian Milner (25:29) Yeah. Lance Dacy (25:44) I find the, and what happens is you say, this is too technical. You know, I just updated a, you know, it was a, just say a re-indexed a database table. It's like, they don't understand what that means. That's not true. You show a query, run the query, say it was very slow. It's had a subtree cost of this and I changed these indexes. I run it again. It's the same data. So that's good, but it goes quicker. And here it is. I mean, it takes under a minute. You don't have to know SQL to understand what's going on, but that gives them confidence that Brian Milner (26:07) Yeah. Lance Dacy (26:13) Wow. Okay. That's really cool. So it took time, right? Some people just think, well, it's too technical. They want to understand it. It took you half the sprint. Be proud of that. So I think one of the big problems as well, not having stakeholders there at all, but not having a good, you know, I don't want to make it so formal that it's stuffy, but I like to put those three components in there. Why did we have the sprint? What's the overall budget release and timeline? What are the metrics we're capturing? Do these look good to y'all? Is there anything else you want? And then the demo. Brian Milner (26:21) Yeah, yeah. Lance Dacy (26:42) and let the developers be prepared. What am I going to show? Let me have my test data up and ready to go so those demos go really smooth. And I find that it builds trust and confidence. So that's what I think. Brian Milner (26:52) I completely agree. it's, if you're a developer, and I've encountered this before from developers where they feel a little nervous about letting the stakeholders actually do the thing in the sprint review. And my question to them is, well, then how can you call it done? Right? I mean, if you're afraid to even in the sprint review have someone actually use the product, it needs you, the developer to actually do it. in order for it to be successful, then how can that be done? Lance Dacy (27:19) Right. Or they're like, I don't want to spend the time to get it ready for demo. Well, no, that's the point. You've got to spend some time preparing for the sprint review. That's OK. and guess what, Brian? That might be another meeting. Brian Milner (27:25) Yeah. Yeah, right. Yeah. And, you know, I think this is, this is something we talk about pretty well in, in the WoS class as well, just kind of what a good sprint review looks like and what, how to plan it. you know, what everyone's responsibilities are there. think having being armed with that really does give you a leg up on, on making this a more successful meeting. Lance Dacy (27:54) Absolutely. So I think, you know, we want to involve the stakeholders, have a conversation, invite the right people and make sure, you know, the other part of this, make sure your process is providing the information to the stakeholders that they want. And that's the job of a scrum master. So the sprint reviews are great litmus test for that as well. Brian Milner (28:12) Yeah, well, we got the last one here to cover. That's the retrospective. And this is one of my favorite meetings. But what have you seen as some of the biggest issues with teams and retrospectives? Lance Dacy (28:24) Well, I mean, if usually when somebody asks me, you know, what's the most important pieces of scrum, there's a lot of important pieces. the two most important activities or events in scrum. The first one in my opinion is the retrospective. And the second one is product backlog refinement. Like if you get those two things right, you know, I hear business people, mentors in business all the time. If you take care, of the top line stuff, the bottom line will follow. Right. So if you do really good at retrospection and you do really good at backlog refinement, all these other things will typically fall into place fairly easily. But what happens in the retrospective, in my opinion, is teams try to solve too many problems at one time. They don't know that by the way. So how this really manifests is, we don't see any improvement. And so they just start losing sight of the retrospective providing any value. But really I find the root cause in my opinion is, Brian Milner (28:52) Yeah. Lance Dacy (29:19) They're trying to fix too many things and too many things are too big. You're not breaking it down, right? In Scrum, we talk about breaking product backlog items down into smaller ones that fit in the sprint to show usable increments. Well, you got to drink your own champagne and take your improvement backlog and break it down and limit. You remember that goal of lean concept, I believe I've read somewhere is limit your work in progress. The more things you work on at a time, the longer everything take and people are too busy. to improve, does that sound ridiculous or what? Too busy to improve. And the reason they're too busy to improve is it's too big, they don't see the value in it, so we're not doing a good job backlog refining the improvement backlog. So my opinion is, how we facilitate this event is probably the key because Scrum Masters really can earn their money here. But I've seen teams just get in a conference room, open up a Word doc and go, okay, what went well in the sprint? Brian Milner (29:49) Yeah. Lance Dacy (30:11) and they write it down and then, okay, what didn't go so well this sprint? And then they write it down and then, okay, anything we want to change, yeah, let's change these three things. Okay, Jane, you got this, Bill, you got that one. And then nothing ever happens. So I think that there's an execution part of the retrospective that is lacking. And one thing that I used to do with my teams that I thought worked really well is every retrospective we would have our action items and put them wherever we're doing the daily scrum. so that we're mindful of not only how the scrum is going or the, know, the sprints going with the daily scrum review, but it's also, are we keeping these other things in top of mind? And if that list is too long, you won't. And so I follow what Jeff Sutherland, you know, taught me one time when I was talking to him, he was saying that fine tuning your processes is a lot like fine tuning your computer. If you have a slow down or a bottleneck in your computer, you don't just change all these components and say there it was, you try to change one thing at a time so you can actually troubleshoot if that causes another problem, but it often exposes a bottleneck you never knew was there. So he actually talks about only select one, two, or maybe three things at a time to improve. And if they're too big that you can't really make improvement, break them down. So that to me, is the root cause that causes a ton of other superficial problems, if that makes sense. Brian Milner (31:31) Yeah. Yeah, I think there's a lot of subtlety with this meeting as well, right? mean, there's structure kind of issues that sometimes teams have, but there's some subtle issues that go to things like psychological safety and trust that I think can really make a difference here as well. whenever I bring that up, I always kind of worry people think, this is kind of a kumbaya thing. this guy wants us all to sit in a circle and hold hands and whatever. And that's not what I'm saying, but I do think that there is a level of safety that's needed. if I say my opinion and someone speaks up and says, well, that's stupid, or that's ridiculous, why would we ever do things that way? Right, mean, how likely am I to give you my opinion the next time? Lance Dacy (32:14) I know, what an idiot. ⁓ my gosh, I know, that's so bad. Brian Milner (32:22) Yeah. So I think that's something that you got to kind of be on guard with as a whole team. And you got to make it a whole team mission just to say, look, we're going to prioritize this. We're going to prioritize that we want to feel safe to speak our minds here in a safe way that's not going to be impairing, that's not going to have repercussions. when we do that, we'll find the most important stuff. ⁓ Yeah. Lance Dacy (32:46) Well, I mean, that's kind of why I go back to how it's facilitated, right? Because the way you facilitate, you can make it very institutionalized, right? So the people are just talking about the same problems over and over again. You know, I used to put a little, when I was talking about putting that little piece of paper up on where the daily scrum was, at the end of the sprint, in the retrospective, we would put a plus sign next to the ones we really thought we got better at. We'd put a minus if we got worse and just a slash if we didn't really pay attention at all. And we'd have to look at each other and go, why didn't we make any progress on this? we commit to do much? So the work of improvement is just as important as the product development work because that's what makes you hopefully deliver sooner at some point. I like to not think of agile as a faster way to work. It's actually slower, but you may deliver sooner because of the efficiencies you gain about getting better and more effective. And if you think about agile, Brian Milner (33:08) Yeah. Lance Dacy (33:35) as the philosophy of the way that we're delivering our product, Agile Principle Number 12 actually commands of the team to continuously tune and adjust their people and processes to get better. Well, the way we do that in Scrum is the retrospective. And so to me, it's inspecting the team's own people, process environment, and trying to select the most, know, biggest bang for the buck, the highest value for least cost. Does that sound familiar? You know, what's the improvement we can make and commit to it as a team just as important as we commit to the work of a sprint. And then that top impediment item, you know, becomes visible and, we get it removed and we start building out that cadence. And there's a lot of different, you know, I don't know. We have a lot of different online tools and things like that to facilitate. I'm curious, you do a lot of facilitation with this as well. What are some tools that you think work best to pull that best out of the team to do that? Brian Milner (34:26) Well, I mean, as far as actual tools, I think there's a lot of online tools like Miro and Mural that are really good kind of whiteboarding tools that allow people to interact and sometimes even in some anonymous ways. Sometimes you can have some anonymous type portions of it where that adds a little bit of safety to the room. ⁓ I'm not, no one's gonna know that it was my comment. Lance Dacy (34:26) Thank Yeah. Brian Milner (34:49) I used to use that kind of thing a lot when I was a scrum master. We would use a tool that allowed people to type in things anonymously. And that made a huge difference because here's the thing. One of the hard lines to walk as a scrum master facilitating this is that you're also participating. And facilitating should be kind of a neutral thing. But we're kind of Lance Dacy (35:05) Right. Yeah. Brian Milner (35:14) blurring the lines here as a Scrum Master, because you need to do both. You need to facilitate, but you also need to participate. And that's why I loved having kind of the anonymous nature of people adding things is because I could add things. I could put things on the board that then no one knew came for me, because I'm a team member like everyone else. And if everyone else agreed with me, then we'd talk about it. But if no one else did, hey, we'd talk about whatever everyone else thought was most important. Lance Dacy (35:33) because I'm a human, I can't be one of this. But you could also, know, bias the, or anchor the argument as well, just like when we do with estimating when you got the senior leader. So Scrum Masters, I totally agree. We walk a fine line, you know, active listening and doing some of those professional facilitation techniques to make sure we're guiding the team to a solution. you know, one of the biggest things that I like to do that I thought helped teams, regardless of how, you know, there's multiple ways to... format of retrospective, know, liberating structures has a lot of good activities that you could prey upon. But really what I want to do is bring the data. I bring data that hurts and helps, you know, what are our flow metrics look like, what are the escape defects? Let's not hide away from that. Concrete evidence is what's going to help focus the discussion on the work, not the people. And that's where your psychological safety, I think, comes into play. We want to challenge ideas, not the people. you know, and so we start thinking about ways to come together as a team and really address these things. So I like to prime psychological safety in that way. and focus on the problems with the data, not the people causing them, even though there's probably people causing them. you know, maybe you start with a two minute icebreaker or check in or something like that, that, there's a lot of ways that we could facilitate that. Brian Milner (36:46) Right. Lance Dacy (36:55) you just kind of get what they call an emotional exhale. You know, we just went through this sprint, we might've got our butts chewed in the sprint review by the CEO or whatever. We're in this together as a team, how can we bring that together? And then try to come out with a framed shared goal that's gonna help us all get better, you know, in that as well. So there's a lot of ways to do that. You know, in the WoZ class, we actually show a couple of those, right, that you can walk out. Brian Milner (37:21) Yeah. Lance Dacy (37:22) But that's what I love. The retrospective has to be one of the most important activities, I think, in Scrum. Brian Milner (37:27) I agree. I agree. Well, I mean, we made it through the events and you know, when we kind of look back at this, I would say, I hope what people hear is that it's not really the meetings that are the problem. It's really what goes on in that meeting. What's happening or what's not happening in that meeting that I think is kind of the important part. Recently, recent episode here on the podcast with Kurt Peterson. Lance Dacy (37:47) and I'll see you guys in a second. Brian Milner (37:54) we kind of brought this idea of talent versus skill and talent being kind of more the inborn ability to do something and skill being something you learn and earn on your own. And that's, think the good news about this is that a lot of this is skill-based. It's stuff that you can learn and get better at and improve upon. It's not something you have to just be naturally good at. Lance Dacy (38:16) Right. Well, and we didn't get into backlog refinement too much. That may be its own other thing, but I think those are handled poorly as well. But I agree with you, know, meetings aren't the villain necessarily, know, poorly designed meetings are the enemy. And I find that when every Scrum event is time boxed and anchored to real data and laser focused on inspecting and adapting and learning, that takes some time to learn how to do that. Right. Most individuals that join a team, Brian Milner (38:23) Right. Lance Dacy (38:43) aren't used to working that way, just like a lot of stakeholders aren't used to progressive planning. So I think the foundational element of a scrum master is to bring empathy and, you know, love on people where they are. That's what a coach does is embrace us where we are and say, here's what I'd like to get us and facilitate a plan to get us there. So that's some of the best things that a scrum master role can do. But also it's the team learning. those things as well to help adapt to that. So that's what the WOS class is such a great thing because now they're gonna be on the same language that a scrum master may be doing and that undercurrent can start moving at the same pace. So. Brian Milner (39:19) Absolutely agree, absolutely agree. Well, Lance, I can't thank you enough for making time for us to come back and talk. Thanks for chatting with us. Lance Dacy (39:27) Absolutely. Thanks for having me and wish you all the best of luck out there in your scrum endeavors. Hope to see you in a woes class very soon. Brian Milner (39:34) Yes.

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 [email protected] 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. Brian Milner (06:37) Right. Mike (06:49) I'll let them trade off if they want. If they will make the commitment to me, they'll take it seriously and really come with ideas and try to improve. Brian Milner (06:56) Yeah, well, I think this is a prime example as well why inspecting and adapting is so important because, all right, what's our issue? No one likes going to the retrospectives. We're jumping from that to, then let's just not do them as often. When what you need to do is stop and inspect and say, why don't any of us like coming to the retrospectives? What's the problem about our retrospectives? And that's really the core issue there is to say, Hey, are we doing the same thing every single retrospective? Are we saying, Hey, what went well? What didn't go well? Right. I mean, are we being asked the same questions every time? we never varying it up? Are we always doing kind of navel gazing kind of thing? Or sometimes are we doing team building stuff? Sometimes are we even just celebrating some things that happen from time to time? The root cause is the important part because otherwise, you know, it's like cutting off your leg because you you got to a little infection or something in your big toe. That's not the cure for it. The cure is find out what the disease is and treat the disease. Mike (07:57) 'm back to it's leg day at the gym and I'm going to cut my legs off because I hate leg day that much. Right. It's like, no, no more leg day. Right. So you'd have to really hate leg day for that, for that to be the solution. What, what are some of the signs that you've seen that indicate a retro is not working and that the team needs to kind of rethink things? What are some of those signs? Brian Milner (08:00) All right. No more leg day. Thanks. Yeah, no, that's really good. Common things, people checking out, people just giving surface level answers. Here's a big one. There's obvious things that didn't go well in your sprint, and no one brings them up. You just kind of get there and it's like, for example, hey, we didn't finish everything in this sprint. Mike (08:39) Yeah. Brian Milner (08:44) But then we get into our retrospective and no one puts on the board. What's something that didn't go well this front? We didn't complete all our work, right? Sometimes people get to that point where they just feel like, it's so obvious. Why would I need to bring it up? Well, if it's so obvious, then we need to address it, right? We need to do something about it. So yeah, I think that's part of it is that sometimes people will just check out and you might be able to tell it that way. You might be a tell it because they're not really contributing things. People try to rush through it. You know, it's like you only get a team where only a couple of things are in each one. And it's almost like it feels like the team's colluding to sort of, well, you put these two things up there and that'll be enough. And then they'll leave us alone. We can go on. You know, so, you know, they're, they may not literally be doing that, but it's almost, you get that feel that it's almost like there's an implied, I guess we have to have this number of things up there. Yeah. I mean, it's just, Mike (09:13) Good. Brian Milner (09:37) In general, there's no investment. When people show up, they're not really engaging. They're marking the time. And when that's going on, yeah, that's usually a precursor to someone eventually saying, hey, let's just not do this then. Mike (09:54) One of the problems that I'd add or one of the symptoms that I'd add would be when the team is talking about things again and again, the same item again and again, right? And it's not gonna get fixed. You we might be in there talking about, you know, I hate the new building, right? The new building's farther from my home. This is a real team I worked with where they all moved. They were downtown and the company moved everybody out. near the airport in their city. And it wasn't better for anybody. I mean, it was probably better for the CFO writing the check for the landlord or to the landlord. But it was a bigger commute for everybody. The facility wasn't as nice. It wasn't your restaurants. I mean, it just kind of sucked. And they would grumble about it every week. It's like, we can't fix this, right? We can't fix this. Right. You know, and so sometimes talking about things that are out of a team's hands are are they're just frustrating. Right. Brian Milner (10:34) Ha ha ha ha. Yeah. Mike (10:42) It's like mention it one time. I hate the new building. It sucks. There's no good restaurants here. And you know, you're probably not going to fix that problem. Maybe you can agree that you're going to, know, on, you know, the last Friday of a sprint, everybody on the team is driving back downtown and we're all going to lunch together, right? Fix it that way a little bit. But, you know, don't grumble about things that are out of your hand, right? You know, I'm worried about climate change. It's like, yeah, but I don't hear about that. It seems retrospective, right? Brian Milner (11:02) Yeah. Yeah, that's completely outside our circle to do anything about, right? So yeah, I agree that there is that scope sometimes that happens. But on the other side of it too, I would say one of the other killers that can contribute to people kind of checking out is not feeling like it's making any difference. know, if we bring something up, let's say it's not completely out of our hands, but it is something that's a real issue. And we bring it up. Mike (11:09) You Yeah, we need to test earlier. We need to test earlier in the sprints, right? Brian Milner (11:33) Right. We need to test earlier. We think we'd be better if we had some test automation here and we want to put test automation software in place. Yeah, well, I asked the manager and he said no. So I guess we're done. Right. I mean, it's frustrating. We say these things. I think it's important that the team see progress. It doesn't mean that you have to solve it 100%. In that case, hey, the manager said no. OK. Mike (11:46) No. Frustrating. Brian Milner (12:01) Well then how can we raise the transparency of the issue it's causing for us not to have it? We can make it apparent that this is what's going on. I remember there was a team I had one time that they started to bring up the issue that they didn't have a coffee machine near them. Now this was an absurd case because I don't know any other place that would do this. for whatever reason, this place I was at, they had two floors. the programmers were on a floor without the coffee machine. The coffee machine was down the stairs on the lower floor. And so they were complaining because they were saying, hey, we have to walk up and down the stairs all these times a day. mean, there's a reason that we name our languages Java. They're coffee drinkers. So they brought it up, and we talked about it. And we said, oh, guess they kind of set up the office the way they set up the office. immediately put me into action to think, you know what, this may not be about coding or may not be about something that's kind of a day by day thing that's doing our work, but it is an important thing that they have access to this. And I was able to then kind of start to compile some data and show, look, they're spending this much time walking up and down the stairs and that's happening to each developer and you're losing this much time of their day walking up and down stairs. You think it's too much expense to put in this coffee machine, but you're paying this every week by not having a coffee machine up here. And we were able to get them to actually make that change. That was huge for those developers. They thought that was the best thing in the world that now the coffee machine was relatively easy to get to, and they could get refills anytime they wanted. So I think it's important that they see that progress happens. Right. Mike (13:46) Yeah, it showed that they were cared for, right? That somebody heard, right? Why do you think this is so prevalent? Because, mean, you we hear this all the time, right? You know, oh, our retro soccer. Oh, man, I'm going go to retro today. Why is this such a common thing? Why do so many teams feel like they don't need to do retrospectives? Brian Milner (13:50) Exactly. I'm not really sure why they jumped to that as the solution, because as I said, we don't really do that anywhere else in life. Other than to just think, you know, no one likes meetings. And when we come up against a meeting that we don't feel is going well, then that's sort of, that is sort of our instinct is, well, then let's just not have this meeting. But if they, maybe that gets back to purpose even a little bit then. If I don't understand the purpose of it, then now it's not just that it's not going well, it feels pointless. And why do I want to go through something that's painful to go through and I don't understand why you want me to go through it? You know, that's a double whammy that now the easy solution is, well, let's just not do it then. Mike (14:34) Right. think a lot of teams feel like, you they adopted just the bare beginnings of Agile or Scrum and they start to, they notice they're better, right? We've improved. And they, maybe they are 10, 20, 50 % better than they were before and got there pretty easily. And it's like, well, we don't need to keep improving. We just improved, right? ⁓ And you know, it's the Dunning-Kruger effect, right? This is like so much more you could get better at, but you you see that you got better. Why keep going, right? Brian Milner (15:03) Yeah. Yeah. Mike (15:14) So I think that's a factor. I'm curious what you would say to me 20 something years ago, because Esther Derby is the reason why retros got added as a standard thing in Scrum. They were not part of Scrum at the beginning. And she started lobbying that they should be a standard part of Scrum. And I disagreed. I said retros should not be part of Scrum. And I'm very big on admitting my mistakes. So I argued no. So I'm curious what you would say to me, because here's my argument. I don't want to wait until the end of a sprint to tell my team an opportunity to get better. If I notice an opportunity to get better, I need to bring that up in the next morning's Daily Scrumber. If it's a huge opportunity to go grab everybody that afternoon and mention it. How would you argue with me about that? Because in some ways, that is a better way to get better, right? Just bring it up in the moment. Why wait till the end of a sprint? Brian Milner (16:03) Well, I think what I'd say is, then if you recognize something in the moment, then absolutely bring it up in the moment. There's no need for you to wait till the end of the sprint. I don't think that you store it up or that you have to wait. I would say something similar about a sprint review. Why do I have to wait till the end of the sprint before I get feedback from a customer about something I just did? You don't, right? ⁓ There's no reason why you can't on day two or three Mike (16:25) Okay. Brian Milner (16:28) show it to somebody who's going to be using it and say, what do you think about this? In fact, it's better if you do that. What it becomes though is that, speaking now about the review, the review is the time everyone can count on every sprint to show up and examine the increment and give feedback. The retrospective is very similar. We can give feedback throughout the sprint. We can improve throughout the sprint. Mike (16:52) Right. Brian Milner (16:52) but it's the designated cadence. It's the time that we can count on every sprint that we're gonna set aside, right? We're gonna set that aside to do this because we think it's that important. Mike (17:04) I think it's that dedication, that dedicated time that is part of what persuaded me because suppose I come, I do come up with a brilliant insight. It's my idea. Of course it's a brilliant idea. I come up with this brilliant idea about how our team can get better, Brian. And I want to talk to about it right now. And I, I, I Slack you and I said, let's talk about this. No, your head's down in the middle of something else. You don't want to talk about it right now. It's not the right time, right? And if we set aside that time at the end of the sprint as a dedicated time, it's more likely to happen and it's everybody knows to have their brain ready for that conversation, right? It worked better, right? Brian Milner (17:42) Right, and the fact is, lots of people are heads down throughout the sprint, right? There's lots of time in the sprint where you're just so involved and busy and your brain's working on what we're building that unless you get told, unless you get that thing on the schedule that says, wait, I gotta stop, okay, time to retrospect, right? Unless you get that reminder that, hey, this is important too, right? We gotta do this thing. You could very easily just end up going for a long period of time with never doing it. And that's the danger. It falls off your radar and pretty soon you're never having any kind of time to retrospect. So it's not that there's something magic about, we've got this meeting that's called this. It's really what happens in it. And if that's happening on an ongoing basis, well, maybe you have another process that's not Scrum that would be as effective, but Scrum dedicates that time so that you make sure you don't miss it. Mike (18:35) Yeah, I just don't think it happens. If we told everybody, as soon as you come up with an opportunity to improve, interrupt your team and tell them about it right then. It's not going to happen because if I have a brilliant idea, OK, I might go talk to people. How many brilliant ways to improve a team do you come up with, right? Most of them are incremental, right? Hey, here's a way that we do a little bit better. And I'm going to go, well, this will all be a little bit better, but everybody looks busy. I'm not going to go bother them right now, right? And I noticed that I would do this. I would have an idea. I wouldn't bring it up. And then tomorrow I'd forget about it. What was that brilliant idea I had yesterday? And so I became a very strong advocate of the retro, despite at the beginning, and being very honest with that, not thinking that it should be part of Scrum. It should be something that we just do on a more ad hoc basis. Brian Milner (19:21) Yeah, that's very interesting. And I'm glad you shared that because it's interesting about the evolution of things and how things have changed over time as far as that's concerned. But you know, the other kind of aspect there it also is, you know, if my if I'm heads down and I'm going through, there are some things I'm going to notice just in the course of doing my work, because, hey, I would have been better if I could have done it this way versus that way. But I also feel like I'm going to miss so much if I don't actually pause and and redirect my brain from, I'm just plowing forward to let me actually turn my attention towards what's happened over this recent past and really think through it. Well, what did happen this last sprint? Let me think through everything that's happened. Yeah, that wasn't great. That was okay. That was actually pretty good. Mike (20:07) Do you have a structure you use for helping teams find ways to get better? Brian Milner (20:13) You mean as far as a retrospective is concerned? Mike (20:16) Yeah, I you mentioned earlier asking people like, you know, what went well, what didn't. Is there a structure, even a higher level framework you use? Brian Milner (20:24) Yeah, mean, the way I, Astrodurby and Dinah Larson's book has a really great five step kind of process for it. But I even tend to kind of distill it down even a little bit more than that, to just say that, you if you think about this thing that we talk about as the three pillars of Scrum, that, we talk about in Scrum classes, transparency, inspection, adaptation. I think that's actually a good pattern for retrospective transparency. What actually happened? I mean, let's try to be clear about what the reality was from this past sprint. Inspection, why did those things happen? What was the root cause of why those things happened? And then adaptation, what are you going to do about it? We don't want to just keep doing the same things and let's hope everything gets better. No, hope is not a strategy, right? We have to figure out the root cause and then have a plan. What are we going to do differently? Mike (21:12) Yeah. What advice do you have for somebody listening right now that wants to fix their retrospectives, wants to stop them feeling useless and be productive in their retros? Brian Milner (21:29) Yeah, it's, you know, I sound like a broken record. It's the, it's time to inspect and adapt, right? You need to find the truth of what's behind that resistance, right? What's causing the team to not want to do retrospectives. And, and if you're a scrum master, you know, that, that could be a hard look in the mirror for yourself to kind of look and say, well, maybe I'm not doing a great job facilitating this. Maybe that's the root cause of this. Or maybe there's mistrust on the team. Maybe there's some safety issues. Do we feel safe enough to say things that actually went not so well here? Sense of fear. Or maybe the root cause is it just doesn't matter. It doesn't feel like it matters to anyone on the team. It kind of feels futile and that we're just saying the same things every time, but nothing's actually changing. So I think there's different solutions depending on what that root cause is. And I think that's where I'd probably try to focus is if it feels broken, that's the symptom. What's the root cause of it? Why is it feeling broken to everyone? And then we can come up with a plan for what to do. Mike (22:31) OK, that's good. Inspect and adapt at a meta level, right? mean, why is our retro broken? Inspect and adapt over that, and then inspect and adapt within the retro. So for somebody who's listening today, I want to start to wrap this up. I know we're kind of at the target limit for our podcast episodes. For somebody who's listening right now and maybe is thinking about or has skipped retros, maybe wants to get back to it, are there any things you'd like them to know? Brian Milner (22:35) Yeah. Mike (22:57) What takeaways would you give people as we start to wrap up here? Brian Milner (23:01) Yeah, I think that some of the big takeaways are it's important to always inspect and adapt no matter what we're doing. And that's what the retrospective is, is a chance every sprint to actually inspect and adapt. It's just a tool, right? It's important to understand the retrospective. There's nothing magic there. It's a tool. And we always say, know, individuals and interactions over processes and tools. it's not that that's a magic thing. It's a tool. But if the tool isn't working for you, then inspect and adapt on it, change it to make it work. If you feel like you've lost sight of the job the tool is meant to do, that's a big problem. And that's something that maybe should be a focus not just for you personally, but for the team. Does everyone understand what we're here for, what the purpose is, what we're trying to do with this, and why this is an important use of our time? If not, then Again, maybe you're asking me to go through something that right now is painful and I don't understand why you're asking me to go through it. A lot of these things, when we put together our Better Retrospectives course, we try to address a lot of these common kind of concerns behind why people might skip a retrospective. And as I said, there's various cures to various diseases and you have to be able to really diagnose it. and get to the heart of it before you can apply the proper one to it. Mike (24:23) You mentioned you're doing a webinar. you tell us about that so I can put that on my calendar? I want to join that and listen. Brian Milner (24:29) Yeah, absolutely. And anyone listening can. doesn't cost you a thing. It's a free live session we're going to have September 24th at 9 a.m. Pacific. So 9 Pacific, 10 Mountain, 11 Central, 12 Eastern. So it'll hit right around lunchtime if you're on the East Coast or first thing in the morning if you're on the West Coast. But yeah, it's going to be September 24th. We call this webinar, your fast track to a fresher retrospective because that's the idea. want to try to freshen it up. We want to try to give you some practical concrete ideas in just a short little 20 to 25 minute session. We want to give you some practical steps and things that you can apply immediately and take advantage of. And we're also going to give time afterwards for open Q &A. So if you have a question that's You have a burning question about retros. You feel like you have a situation you need help with. Yeah, bring it to that session and you can ask us. we're not going to be able to get through every question, but we'll be able to get through a good handful of them and try to deal with the things that we think are going to be the most popular questions there in the group. Mike (25:41) Good. I just put it in my calendar and notice it's September 24th is National Punctuation Day. I think the National Punctuation Day celebrations are at the bar that night. that shouldn't conflict with participating in your webinar. Brian Milner (25:54) Is there a sub group that has a party for celebrating the Oxford Comma during this National Punctuation Day? Mike (25:58) You Probably I want to see who is out celebrating National Punctuation Day. So I'll have to have to start looking for that look for look for the parties but Brian Milner (26:08) You I don't know who it is, but I know they are celebrating it! Exclamation point, exclamation point. Mike (26:15) With a few exclamation points. So thanks for letting me on here to talk to about retros, Brian. I learned a lot. I'll turn it back over to you. Brian Milner (26:23) Yeah, no, this was a great conversation. I appreciate you coming on and kind of driving this a little bit for us, Mike. yeah, just a reminder, we'll say that again, September 24th, at 9 a.m. Pacific. You can go to the Mountain Goat website and we'll put a link in our show notes as well where you can kind of find out more information about it and put it in your calendar. Mike (26:45) Perfect.

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 [email protected] 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. So two days of your sprint, you've got half the day for meeting, two out of 10. And the other days, you've got 15 minutes every day. So yeah, there's a lot of those 15 minute meetings, but they're just one a day. And otherwise you have the entire rest of the day to do whatever you need to do to build. So percentage wise, it's actually a small percentage of the total time that you have to work in the course of two weeks. ⁓ If the meetings are not being kept in their time boxes, Cort Sharp (07:32) Mm-hmm. Right. Brian Milner (07:55) then that's the issue, right? If we have a daily scrum that goes for an hour, yeah, I would feel like that's a beat down as well. That's not what it's intended to be. Cort Sharp (08:06) Right, right. And I've also heard the other really common complaint is about the daily scrum of, I understand it's only 15 minutes. I understand that it's a check-in. There's been, I've heard complaints about other, or seen complaints about other meetings where the point of the meeting isn't really well understood across the team, which I think we'll get into a little bit later. But specifically about the daily scrum, the biggest complaint I've seen is, okay, it's 15 minutes, but is it actually really only 15 minutes of your day? And again, same buddy of mine, same friend of mine who threw this out to me, and he was like, so let me paint this picture for you. I get in the office, let's say at 9 a.m. I sit down, I eat. respond to a few emails. look at my emails, I check that out until about 9.30. Our daily standup is at 9.30. Our daily scrum is at 9.30. I have to do minimal work because I can't get into any deep work. I can't get into any major thought work in that first 30 minutes. So I can't really do a whole lot there. Maybe I'll grab a cup of coffee and hang out. That's what most of my days look like. 15 minutes. And then there's always 15 minutes after that 15 minutes to kind of coordinate with whoever needs to, whoever I need to work with to get stuff done, to help remove bottlenecks or anything, which is totally fine, right? We encourage kind of that 16th minute, so to speak, outside of it, but the meeting officially ends at 15 minutes and unless you need to coordinate with someone else, you're free to go, right? So he's like, okay, there's normally another about 15, maybe 30 minutes. So that takes me until about 10, 15. Well, lunch is at 11, so I got another 45 minutes of nothing. Can't really do a ton of work, and that's basically my whole morning just gone, right out of the gate, right? So it's a 15 minute meeting, but in my friend's world, it's a lot more than 15 minutes. ⁓ I know what I would say to that. I'm curious what you would say, and then I'll share what I would say to that. Brian Milner (10:02) Yeah. Okay. Yeah. I'm going to say something that may blow people's minds. What if you don't have the daily scrum first thing in your day? Right. Maybe what the issue is here is the time of your daily scrum. If it's at 9.30 and that's messing with your day because you can't really get anything done before that. And then afterwards you're spending more time. So it's taken time and then there's not enough focus time before lunch. so you feel like half your day is gone, well, what would happen if it was the last thing in your day? What about if you ended the day with a daily scrum? What about if you did it first thing after lunch? There's nothing that says it has to be first thing in the day. The team can decide any point of the day to have the daily scrum, and I encourage the team to experiment with it. I've had some teams before who Cort Sharp (10:48) Right. Mm-hmm. Brian Milner (10:58) really love end of the day daily scrums because they felt like at the end of the day, we check in with each other. We get together and say, all right, what happened today? Right. And they can all, it's all fresh in their mind because they just finished the day. They can talk through it all. All right. So what does that mean for tomorrow? All right. When we come in tomorrow, we're going to do this. And one of the things that allows is if you have, most of the places I've worked, Cort Sharp (11:02) Hmm. Mm-hmm. Brian Milner (11:24) You have developers who have sort of different time schedules. Some people will sleep in and come in late and work late. And other people like to come in really early because they like to avoid the traffic. If you have that kind of situation, if you put it towards the back part of your day, then when people come in in the morning, it doesn't matter what time they come in, they have a big chunk of focus time, but then they can dive in and do things. to me, your friend's problem is more about Cort Sharp (11:32) Mm-hmm. Brian Milner (11:50) that interrupting the block of concentration time and it just needs to be moved to a place where it doesn't, you know, kind of split that block of focus time. Cort Sharp (11:54) Mm-hmm. That's a much better answer than I gave him. I just said, well, what else would you be doing in your morning? And he said, well, probably, you know, putzing around, checking email, doing nothing until lunch anyways. ⁓ Right, right. Brian Milner (12:06) Ha ha ha! Well, there is always that, right? mean, just because you've got the opportunity to have focus doesn't mean you're going to focus, but that's a whole other set of issues, right? Yeah. Cort Sharp (12:24) Right, yep. And really, I guess my additional answer to him was also, when you're working in an organization, you're making a reciprocal commitment to that organization to say, I will get this amount of work done, you will give me this type of compensation, and there will be communication between everyone. ⁓ And to me, the Daily Scrum is that communicative part, maybe not necessarily with the organization as a whole. Brian Milner (12:44) Right. Cort Sharp (12:51) but you're still communicating with your team and you're getting on the same page, you're getting aligned so that you all can meet your reciprocal commitment. So really, is the daily scrum for the team or for the organization? I think you can make an argument for either, but at the end of the day, it's for everyone to get on the same page so that we can move forward, which you were going to say something? Go ahead. Brian Milner (13:12) No, just going to say, part of that as well is just, this is some of the stuff that we talk about in our working on a Scrum team class that we're launching here at Mountain Goat Software is really these kind of more subtleties of how the team works together. When you take a Scrum Master class or something like that, you'll learn that, it's a 15 minute meeting and there's a time box. You may not hear that kind of thing of, well, what works best for this team? Maybe it's the end of the day. Maybe it's the middle of the day. Those are the kinds of things that we try to focus on in a WoWs class is what's the best way for your team to actually do this thing and actually make it successful. ⁓ One of those other areas that I think is kind of a classification of problems is that classification of things and just kind of general process confusion. Cort Sharp (13:49) Mm. Mm-hmm. Brian Milner (14:00) You know people who just don't understand You know chunks of the process or why things are done a certain way or how to do certain things What what kind of issues have you heard along those lines? Cort Sharp (14:01) Right. I cannot tell you how many times I have heard and seen and had conversations with people about velocity and how velocity, some piece of after it's explained to them, they totally get it. They're on the same page. That's all good. Then they run into the issue of explaining it to their leadership. But the understanding of velocity is that it's a changeable or it's a metric to compare teams. Brian Milner (14:21) Ha Cort Sharp (14:41) And I'm on team A and we have a velocity of 20. You're on team B. You have a velocity of 30. Someone looks at that, bigger number, better, right? Brian's team is better than Court's team. No, that's not what it is at all. That's not how it should be used. That's not how it should be handled. That is a misuse of the process. That is a confusion point on what velocity actually is. Velocity, I guess we'll explain it here. Brian Milner (14:52) Right. Cort Sharp (15:06) Velocity is just a measurement of how much one specific team gets done in a period of time. That's it. How many points? And points are all relative. So story points are relative. They are not the same from one team to the next. So therefore, your velocity cannot be the same from one team to the next or comparable from one team to the next. You might have the same velocities, but it's not like saying, OK, my US American dollar is the same as your US American dollar. Those are two very similar, those are the same exact thing. Those are very comparable. We're working with different types of measuring is really what it comes down to, right? Brian Milner (15:43) Right. Well, and I get the confusion because Mike's phrase is, estimate size, derive duration. So when you start to say, well, a story point is a measure of size, not time, you sometimes get pushback from people to say, yeah, but you're eventually going to translate it into time anyway. And you're right. We are. We're deriving duration from it. But the split we're trying to make there is when we estimate, right? When the developers are doing the estimation, we don't want them thinking in terms of time. We don't want them to make that process forward leap to say, well then the story point equals this number of hours. So let me do the calculation in my head and figure out how many story points this is gonna be. I say this in class. If your organization has a conversion chart like that, Cort Sharp (16:12) Mm-hmm. Brian Milner (16:33) a story point equals this number of hours, you're gonna have to convince me and explain to me what benefit there is of doing that. Because I have yet to hear anyone say, oh, well, we do that because it gives us this benefit. Other than saying because that's the way our tool works, right? Our tool we use to manage our process or whatever takes it in this way. And so we have to make the conversion so that we can use this tool. Cort Sharp (16:42) Mm-hmm. Right. Mm-hmm. Brian Milner (17:01) Now the problem is the tool is driving your process. But other than that, there's not really a benefit that anyone can show me for making that conversion, because what the developer ends up doing is estimating in time. And if they're going to estimate in time, wouldn't it be easier just to say, our estimate is in hours rather than story points? ⁓ It's six hours to do that. It's not one story point. ⁓ Cort Sharp (17:19) Mm-hmm. Right. Right. Brian Milner (17:26) That's what I encourage people to do. the confusion comes from the fact that we do make that duration, we do drive the duration eventually, but that's for the long range forecast. I mean, we say very clearly in our other classes, but we talk about this in the worst class and the working on a scrumpting class, that when you're estimating something, you're thinking in terms of size, you're thinking in terms of risk. comparative to other things. And there's really only two reasons that we would use Story Points. One is to make those longer term forecasts, but the other is to help the product owner to know the relative cost of things so they can prioritize. But the thing you're mentioning, Core, is to use it as a performance metric, and that's where people fall into, I think, a big trap. When you use it as a performance metric, it actually destroys the other two reasons. Mike says this, we have a good thing going with the other two reasons. Organizations want to be able to forecast forward. Organizations need the product owner to be able to know the relative cost of something so they can prioritize. Those are good things. So why go in and destroy it by also trying to use it as a performance metric? Because those two things are needed still. And we won't have a way of doing those. Cort Sharp (18:24) You Right. Right. Mm-hmm. Right. Yeah, totally. I agree with that. I don't really have anything to add. I you just kind of knocked that one out of the park there, Brian. Good job. Brian Milner (18:48) Yeah. Yeah, no, mean, velocity, some of these, part of it's, you know, these are all new terms for a lot of people as well. And so you hear terms like velocity and think, oh, what does that mean? And, and I get it, you know, if you're a manager and you're not really familiar with this kind of stuff and you hear the term velocity and you think, oh, that's the speed of the team. Well, yeah, it is the speed of the team. Right. And if it's the speed of the team, why can't I use that to judge one team against the other? Because it's like using, um, you know, Fahrenheit and Celsius. I mean, it's Cort Sharp (18:56) Right. Brian Milner (19:18) metric and imperial. They're different measures. And so one number doesn't equal the same thing as the other. ⁓ Now, there are some scaled frameworks like safe that we'll try to level set across teams by having a little cheat sheet saying, hey, this is an example of a five-point story. This is an example of an eight-point story. So that the teams can maybe relatively compare against the same definitions of Cort Sharp (19:25) Right? Right. Mm-hmm. Mm-hmm. Brian Milner (19:45) sizes. ⁓ But I gotta say, even there, the teams are going to be off. The teams are not going to be perfectly aligned. That's the only thing that you can really do to try to align those. But they still have their own conversations. They still reach their own conclusions. And so the scales aren't going to be perfectly aligned no matter what you do. Cort Sharp (19:46) Mm-hmm. think even more importantly beyond they have their own conversations or I guess more fundamentally, not more importantly, more fundamentally, is that they have different people on different teams. You have different skill sets, you have different abilities, you have different people working on different stuff. I think I've programmed a little more recently than you have maybe, or it might be vice versa. I know you've recently just built a website again. But I would probably wager my programming skill set in like, I don't know, Ruby on Rails is probably a little, I got a little edge up on you right there, right? So if we were on different teams, Court's on this team, Brian's on that team, how can we possibly compare this different skill sets to each other and expect the same result, the same speed, the same pace? Brian Milner (20:37) Yep. Yep, definitely so. Cort Sharp (20:55) You were talking about, oh, it's like comparing using Fahrenheit and Celsius. The first one that popped into my mind was miles per hour or miles and kilometers per hour, miles per hour, kilometers per hour. Right. Speed in different cars. And then even beyond that, I guess, building on the car analogy, that's like comparing a high end Ferrari to my little first car ever, which was a Saturn Ion little beater. Could barely get up to 60 miles an hour thing. Those are two different cars. They're two different skill sets and they require two different viewpoints to even be able to compare them. There are comparisons you can make, know, four wheels, steering wheel, whatever. But at the end of the day, one of those is going a whole lot faster and it was not my first car. I can tell you that. ⁓ Brian Milner (21:39) Yeah. Yeah, no, I think that's a good way to compare it as well. What about things that have to do, and I'll kind of combine some thoughts here, but maybe what about things that are kind of more role-centric or even just how the team works together? What kind of issues have you heard people mention recently in those areas? Cort Sharp (21:49) Mm-hmm. So managers, for one, what is the role of managers within Scrum? What's the difference between a product owner and a product manager? Is there a product manager? Does that person even exist? Do we just need to fire all of our product managers or turn them all over into product owners? That one's very common. But I think another really common one is when does the Scrum master step in? And the first time I took my first scrum master class, I can't say first time I took one. I've only officially taken one. but I've been in, if you look at the title of a podcast episode, a couple, couple episodes ago, a rough estimate of a billion, scrum classes. Laura, Laura, Laura Kendrick and I have been in a billion scrum master classes. That was, that was the fun conversation we had, but. I made that that I needed that question to answer to help me kind of grasp what is this new role? This is not a very traditional typical thing that you see within organizations of the Scrum Master. Do I as the Scrum Master, do I help estimate? Do I help prioritize the backlog? What do I do? Am I am I a team lead? Is everyone trying to talk with me on the daily stand up and is it my role or my job to hold? take notes, hold people accountable to what they're saying? Or is that kind of just my job to say, okay, cool, we did it, we're good. I facilitated this meeting, I put it on all your calendars, you showed up and do your thing, I'm out, see ya, right? So I think the Scrum Master role as a whole, there's a bit of confusion on that and product or project managers, right? How do we manage those or handle those? Brian Milner (23:43) Yeah. Well, the other titles, no matter what other title that you have, first of all, let's separate out. This is part of what people need to understand. Do not confuse job title with scrum roll, right? Because you can have, let's say I'm a project, I'm hired as a project manager, but... Cort Sharp (24:00) Hmm. Brian Milner (24:07) now I'm gonna be on a Scrum team, I could be the Scrum master on that Scrum team. Does that change my job title? No, I'm still hired as a project manager. So that's kind of the thing that people need to understand. You don't have to have the job title Scrum master or now we're doing Scrum, so now we got to fire our project managers and hire Scrum masters, right? That's not necessarily the case. It's a role on the team. ⁓ So that being said, Scrum defines three. Cort Sharp (24:15) All right. Mm-hmm. Brian Milner (24:33) It defines Scrum Master, Product Owner, and Developer. It doesn't define any others. It doesn't mean you don't have them. Mike has this phrase that I love. says, the Scrum guy doesn't mention tacos, but it doesn't mean we don't have tacos. ⁓ The one I like to say in class is it also doesn't define a CEO. But I bet you have a CEO. I bet your company has a CEO. Cort Sharp (24:47) Right. Brian Milner (24:58) It's not saying that you don't need these other roles or that there's no place for them in an organization using Scrum. It's saying Scrum is going to define for you how a single team works. And if you have a product manager, maybe that's more of a scaled thing of how we manage that product across multiple teams. If you have project managers, maybe that's about coordinating information across teams. If you have business analysts, maybe that's helping product owners to write stories. Maybe they are a product owner. I don't know. If you have managers, managers are usually not on a Scrum team unless they're really expert at doing a certain skill. Sometimes I'll see managers who are developers on a team. But the power dynamic is a weird thing on a Scrum team and that's something to be careful of. If you do have someone who is a manager of any kind on a Scrum team, I would, if at all possible, try to make sure that they don't have any direct reports that are also on that same team. They can be on another team with other people that don't report to them, but if you have them on a team with people that directly report to them, now you got this weird power dynamic within this team that's supposed to be a team of equals, but it's not a team of equals because one person's going to fill out a... Cort Sharp (25:56) Yeah. Mm-hmm. Brian Milner (26:12) performance report on me. So how safe do I feel to say I made a mistake around a manager who's gonna put that on my performance report? That's the danger. ⁓ But yeah, I think you're gonna have any of these other roles. And as far as the Scrum Master is concerned, when does the Scrum Master step in? Well, let me ask everyone listening to think about this question. If you were a parent of a child, when do you step in if you have a child who's doing something that could be harmful? Cort Sharp (26:21) Right? Right. Brian Milner (26:39) Think about this, I didn't tell you what age the child was, right? If you have an infant, you're gonna step in a lot quicker. You're gonna protect them a lot more. If you have a teenager, you might give them a lot more leash and say, hey, that's your responsibility, right? You know kind of how to do this. And if they insist on doing something a way that you don't think is the right way, Cort Sharp (26:42) Mm-hmm. Brian Milner (27:04) a certain point as a parent, you have to just say, you know what, this is their lesson to learn. And, you know, they need to have the, I believe very strongly as a parent that you have to really defend your kids' rights to make their own mistakes. And I'm not saying developers are kids, or I'm not saying that, you know, you're, as a Scrum Master, you're the parent of the team. Please don't interpret it that way. But I am saying there's a parallel to this to say, Cort Sharp (27:09) Mm-hmm. Right. You Brian Milner (27:29) As a scrum master, knowing when to step in is an issue by issue decision. At this instance, how harmful will it be if they do this thing? Is this a kid running out in front of a truck coming down the street? Well, I'm gonna stop that. ⁓ Is this, hey, don't touch that plate, it's hot. I have told you 50 times, don't touch that plate, it's a hot plate. Cort Sharp (27:35) Right. Right. Brian Milner (27:52) Okay, well hey, maybe it's time for you to touch that hot plate and understand that, hey, next time I'm not gonna touch that hot plate, you know? Cort Sharp (27:54) Right. I totally agree. I'm a little more, and I understand I'm a little biased in this, but I'm a little more of a fan of the Scrum Master. The best or a good analogy of a Scrum Master is like a coach on a team, like a sports team is what I'm saying. And the reason I'm biased, right. Brian Milner (28:12) Gee, I can't understand why that would resonate with you. Cort Sharp (28:16) Who would have thought? I am a, well, recently, I'm a little hiatus right now, but I am a swim coach, head coach, and I think the parallel there is just much easier for me to grasp because think of a coach. You are supporting your team. You're stepping in when needed. You're talking with, whether it's officials or referees or someone that's a little higher up, has a little more authority. than you or your team has in a moment. You're not being disrespectful to them, but you're just communicating, you're conversing, you want to get their understanding and you want to communicate that to your team and work within whatever kind of scope is set there. You're working within the scope of the rules. So I like to view that as kind of like, here's the general organization rules that we follow and standards and practices and all that stuff. But I'm not the one, me personally, I'm not the one. Brian Milner (28:48) Yeah. Cort Sharp (29:09) jumping in the water and doing the races, right? I'm not the one out there on the court, dribbling a ball up and down. I'm not the one out there on the field tackling people, right? I'm there to help the team formulate a plan, help the team execute that plan and help the team really just do what they can't or remove as much of their stress as possible so that they can only focus on doing their job, which in the coaching space is Brian Milner (29:15) Yeah. Cort Sharp (29:36) sport coaching space is let the team go out and swim, let the team go out and play football, let the team go out and play basketball or baseball or softball or whatever it is, right? Let them do their thing. You're there to help them and make their day on game day on meat day as easy as possible and as seamless as possible for them. So there was there was something that you said there to Brian that kind of got my gears gears turned a little bit. Brian Milner (29:55) Absolutely, Kreen. Cort Sharp (30:02) You were talking about how the kind of power dynamic, if like a manager is on a team and someone reports to them, there's that power dynamic there. But you said that everyone is on an equal playing field within Scrum. we're all on the same level within our team. We might have different roles, but we're all on the same level. And that kind of got me moving into like, what have you seen that one kind of helps establish that we're all on the same team, we're all on the same playing field, we're all working together, you I might be the product owner, so I might have a little, or I do have guidance over here's the direction we're gonna go more so than maybe the Scrum Master does with the product development itself. But how do you kind of build that trust within a team to be able to say, yeah, I see you, Cort, as an equal contributor here, even though you're the one saying, We're going to do, we need to do this, this, this, and the other thing in the next two weeks. cause I see a lot of, I see a lot of questions about that. see a lot of struggles with that. And I think that's a very common issue that a lot of people face within a scrum team. Because again, it is so different from, I report to my manager. You don't report to your scrum master. You don't report to your product owner. You sit down and have conversations with them. So how do you, how do you kind of foster that and facilitate that? that type of environment. Brian Milner (31:25) Yeah. Great question. And like the kids used to say a while back, there's the rub. You know, that's kind of the key point there. There's a thing we say about Scrum where we, a lot of trainers and coaches will say this, Scrum is simple to understand, difficult to master. And that is precisely what's meant by that. And that's kind of some of the stuff that we try to capture in this working on Scrum team. Class is is that difficult to master portion because? You know, how do you how do you gain trust from someone else? well That's not in the scrum guide, right? I we're not gonna be able to you know, look that section up and say here's the rules on how you You know start to trust someone else that you're working alongside That's a difficult thing How do you do it? Well, it takes time You know, it's like a any kind of any other kind of relationship you have with another human being, you can't walk in from day one and say, hey, we're going to now have this deep trust with each other. You have to extend it and you have to earn it. That's the way that it's built. And that has to happen over time. You have to display that I have trust in you and I'm worthy of your trust. So when you put your trust in me, you can count on me. I'm going to be here and I'm going to do what it is you expect me to do. That's really the only answer that works for that. it's difficult. is the human working dynamic, I think, is the undervalued kind of glue that holds a lot of this other stuff together. ⁓ Cort Sharp (32:52) Yeah. Mm-hmm. Brian Milner (32:55) And it's that kind of stuff that a good scrum master, I think, can really make an impact on because, hey, they're not just going to know a time box. That's kind of just Scrum 101. But they're going to also know, well, what happens when I have two team members who get into a big conflict, who disagree? My hand's off, and I just let that run. And all of a sudden, now we have a team that splits, that fractures along that line. Cort Sharp (33:05) Right. Right. Yeah. Brian Milner (33:23) Or do I get roll up my sleeves and get involved and have the skills to help them navigate that conflict and come back as a team without resentment, without losing trust in each other, but really working honestly with each other and being productive when we come back. That's the difficulty. And like I said, that's something we tried to capture when we kind of created that working on a Scrum Team classes. Cort Sharp (33:23) Right. Brian Milner (33:48) And what are some of those more subtleties of nuances that really are the heart of whether the team is going to work or not? Cort Sharp (33:57) Right. think even, even beyond just what do these look like? I think the way I view a working on a scrum team is it's for everyone on a scrum team, right? It's not just for scrum masters. It's not just for product owners. It's not just for developers. It gives you a big picture. Excuse me. Sorry. It gives you a big picture of how, how effective you can truly be when you are. Brian Milner (34:18) Yeah. Cort Sharp (34:25) working together on a Scrum team, right? You were talking a little bit about the human working dynamic or nature, one of those. And as soon as you said that, I was like, we should double click into that a little bit. But very briefly, maybe double click into it a little bit of when we work together and humans are working together and not working in siloed environments, not saying, hey, I'm the front end developer. I did my mock up. Brian Milner (34:31) Yeah, yeah. Cort Sharp (34:52) I'm out, I'm done. Figure it out everyone else. you're, struggling with your database stuff. Tough. I'm done with my thing. I'm going to sit back and sip a, sip a cool lot on, on Tahiti's beaches or whatever. Right. We're not doing that. We're, we're helping each other out. We're working together and we're saying, okay, cool. You're having database issues. I don't know anything about databases, but maybe I can help look up some stuff or I can find some. help you out in some way that isn't inhibiting you from doing your job. But it might not be like doing it. It's definitely not doing your job for you. And it's not like it's a, I know everything about databases or I know enough about databases to be able to get by. It could be even as basic as, you run into this error code. Cool. I'll look that up for you and send you the results and save you a little time, hopefully that way or something. But it's that team collaboration, it's working together as a team. I like the perfect example, which I'm pretty sure we talked about this in working on a Scrum Team course as well, of developers and testers working together in tandem and saying, instead of, we like to say, developers finish their code and then we throw it over the proverbial wall. And all right, testers, you got to catch it, figure it out. and then test it, developers maybe sit side by side with testers or hop on a call, not too dissimilar from what we're doing here, just hop on a call with each other and say, let's figure out the verification that the password meets the requirements. Okay, cool, tester, you want to write up the tests, I'll start developing or working on the code for it. Awesome, here's my code, here's my thought process. Do you have any thoughts, Tester? Do you see any edge cases right out of the gate that I should keep an eye out for or work on? I think that is the bigger picture that working on a Scrum team really highlights and really focuses on and allows a lot of people to kind of open their eyes a bit more and see the forest through the trees, so to speak, to be able to understand here's the value and here's what it actually means to be working on a Scrum team rather than just here's my role. I'm gonna go do my role, do my thing and see everyone else figure it out. Brian Milner (37:08) Yeah, not that it ignores the basic components and the ground rules that help us, but it goes beyond that to say, how do you actually make this thing work? So yeah, that's a great point. Well, this has been really useful. I really appreciate you taking time to do this, Court, and coming back. And I'm sure we'll do this on a periodic basis, just to check in and see, hey, what are you hearing now? What are the hot button issues now? So. Cort Sharp (37:18) Absolutely. Yeah. Yeah. Brian Milner (37:32) Thanks for sharing that and keeping your ears open and continue to do that so we can do more of these. Cort Sharp (37:39) Hey, happy to Brian always always fun just seeing what's what's going on out there. What conversations are are being had. And I hope this actually like help someone. Right. I hope this this helps solve either clears up some confusion about, know, maybe what the daily standup is for, what the daily scrum is for, who it's for. Hopefully it doesn't add more confusion. But if it does, you know, you know where to go. Right. Brian Milner (37:59) Hahaha. Exactly, All right, thanks, Cort. Cort Sharp (38:05) Yeah, thanks for having me.

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 [email protected] 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 were things that could not have been foreseen or things that we could not have planned in advance. And how many of these things are things that really were just kind of urgent pop-up day by day, we've got to handle these things as they come in. And don't take for granted, I don't think would be my advice to people that all the things that people are requesting of you are kind of urgent day by day things. There's probably a lot of those things that could have been foreseen and could have been planned. But it takes kind of that after action of retrospecting and trying to figure that out to know the difference. Kert (07:34) Beautifully put, I totally agree. Brian Milner (07:37) Yeah. So Kert, what are some of the other big challenges that you've heard from people in the shared services space when it comes to just using Scrum? Kert (07:45) Well, one of the biggest challenges that I've seen and one of the things that I think is a great solution I heard from one of my mentors, Kevin Rosengren, who worked at Capital One for many years. I worked with him at Applied Frameworks and he's now an airline pilot. He loves to fly. And so he's back doing that commercially. But I worked at Mission Health in Western North Carolina for, I was a contractor there working with the application support team. And I kept using the word intake management. intake management and Kevin got really his kind of the back, back, hairs in his neck kind of bristled and his hackles went up and I'm like, come on, Kevin, what's, what's wrong with intake? And he said, intake implies passivity. You're just kind of standing there waiting for things to come at you. He says, I want my product owner to be proactive. I want them to have a vision, a mission. want them to be out in front of the problems. And so I think one of the biggest challenges for shared services is really, taking ownership of the team. And really be a financial custodian for the investment that the company's making in that team and being more proactive in Kanban. We have this term called shaping demand. And this idea of shape demand implies proactivity. So I'll give you an example. was it Collins aerospace working with a middleware team and they did some demand analysis. They kind of diagnosed their backlog, what's in it. And they, they started to realize they weren't tracking an important backlog item. speaking of kind of unplanned work, there are people with ask him for advice or consulting and they realized over a period of weeks or months that a lot of their capacity was kind of leaking or going out via these, just these consulting hits that they took. Give us advice on this, give us advice on this and it may be three hours here, four hours there, but it would add up and they realized, Hey, we can get more active. But we create a knowledge base. If we have some protocols about how we receive this request, if we make them fill out a form. So those are some. some aspects of really taking ownership of your service and requiring certain, you could say, information or maybe levels of respect coming from the requester that begins to help you feel like you have more power than you might have thought last week or last month. Yeah. Brian Milner (09:55) Yeah, that's a good distinction because I agree there is sort of this reactive nature sometimes to that work. if I'm a, I don't know, if I'm a backend shared services team and we're fulfilling requests on a daily basis of people to build servers and install things or whatever, it can feel an awful lot like we're just reacting to what people are giving us. So that, I agree, that's a huge challenge of, know, when you're that kind of product owner, how do you come up with a vision? How do you understand, you know, I get those questions all the time, especially if you're in things like sprint goals, you know, those kinds of things. You know, do we have a sprint goal when what we're doing is just kind of taking things in and responding to people? What do you think are the keys to people becoming more proactive than reactive as a shared services team? Kert (10:48) Yeah, that's that I think therein lies the challenge, Brian. I think that's a real challenge because I do think that things come at you and it just feels like you you're a ticket taker, right? You're you're you're just under this deluge of constant work and it's very tactical and it's very kind of, know, it doesn't it lacks sort of that that sense of purpose drive and the ability to say no. Now, some demand is going to be irrefutable, some demand you just have to say yes to. But I think more often or I say There is definitely a category of demand that you should be able to parse through and determine if it's for you and if it fits with the strategic goals that you've been situated, that you've been assigned or your mandate, so to speak. Gosh, it's shifting from, it's kind of like, how do you shift from that fire fighting mode to fire prevention? And I think there's a piece of that is kind of. Brian Milner (11:35) Right, right. Kert (11:37) I call it scrambling up to the crow's nest, you know, in the old pirate ships. And you've got to have at least someone on the team that's looking out and seeing the big picture and understanding the strategic goals of the business and how we as a shared services team can begin to serve them. But I don't have a, it's not easy because, you know, I think when I was a product owner at Amazon in the early days, and there was a very clear, you know, there was very clear missions like let's grow the number of wishlist creators or number of wishlists in the community. And so there was a kind of a clear, you could say marker and a clear direction for what you're up to. You're serving the community. You're doing things to populate the community, get people more connected. I think there's a lot less clarity and you have to kind of hunt for it, I would say. And I think it does take I think one of the challenges for shared services leadership is to be more connected to the business and to recognize themselves as a more integral part of the business and the ability to actually affect business outcomes. I think, so anyway, connecting to the business and getting those shared outcomes in view, think is a part of that puzzle. Brian Milner (12:44) Yeah. Yeah, I think you're making a strong point there because I agree. That's sometimes I think the challenge in that space is you do feel sometimes very disconnected from the business goal because it's not as clear as gain this new set of customers or service this new clientele or anything. It's more support based. It's more infrastructure based. If we don't do our job in that space, then we can't enable the other groups to do what they do well. But that's a layer of abstraction really, even from what the business has as its goal. So I think that's an important point is, if I'm that kind of product owner, I want to make sure that what we do is tied into the business objective and trying to understand fully what it is we're trying to do as a business and how we support that. We talked to, I mentioned a little bit earlier about customers and that being kind of a friction point of understanding customers. And how do you, how does that relate in your mind when you're in a shared services team? Do you, there less emphasis on trying to understand who your customer is if, know, from product ownership, uh, kind of discipline, uh, or, or is it just as important and we were not really understanding what we. should be classifying as our customers. Kert (14:07) I think it's the latter, Brian. I definitely think it's the latter. When I was working with this 50 person division at Mission Health, I Mission Health got acquired a couple of years ago, there were requests coming from every department in the hospital system. mean, there was clinics, there was oncology, there was radiology, there was all this, there was this huge landscape of stakeholders that, again, felt like my thing's the most important. And understanding each customer or segment of the, you could say the market, right? The 10,000 person healthcare system was really critical to sequencing work and shaping work and to timing, determining how to kind of decompose it. And so that was a really vital piece. what, you know, I think about a few weeks before I left Mission Health, there was a really strong move from the leader there, Joel, to create what we call strategic engagement partners, which really were these proactive individuals that would go out into the landscape of the hospital system and begin to profile the oncology clinicians or the oncology physicians. And so by doing that, it started to kind of get them to put a finger on the pulse of the bigger, really the customer, which was a variety of customers, but it also helped them recognize, okay, this quarter we're, As a healthcare system, we're falling way behind in MRIs or radiology services. And so we better give some extra attention to that. So let's ensure that that's part of our goal this quarter. And so it really, that strategic engagement with the customer is, think as critical as it is when you're selling a camera or a car. Yeah. Brian Milner (15:43) Yeah, yeah, that's awesome. That just brings to mind as well then the idea of making closing that loop with your customer to understand whether what you're doing is actually making impact or not. And I think you gave a good example there, but what about if your shared services team is kind of more internal? And like I said, if we're installing servers, If we're installing some big network system or something, and that's what our team does in various places, how do we close that loop in a more productive way and really make sure that the work we're doing, even though it's somewhat repetitive, even though it's abstracted from your end customer, how do you make sure it's actually doing what's needed? Kert (16:26) Yeah, that's, I love that question, Brian. It's a fantastic question. So I live in Canada. moved here, moved here five years ago. There's a data center of excellence, data center of excellence for the government of Alberta. And, the leader of that data center of excellence, a guy named Donnie, he, he came to one of my product owner trainings and he started to kind of put pieces together that I want my 30 person data team to be equipped to not only go out and service, you know, the community of the ministries. there's like 26 ministries. like health, education, kind of like departments here in the US to service them, but also to help recognize that what we're providing is impacting the bottom line of the ministries. And in some cases, it's harder than others. I mean, I'll just like the Ministry of Health Care, for example, if a data center of excellence can go in and be a strategic partner for that data for the health care ministry, they can begin to formulate. Brian Milner (17:14) Yeah. Kert (17:24) a strategic plan for how they use data. They can begin to equip them with dashboards and other information, other data products, and they can tell a story to the bigger organization that's allocating funding for the data center of excellence. So his drum that he beats is he wants his people to be able to go in and engage strategically and be able to tell a story about the impact they have. Now, some industries are so busy and so inundated with work, they just want a dashboard. Be a ticket taker, give me a dashboard, and don't bother me with strategic stuff. And those are much harder to kind of draw the connect the dots between business impact and our efforts. But there's going to be a subset, I think, of requesters or customers that you're going to be able to start to build a relationship and tell a story. And then those customers become indispensable to, they can become part of your testimonial. Brian Milner (17:55) Yeah. Kert (18:15) they become indispensable to you justifying your existence the next annual budgeting cycle, so to speak. Brian Milner (18:21) Yeah. Yeah. That's so good. One of the other areas I'm thinking about as we're talking about this, because there's a lot of content that comes across in the product in our class about the idea that we should be in an experimentation mindset and look at the things in our backlog more as experiments. We're running these things trying to see if they're going to solve the bigger problem. And then if they don't, we find another experiment. Sometimes I hear a lot from people in classes that are in more shared services places that they have a harder time finding how that would fit in with what they do. It doesn't feel like experimentation. feels like, like we've talked about kind of more order taking. So how does that apply, Kert? How do you, how do you, if you're a product owner in that space, how can you take more of an experimentation mindset if you're in shared services? Kert (19:10) Yeah. You know, I love this question. I've never heard this question, Brian. And it's, it's a great question. It's, it's, it's taken me deep down deep, deep thinking about product ownership. I'll throw out my, my, my, I'll kind of expose my thinking and it, cause I don't have, direct experience that I could point to in sort of this experimentation, the application of this mindset to shared services. I can imagine, can imagine if you have a customer that comes and says, you know, Brian Milner (19:14) Hahaha. You Kert (19:39) I want a purple minivan. And you're in that mindset as a shared service provider, you're going to want to discover the underlying need and sort of begin to kind of tease out, you know, what is it that you're trying, what problem are you trying to solve? What is it that you're after? And maybe, you know, we've all seen that famous, you know, iterative incremental picture of, you know, the skateboard, then the, you know, what is the... thing with the handles on it and then the motorcycle and a bicycle. So that evolution of solutions you could say. And I think if you're in that mindset, you're going to say, Hey, I know you want a pink minivan or a purple minivan. Let's start with, you know, this, which is, which is going to move you in that direction, because I know what you're doing is trying to solve this problem. And let's start with that. And let's see, let's see how it goes. You see, you're enlisting the support and partnership of your customer or requester. And so it takes that willingness to kind of be in a. Brian Milner (20:03) Yeah. Kert (20:30) experimental mindset with the shared services provider, I would think. So that's my thought. don't know how that question lands for you, but it's a great question. Brian Milner (20:38) Yeah. No, I mean, I think this is kind of central to what we're talking about here because, you know, I think there are going to be things that, you know, are just needed and there there's not really going to be an exploration of those things. If we have a government regulation that says we've got to do this and you've got to have this in place by this date or whatever, that's That's not up for question. I don't need to run a rice, you know, kind of a prioritization on that because it's needed, right? It's unquestionable. But I think that sometimes it's sort of that line in product ownership of, I think it's very easy if you're a product owner in the shared services space to maybe shift and consider everything as a needed thing, as being an order taker. And if that's the case, then yeah, you kind of, you kind of abdicate your, responsibility in that case of understanding and prioritization and everything else, because you're just kind of giving it to the people who are demanding things from you. And I think that that's there's, there's a balance there. There's a yin and yang. I think because you've got to understand some of those things are that way. And there are some things that are not. And the things that are not, I've got to understand, as you said, the core need behind it. Because it's very easy to have your stakeholders turn you into just an order taker. And if you allow that to happen, your stakeholders will run over you. But you've got to keep that wall, keep that boundary up, I think, if you're a product owner in that space, to be able to say, now, wait a minute. You're saying you need this. Let me understand why, help me understand what's behind this. What is it that you're trying to do and accomplish with this? It's the whole how versus what kind of discussion, right? We have to understand the how behind it, or we have to understand the what behind it so that we can then talk with the team and find the best how. But if we don't go through that extra work, then I think that we just. Kert (22:34) Yeah. Yeah. Brian Milner (22:51) quite simply become order takers and get overwhelmed with the volume that's coming at us. Kert (22:56) Totally agree. And I think data teams are a prime example because of course everyone these days wants a dashboard. Give me a dashboard. I need a dashboard. And the probing and sort of the con I call it a consultative approach. The consultative hat you wear to go in and discover what's underlying that request. And like you're saying, what is it you're really wanting and why and what need are you trying to, you know, kind of achieve there is often I say undervalued. Brian Milner (23:01) Yeah. Kert (23:22) And often, you know, not seen because they're under such a deluge of just, you know, okay, just get them something and make them go away. And I think there's a desire to have, I mean, Donnie wanted sort of everyone in the team, his 30 person team to have that capability or that sort of consultative hat that they could wear. And I think that can come with time, but I do think that there's some people, you know, in that What we recognize was in that 30 person team, there were probably six to eight folks that were really sort of ready to step into the role of product owner. And so I think one of the things that's important in any team, specifically in shared services teams is to recognize there's going to be people or a person or people that are sort of inclined towards, you know, being a great listener, being consultative, thinking strategically and sort of bringing, you know, having kind of, I don't like the word gatekeeper, but sort of manning that front gate and ensuring that what's taken in is well understood and well shaped and all that sort of thing. Brian Milner (24:20) Yeah Yeah, I agree. don't like gatekeeper as well, but there's a judgment element, right? I mean, you've got to apply judgment. And that's quite frankly something that only humans can do is to apply judgment to decisions and understand the story behind the data. Well, this has been great. I really appreciate you coming on and talking about this topic. As I said, this is something I hear questions about quite often in product owner classes, because there's a huge number of product owners out there that are in this space and sometimes feel like the redheaded stepchild. Maybe we just don't fit in. But I think you made a strong case here. I think there's a lot that can apply. Kert (25:07) So, so Brian, I'm really curious when you think about great product owners. I feel like my question to you is, are they made or are they born great product owners? Do you have any thoughts? Like what comes to mind when you think about that question? Brian Milner (25:16) Ha ⁓ yeah, I mean, there's, there's, there's talent and skill, is what comes to mind. And I think that we all have some natural abilities in different areas, but I think we all have skills that we acquire and learn and there's discipline to it. There's rigor to that. There's a process to it. And I mean, I, you know, I think there are our product owners that have talent, ⁓ that are, that's kind of innate. but for me, it's mostly in areas that's, things like communication, right? If you're, if you're a poor communicator, ⁓ you can improve your communication skills, but, ⁓ you know, you see this in politicians and things in certain times. I talk about certain politicians as being just really good communicators naturally. Yeah. They, they've, they've studied communication and understand how to do it better. but they had an innate skill in that area already, or innate talent, I should say, since I'm differentiating between the two. ⁓ But yeah, I think I would lean more towards like maybe 90-10 skill over talent, and that it's, you know, it is a lot of practice and learning and discipline that we just, need to study and know our craft, you know, it's a craft. And I think we have to improve on that and get better at it. But yeah, I mean, in this kind of work, think I wouldn't put too much emphasis on the talent side of it. I think that there is some innateness that can be useful, but ⁓ I kind of lean much more to the skill area. Kert (27:06) Yeah, yeah. So Donnie's got this 30 person team and he suspected there were six to eight that were suitable candidates to kind of go into a multi-week cohort to kind of become sort of more seasoned or sort of competent product owners. If you had 30 people in front of you and you were asked to choose the six to eight that are most suitable for a product owner program, would you have any thoughts around? how you would do that. mean, I'm guessing you probably wouldn't draw straws, but Brian Milner (27:38) No, I mean, I think it comes back to some of the things that we talk about. ⁓ Whenever I go into an organization and try to figure out who's the right product owner for this product, it comes down to a few common things. First of all, do they have the domain knowledge for the product? Do they know enough about that product to be effective, know about the market, the customers, those kind of things? Do they have the availability to do the job? ⁓ Are they constantly going to be involved in other things? Are you splitting this person between 10 teams? ⁓ And then are you going to be able to give them the authority that they need to make the decisions that they need to make in that role? ⁓ if I was trying to decide which is the right person, that would be the rubric I would be using is trying to say which one of these people match best for this product. Kert (28:34) Right on. Cool. Thanks, man. Thanks for entertaining that last topic. Brian Milner (28:39) Yeah.

Even the most capable professionals can struggle in interviews. In this episode, Brian and job interview coach Tali Shlafer break down why, and what to do instead. Overview In this episode of the Agile Mentors Podcast, Brian welcomes interview coach Tali Shlafer for a practical, clear-eyed conversation about how to approach job interviews as a skill, not a personality trait. Tali shares why being great at your job doesn’t automatically translate to interview success, especially in collaborative fields like product development, Agile coaching, and project management. She outlines a straightforward way to prepare for interviews by identifying the real challenges behind a role and building stories that speak directly to them, without sounding rehearsed or robotic. From reframing “bragging” as problem-solving to handling tough questions with clarity and self-awareness, this episode is full of grounded advice for professionals navigating their next move. References and resources mentioned in the show: Tali Shlafer Free Job Interview Tip Vault Tali's LinkedIn Tali's Instagram #93: The Rise of Human Skills and Agile Acumen with Evan Leybourn #111: Adapting to the Future of Work with Heather McGowan Blog: Entry-Level Scrum Masters: Seven Tips on How to Get Your First Scrum Master Job by Mike Cohn AI Prompt Pack for Product Owners & Scrum Masters Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is 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. Tali Shlafer is a certified interview coach who helps high performers turn nerves into clarity and confidence so they can land roles they’re truly excited about. Her practical frameworks—rooted in psychology, communication, and performance—ditch the gimmicks and empower candidates to show up as their best, most authentic selves. Auto-generated Transcript: Brian Milner (00:00) Welcome in everyone. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have Miss Tali Schläufer with us. Welcome in Tali. Tali Shlafer (00:11) Thanks, Brian. I'm excited to be here. Brian Milner (00:13) Very excited to have Tali with us. She is a job interview coach so you can kind of See the direction we're going in here one of her tagline is that she she helps you know professionals get offers they're really excited about and She's got some really interesting insights here because I know in today's world in today's environment There is a lot of shifting going on. There's a lot of transitioning between different places of work. And that interview is always kind of the forgotten portion of it, right? You get past all the other stuff, you get to the point where you're in the interview. So Tali, from your perspective, I know you see and help a lot of people with that portion of it. What are some of the biggest mistakes that people make that you see routinely as you help people prepare for their interviews? Tali Shlafer (01:01) Yeah, absolutely. I think one of the things that you just mentioned where, you know, people really struggling with the interview piece, you do all this work in your job search to update your resume, update your LinkedIn network, all this stuff, and then you get to the interview and it's like, okay, we're close. It's actually the interview is actually a completely different stage than anything else. And one mistake that I often see people making is just the mindset around interviews. A lot of people think, if I'm great at my job, I'll just interview really well. Like I'm a top performer. I'm good to go. But interviewing is actually a skill that's completely separate from anything else we do in the workplace. It requires you to be able to articulate what you've done in the workplace and the results and the impact that you brought in a way that most of us don't have to do in our day-to-day jobs. And you have to do it better than everybody else. So just because you are a top performer doesn't necessarily mean that that translates into your ability. to talk about yourself and talk about your career, especially in a way that resonates with the specific job culture and the specific job that you're applying for. So I think that's kind of the top mistake that I would just from a mindset level, is seeing interviews as something that you're naturally good at rather than as a skill that you can really develop and build in order to set yourself up for success. Brian Milner (02:12) Yeah. Yeah, that's a great point because, know, just because, as you said, just because I'm a top performer in something that I do, have a huge skill set or knowledge area that I'm really good at, doesn't mean that I'm necessarily good at an interview process because it is kind of a whole set of other communication skills that you have to have in that kind of environment. I know when I've talked to people about it sometimes, they feel sort of this, I don't know, dichotomy a little bit back and forth about... I know I'm supposed to plug myself here. I know I'm supposed to kind of brag a little bit, but I also don't want to sound cocky. I don't want to sound, you know, I don't know, just brash or anything. How do you help people or what do you advise people about in that area? Tali Shlafer (03:06) Yeah, and I think this is really common for people who are top performers and people who are very team oriented and collaboration oriented. It's really difficult for those folks to go, hey, I did all this stuff by myself and to kind of put themselves in that spotlight. So it's a very common challenge. It's also very common for folks who are really good at their job and have been doing this for a long time to actually be able to articulate. what that secret sauce is, like why they're actually good at their job, which is part of the challenge. Remind me the question that you just asked. Brian Milner (03:38) No, I'm just, in talking about kind of like how people prepare for these kind of things, the way they communicate this stuff, sometimes it's kind of more this worry about am I being a little too overbearing or brash in how I'm bragging about myself? Will I come off seeming cocky? or overconfident, how do they walk that fine line? Tali Shlafer (04:03) Yeah, I think this is a really big mindset piece where a lot of people who are those top performers and are very collaborative in nature are afraid to talk about themselves and be in the spotlight and kind of take credit where, especially in something like in the agile world or project management, product management, it's a very collaborative space. people are afraid to like, people are afraid to say, here's what I did. And Part of the mindset shift that I really encourage clients and job seekers to have is rather than to see it as, hey, the interview is all about you and the spotlight's on you and you're a used car salesman trying to promo yourself and it feels really icky so we don't want to do it. We end up not doing it at all. Think of it rather as you're trying to help this employer solve a problem. You're on the same side of the table with them. You're essentially a consultant for them. Their problem is... Hey, I've got this role. I have this challenge in my company. I have this opportunity. I have this thing that I need help with and I need to find who's going to be able to help me do that. And so you're essentially being an advisor for them and sharing here's how my previous experiences and what I've done in the past might be able to help you with your challenges. So it's really, it's really a partnership type of conversation where you're exploring, well, what are you struggling with? and how, let me share ways that I think I might be able to help. I think having that mindset is a lot more helpful for people who are more collaborative in nature. I think there's also a part of it that is getting really clear on how your work has actually delivered results. Being really confident, a lot of folks who are more collaborative in nature, which is a lot of people that I work with. tend to really get stuck in the we. So they say, we deliver this, we manage this, we strategize in this way. And then the interviewer ends up losing the thread of, well, what did this person sitting across from me do? What did they lead? What did they manage versus what did they do collaboratively? so getting really clear and even getting some language around how to talk about your contributions with respect to the team. So saying, I led this strategy session or I facilitated the collaboration of this, or I made the suggestion to people who then made a decision. Those kind of nuanced pieces of communication can help us feel more comfortable with actually owning our story in a way that doesn't feel gross. Brian Milner (06:39) Yeah, I think you make a great point there about the partnership aspect of it because having been on both sides of the table there, I know when I was hiring people as a software manager of some kind, the thought is always when the person comes in, you want to hire them. When they've reached that stage, when you finally bring them in, you're excited about the people that you decided to bring in and you're pulling for them. You want them to actually be successful. So I think it's important to keep that in mind too, that they want you to be successful. They want that role filled or they wouldn't have put out the job wreck and all the other things. If you, so let's just kind of talk through on a practical level. If you, you've done the work, you've put out the resume, you've got the call, maybe you've even gone through, well, I guess we should talk about that as well. Kind of the difference between a virtual or phone interview and an in-person interview. Is there a difference in level of prep or in how you, you know. tricks to being more successful if it's virtual versus in person. Tali Shlafer (07:50) I think the preparation itself should be the same. At the end of the day, your preparation should be about what are the challenges that this company, that this organization is facing and how does this role help solve those challenges? What are the skills? What are the top five skills that I need to demonstrate? Hard and soft skills. And in order to show them that I can be the top performer for this role and what are stories that I can share for each one of those skills. to prove that, I have what it takes, I can actually walk the walk as well. I've gotten results in this area before. So the prep work itself in the days leading up to the interview should be more or less the same. I would say the difference between a virtual interview versus an in-person interview is just people's comfort level. I think a lot of people are really comfortable in in-person interviews because it feels like you're actually talking to a human, right? You have a full-size person sitting across from the table from you. So it's a lot more comfortable. And I think even though through COVID, we had a lot more virtual conversations, there's still a very performative feeling element to it when it comes to virtual interviews. So one of my top tips for virtual interviews is please turn off your self view. So if you're in the Zoom call and if you're in a meeting, because it makes people so nervous and self-conscious. So when you get on that Zoom call, that Teams call, whatever platform you're using, make sure you're in the frame, right? Make sure that your lighting is good, all that stuff, and then turn off that camera so that you're not just watching yourself and being super self-conscious the entire time. Because think about it, in what other context in your life, when you're having a conversation with someone, do you have a mirror that you're looking at? Brian Milner (09:36) Right, right, I mean, if you're in their interview room, unless there's a mirror all the way around, you're not really getting that view. And even if you did, you probably wouldn't watch yourself in the mirror the entire time. So yeah, that's a great tip. And I think you're absolutely right. It can lead to being very, very self-conscious then. I think it's, I want to go back a little bit to the prep because I think your tip there is a really important thing is to try to understand the challenges, understand what it is they're looking for. And it just struck me as you were saying that it seems very similar to, in my kind of line of work, I do a lot of consulting work with people. And when I have a client that's a prospective client, it's almost the same thing. where you have to research a little bit about the company ahead of time. If you're doing kind of a sales call prior to the engagement, it's very similar. And I just thought about that. There is an overlap there between that and job interviews because you are selling yourself. You are selling your services to that company. Tali Shlafer (10:36) And a lot of people, here's another mistake that a lot of people, a lot of well-meaning people make is as part of their prep work, going online and finding a bunch of questions that they can then prepare for. So it's a very, I kind of call it whack-a-mole where, hey, let me try to figure out all the possible questions I might get asked and write out answers for those. Brian Milner (10:51) Ha ha. Tali Shlafer (10:59) That might get some people results. And if it's getting you results, that's great. But what I really encourage people to do is really reverse engineer your talking points from the job description, from what you know, even, you know, once you've had the conversation with the recruiter, you know, a little bit more about the position than maybe is even listed on the job description. So compile everything that you know about this opportunity and figure out, okay, what are the most important things for me to be able to articulate rather than just guessing at. random questions that the internet says you might get asked. Brian Milner (11:32) Yeah, that's a great point. I know we all want to get past that and get to the job, but I think there's also an element there of, let's say you do memorize these questions and they just happen to ask you the exact questions you had prepared for. If you don't really have that knowledge, then you're not going to really do well in that job even if you get it. So it's almost a blessing to not get that job, you know, if you didn't know that information, because they're going to be counting on you to do that. And you're not going to be a you're not going to do your job well then. Yeah. Tali Shlafer (12:06) Yeah, and the memorizing piece that you just mentioned is really, really easy for people to fall into the trap of trying to memorize their answers, especially with chat GPT and AI. Everybody's thinking, well, let's use these AI tools to help us come up with interview answers. so we plug in, job seekers will plug in, here's a bunch of questions that I might get. Look at my resume, tell me how can I answer these questions? And it feels safe. It feels like, this very smart robot or technology is gonna say this in a better way than I can. Brian Milner (12:36) you Tali Shlafer (12:40) But it really sets people up for failure most of the time because number one, most people aren't good at memorizing things, right? Most of us don't have to do that as our job. So most of us are really bad at memorizing. Number two, it makes you sound like a robot. It doesn't sound human. You lose the attention of the person who you're talking with. And number three, doesn't when you just memorize answers rather than thinking about it as what are talking points that I can riff off, riff on and kind of reuse and recycle and tell stories with. When you memorize, it puts you in the position of, well, yeah, it's great if they ask you that exact question. And some questions you will get asked, like tell me about yourself, you're going to get 99 % of the time. But for the most part, if you memorize a set of 10 questions and one of those questions gets a slight variation, or they ask a question that's not on there, you end up panicking. You don't know how to think on your feet because you're reliant on your tool. You've used AI or you've used your script as a strategy rather than a tool. Brian Milner (13:42) Yeah, that's a great point. I'm kind of wanting to get your take on this because this is a big thing that I know often comes up in these kinds of interviews is those questions that we all hate to get that you just know, no one ever knows how to answer these things. So I'm just curious how you advise people, you know, the awful question like, you know, give me some of your weaknesses or give me some of the things that you're not good at. How do you advise people to handle those kind of questions when they get asked in interviews? Tali Shlafer (14:14) Yeah, so there are definitely some questions that we tend to hear more often than others, especially when it comes to those recruiter interviews. The tell me about yourself, what are your strengths? What are your weaknesses? Tell me about a time you had to deal with a conflict. Tell me about a time you had to deal with a mistake. Those are pretty common, I would say, in that initial recruiter conversation. It's always an interview in my book. The weakness question I know is one of the that and the tell me about yourself is what really stresses people out. Brian Milner (14:40) Ha Tali Shlafer (14:43) My general advice for the weakness is actually something that I heard Adam Grant, who's an organizational psychology at Wharton share, which is pick something that is real but not disqualifying. So if you're an Agilist, your weakness should probably not be scrum or not be, you know, understanding business requirements. But it could be something like public speaking. Brian Milner (15:00) Ha Tali Shlafer (15:08) Or it could be something like delegating, where, you know, it's something real and it's not... It's something authentic. Authenticity is really, really important, especially nowadays in interviews. But it doesn't stop you from being able to perform well. So what I typically advise is pick a weakness, like Adam Grant says, that's real but not disqualifying. And this is important, and where a lot of people miss out, share what are you doing to actually address it? Because what we want to do, the point of that question isn't tell us what's wrong with you so we can judge you and disqualify you from the job. It's the subcontext of it is do you have self-awareness? Are you somebody who is aware enough and humble enough to know your shortcomings? And are you someone who's proactive about fixing them? and about becoming a better person. So the second part of that answer should be, well, what have you done to try to improve? What are specific steps that you've taken in order to improve? Brian Milner (16:09) Yeah, that's a great response. I know I've heard the traditional, you try to say one of your strengths as, I guess my weakness is I work too hard, like that kind of thing. Which I agree, it's not sincere. If I'm hearing that and I'm interviewing someone, that could disqualify him in my book, because I could think, this person is not going be honest with me. ⁓ Tali Shlafer (16:20) Yeah. or the I'm a perfectionist piece? The most common answer to that question. Brian Milner (16:33) Alright, I'm a perfectionist, right? Yeah, exactly. Well, you hit on the other big one too, the tell me about yourself. How do you advise people to handle that? Do you have a script in mind? you kind of detail out a couple of things? What's important to hit when someone asks you to just tell me about yourself? Tali Shlafer (16:54) Yeah, I'm a big fan of formulas over scripts. So I'll share my formula, but let me share a couple things that derail people. Let's kind of establish what's not helpful. And then we can kind of talk about this formula, which by the way, lots of different career coaches have different formulas. There's not necessarily one that works. It's just pick something and learn to do it really well. A lot of people will go in and start well. I graduated from the University of Washington in 1995, and they give kind of their entire history. And we lose the interviewer right away when we do that. So rather than giving them a chronological history of everything that's happened in your career and asking them, when we do that, we are essentially asking them, hey, here's all this information and data. You make sense of it. You figure out how it's relevant to you. I think it's actually really kind to use a formula to help them understand. Here's everything you need to know about me as it pertains to this role. So taking everything, taking your history and your career through the filter of what is important to demonstrate for this role. So the formula that I teach is sharing a super quick background. Hey, I'm Tali, I've been a project manager for the last 10 years. That's not true, that's not, let me reset that. So I think starting with a very brief. Brian Milner (18:12) You Tali Shlafer (18:16) sentence about yourself, your relevant role, how long you've had experience. Hey, I'm John. I've been project manager for the last 10 years, sharing the three key skills that you need to have in order to succeed at this job. And for each of those three skills, can you list an accomplishment or a metric or a success story? And we're not telling a whole story. We're just giving them here's the highlight reel, here's the headline, and then you'll click into all of those stories later. So quick little background about yourself, three main skills that you've developed that are relevant for this role, and super high level accomplishment to demonstrate those skills. So that's a little bit, that kind of is the first half, and that talks more about your previous experiences. And then in the second half of this answer, we want to pivot it to the future. So the first half is really about the past, it's about yourself. And then in the second half, we want to pivot to the future. what are you looking for in your next role? And hopefully that thing is also in that, that whatever you're looking for in your next role should dovetail really nicely into what they're offering as a company and as, as a, as an organization. What are you looking for specifically in your next role? And why are you so excited about interviewing with this company? And we want to share something really specific that We want to share something specific that feels personal. Where a lot of people go wrong is they'll share something like, I really want growth in my next role. And I'm excited about this team because I know you guys really value innovation. That doesn't really tell us anything. So we want one level of detail lower. So I'm really excited. What I really want in my next role is more leadership opportunities, so opportunities to mentor. And I'm really excited about this particular opportunities because I looked on your website, I looked at your blog posts, I looked at your, you know, CEO's posts that they share on LinkedIn. And I can tell that this is a really important part of your culture is being able to mentor people up into higher positions, right? Getting that specific, and there's not a right answer. I remember when I was interviewing for... out of college, I was interviewing for T-Mobile for an internship. And my answer was, I've talked to a lot of people, I've networked with a lot of people at T-Mobile. And one thing that really strikes me is the fact that a lot of people will leave for local companies like Microsoft, Amazon, and then they come back. There's a lot of people who spend a lot of time here. really does. There's a lot of loyalty and the culture, like I shared things that are specific to the culture and there's not a right answer here. It just needs to be. specific and it needs to be something that when you talk about it you kind of start getting butterflies because that's contagious. Brian Milner (21:07) That's awesome. Well, I want to ask about kind of the other half of the interview or the other portion of the interview as well. They, you know, I often hear people say, you know, you should walk into the interview understanding that it's a two way interview. They're interviewing you, but you're interviewing them as well because you want to know, is this the right place for me? So I can make the right decision about where I'm going to end up. What kind of things do you advise people to ask about or to focus on? What are some things that might expose some hidden things about the organization, warning signs or anything like that that might pop up in an interview to ask about? Tali Shlafer (21:45) That's a really good question. think one thing, it really depends on the opportunity and what you're looking for. So I don't think that there's one magic question that if you ask it, oh, the person's gonna be super impressed. Let me back up. What I really like about what you just said, is the framing of the questions that you ask at the end as a two-way conversation and as a way for you to understand more about the company so you can see if it's a good fit. I think a lot of people, especially in tough job markets, tend to kind of close their eyes and hope they get something and they almost blind themselves to the fact that they need to also do the work to make sure that it's a good fit. Or I see a lot of people who go, well, what can I ask that's impressive? What questions can I ask that's going to really wow them at the end, rather than seeing it as an opportunity to really understand what they offer more? So I would sit down and prioritize what is really important for you in a culture. if getting feedback, if growth is important for you, making sure to ask about, can you tell me about recently on your team, somebody who was promoted or how you helped somebody grow in the company? The best way that we can learn about something is through examples. The best proof that somebody values something is through the examples that they share. So we want to ask, kind of like you hear behavioral questions, you get asked, like, tell me about a time when. You can also use that, figure out what's important for you, and then create. Ask questions specifically about those things. One question that I think can be really helpful to get you to get a sense of what kind of person succeeds on this team and what the team really values is kind of the inverse of that. can you tell me about, can you tell me about what type of person doesn't do well here? Because then if they say, you know, The type of person who doesn't do well here isn't committed to working 60 hours a week. They expect to take their vacations and not be able to unplug. That kind of being able to hear who isn't successful gives you some context around some of their values as well. Brian Milner (24:01) Yeah, that's an excellent question because I agree. Presumably, this is someone you're going to be working with if you get the job. That immediate relationship, think, is going to really be impactful on the expectations, that sort of thing. Yeah, if I'm interviewing and I ask that kind of question, and they do come back and say, yeah, the person who doesn't work 60 hours or anything. Yeah, that's a good sign that maybe this is, I don't know, unless I enjoy working 60 hours a week, that maybe this is not the right cultural fit for me. So that's an excellent question, because I think that would expose some of that behind the scenes stuff, cultural things. ⁓ Tali Shlafer (24:42) And you really want to ask about questions about your dynamic with the manager. So what kind of people succeed under them? Because that's the number one people. I believe I'd have to fact check this, but you always hear that the number one people reason people don't like their jobs or people leave their jobs is because of their boss. So you want to understand you're essentially going on a date with them and you want to understand what is it like to hang out with you for 40 hours a week? Brian Milner (25:05) you Tali Shlafer (25:09) So asking specific questions to really understand what's their working style, what are their expectations, what are their positive experiences, what does feedback look like? Is it a once a year thing? Is it a every time we touch base during our one-on-ones you get feedback? That is really important. The other thing that's important to think about is do you understand the role itself? Like what questions do you have? What gaps in your understanding do you have about the role? Really clarifying to make sure that you know what you're signing up for. Brian Milner (25:40) Yeah, that's a great response as well. I know I remember from back in the day getting told that it's a good kind of question to ask what would success look like? If you really got someone to nail this and you were really happy with the hire and it was perfect, what would be the biggest thing that would contribute to that? And I've always liked that approach as well because it kind of gives you the expectation from the start to know here's what's most important in that manager's mind of what they're looking for. Yeah, just in my memory of interviewing people, would say I've never, I don't think I've ever not hired someone because of a question that they asked at the end, but... I have felt sometimes like when they don't ask questions that they're a little unprepared. Tali Shlafer (26:30) Yeah, and I think it, I think part of the not asking questions, one is being not prepared, not thinking thoroughly about the job. But it's also a little bit of a sense of desperation, like, I've been applying for four months, I don't care, I'm willing to take anything. So I don't have questions, because let me just take any first job that comes available. There's kind of that mindset. And I think it manifests as, I don't have any questions. And I think Brian Milner (26:48) You Tali Shlafer (26:58) People can kind of feel that when you're not critical, when you're not trying to figure out, am I really going to be able to succeed here? People kind of pick up on that and it either looks like desperation or it looks like disengagement and disinterest. We want people not, we don't want to hire the first person off the street who can do the job. We want to hire somebody who's excited to be there and who we know isn't going to leave six months later when they find something better. Brian Milner (27:23) Yeah, that's really good. Well, this has been really enlightening. I think there's a lot of gems in here that I think people can apply. we all find ourselves in that position from time to time of having to interview for things. As I said, even as a consultant, it's an interview when you talk to a potential new client. So I think these are all really great tips for that. We're going to make sure that there's contact information for Tali at the show notes of this so you can get a hold of her. Anything you want to shout out about, any places you want to point people to to get in contact with you? Tali Shlafer (27:56) So for the last few years, I've been posting usually about two short form videos a day to LinkedIn, all the social medias. Over the last couple of years, I've posted over 700 short form videos on social media. I've actually had over a hundred million views on LinkedIn, which is really crazy. Somebody recognized me at the dog park the other day, which was wild. But I created an interview tip-ball that took the best... The most helpful videos the ones that have gone viral received the best feedback gotten people the biggest results in their interviews And I compiled them all in one Interview tip bolt so that's my little thing that I like to share with people You'll see everything in there from how to tell me about yourself To answering why do people ramble and what other mistakes are people making? and also special tips for senior leaders and executives. So that's my little freebie that I like to share out for folks who are interested in the stuff that I'm talking about. Brian Milner (28:56) Awesome, awesome. we will definitely make that available to people in the show notes and links to your socials as well so people can follow you and stay on top of your tips as they come out. So thank you so much for coming on, Tali, and I appreciate you spending some time with us and sharing your knowledge with us. Tali Shlafer (29:13) Thanks so much, Brian. It was a pleasure.

Join Brian and Barnaby Golden as they dig into a surprisingly common roadblock in Agile teams, the underpowered product owner, and how it quietly derails decision-making, flow, and team momentum. Overview In this episode of the Agile Mentors Podcast, Brian welcomes Agile coach and community contributor Barnaby Golden to explore the risks and ripple effects of placing a product owner in the role without the authority to own it. They discuss the stark difference between empowered and underpowered product owners, why availability without authority is a setup for frustration, and how misalignment at the leadership level creates more theater than agility. From trust gaps to political decision-making, Barnaby and Brian unpack the hidden reasons teams get stuck and what it takes to create real, empowered ownership that delivers actual value. References and resources mentioned in the show: Barnaby Golden #104: Mastering Product Ownership with Mike Cohn #3: What Makes a Great Product Owner? With Lance Dacy How to Engage and Help Busy Product Owners by Mike Cohn 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 [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Barnaby Golden is an experienced Scrum Master and Agile Coach with a knack for helping teams truly live Agile, not just adopt it. Lately, he’s been diving into the real-world use of AI—helping organizations, including nonprofits, turn tech hype into practical, high-impact tools with smart governance Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors, we're back. This is another episode of the Agile Mentors Podcast. I'm here with you as always, Brian Milner, and we have a very special guest with us today. We have Mr. Barnaby Golden with us. Barnaby, welcome in. Barnaby Golden (00:14) Thank you, it's good to be here. Brian Milner (00:16) Very excited to have Barnaby here. Barnaby is an Agile coach, also a Scrum Master. He is known to us because he is part of our Agile Mentors community. And he is an active member there and has weighed in on several issues and helped people and mentored people through things there. So we wanted to share some of the wisdom of the crowd that we have there at Agile Mentors. Just a few select people that have really contributed. and giving us some really good advice there with the podcast audience as well. So you guys can kind of hear what kind of stuff is there on the Agile Mentors discussion forums. But we were talking about topics here with Barnaby about what we were going to talk about and he proposed one that I really found intriguing. It was focusing around the underpowered product owner, the underpowered PO. And I think that's probably a good place for us to start then, Barnaby. Why don't you kind of just explain to everyone what that idea is, what you mean by the underpowered PO. Barnaby Golden (01:12) Sure, of course. So in fact, what I'll do is I'll explain it by giving you the opposite, which is what does a good, effective, powerful product owner look like? And I was working for an organization a few years back, it was a publishing organization. And we had the head of the editorial team was the product owner for a particular Scrum team. Brian Milner (01:16) Okay. Barnaby Golden (01:38) And this head of editorial had a lot of power and influence in the organization. They were pretty much a decision maker in terms of the products that the team was building. And I remember a particular conversation where the team was talking to this product owner and the team said, look, we know you want to get this, this release out this week, but we've got some technical debt. really need to fix it. And I remember the, this guy saying, look, okay. I'm going to let me think about this for a second. Okay. I can make the decision on this, which is, yep, you can have your time. I'll communicate with others within the organization. The release will be delayed. And that was such a powerful moment because in that second, the decision was made. The product owner trusted the team, the team completely trusted the product owner. And it felt slick and efficient and worked really well. Conversely, I've worked in organizations where in some way, surprisingly enough, product owner is seen as quite a junior role. So I've seen the situation where you have a whole hierarchy of product people and the most junior role in the product organization is the product owner. And what happens in that scenario is the product owner is powerless to make a lot of decisions. So they have to push them up the tree. And in that situation, the conversation between the team and the product owner is the team says, yeah, we need to do this thing. And the product owner says, okay, give me some time. Might be a day and I'll get back to you. Hopefully I can get in contact with other people within my hierarchy and the flows broken. What's the team going to do now? They're going to maybe find something alternative to work on. It's very frustrating. And you sometimes get the situation as well where the the underpowered product owner will sympathize with something the team is saying, but will not be able to make a change because they haven't got the authority to do the change. So they'll say, yeah, I agree with you. I know what you're saying. This is a really bad idea what's being suggested, but I have no choice. We have a roadmap. We've got to meet the roadmap. Brian Milner (03:45) Yeah, that's a clear picture. I agree with you that those are two stark contrasts. And what I like about the explanation is you kind of highlight the effectiveness of one versus the ineffectiveness of the other, right? It's just, it's such a dramatic difference when that person is able to make the decisions on the spot. go forward, and the team is just free to move as quickly as possible. Whereas the other one, it's just holdups. It's just delays and obstacles, roadblocks in the team's way. So yeah, a really clear picture there. Just as you were talking about this, I was thinking to myself, well, maybe one of the worthy paths for us to go down here and talking about this. is trying to understand a little bit about the why behind it. ⁓ Because I think there's, just in thinking about it, I think there's maybe several causes for this or several things that might lead to having an underpowered PO. What's been your experience? What kind of things have you seen that might contribute to an underpowered PO? Barnaby Golden (04:36) Hmm. I think the main reason, the biggest driving factor behind it is the feeling that the people with the authority to make decisions do not have time to spend with the team. So you've got your head of product or the real decision makers in the organization. They are saying, I can't spend two, three hours a week with a team. I can't go to a planning meeting. got, you know, I'm a busy person. I've got things on my schedule. So they see the product owner role as a stand-in for themselves with the team. And this stand-in has lots of time to spend with the team, which is good. And that's a powerful thing. But at the same time, if they've not got the authority to make decisions, then maybe that time is not effectively spent. Brian Milner (05:41) Yeah, it's almost as if they just want a warm body there. It's a placeholder. You're here as a placeholder for me because I can't be two places at once. I've heard a couple of things that people will frequently point to that a product owner needs to be successful. And there's sort of this dichotomy of these two things that are part of that. And that's the kind of empowered Barnaby Golden (05:44) Yeah. Brian Milner (06:05) product owner that is empowered to make decisions versus having the availability to actually be present with the team. it's always, it seems like that's a fracture point that sometimes causes this because you have the leaders who, hey, I need to make all the decisions, but I don't have the availability. and the people that they know have the availability, they don't want to empower to make the decisions. So they're kind of setting up their product owners to fail. Barnaby Golden (06:35) I think it's a classic example as well with when you want to be an agile organization, you can't just have pockets of agility. You can't just have a scrum team and say, well, that's where we'll be agile in this scrum team. The entire organization as a whole has to think in the agile mindset. And if you want to be able to adapt to change, then one of the ways you're to have to do that is you're going to have to have the decision makers close to the teams that are implementing the decisions. and so you can't have your, your cake and not eat it. If you see what I mean in terms of, you, you can't pick and choose the aspects of agile that you want. need to, as an organization, adopt the whole thing. Brian Milner (07:17) Yeah, that's always one thing I try to tell people as well is when you're selecting a product owner, when you're trying to decide who's the right person to be the product owner for this team, those are two of the things you have to really consider strongly is does this person have the availability to be here with the team and is this person empowered to make decisions? I've run up against leaders before that don't want to empower someone and Kind of the counterpoint I give them a lot of times is, I don't know, I think maybe in their head they're thinking this is giving someone free reign to make really long-term decisions on their own when that's not really the case. The product owner can be fully empowered, but the decisions that they're making on the spot are just a couple of week decisions. It's not a six month decision. there's gonna be sprint reviews, we're gonna display stuff and get feedback and we can course correct and all those things. So once you can kind of put it in that frame that it's really just a couple of weeks that you're empowering them to make decisions, I've had more success framing it that way. I don't know, what about you? Barnaby Golden (08:23) Yeah, I think that makes a huge amount of sense. The fear is loss of control. So the fear is that by empowering the product owner, they might do something which they would regard as a mistake. And they will often see themselves, because they're in a senior position, they see themselves as being responsible. So if they're responsible and the product owner makes a decision they don't like, perhaps that will reflect poorly on them. So there's a trust issue here. A good product owner is going to be consulting their stakeholders anyway. And I would think the, the senior product leadership team is part of their stakeholders. So you would hope that they were keeping them very, very up to date on their thinking that there would be no great surprises that they wouldn't do something, you know, suddenly switch from one product to a completely different product. They would always be keeping their stakeholders in the loop. And in which case. they would be building up the trust of the people around them and then you would hope that over time that they would become more empowered. Brian Milner (09:23) Yeah. Yeah. I just, I kind of wonder if that's maybe part of it, that the, they have a misunderstanding of kind of how the role works. You know, cause maybe they, maybe they see it as completely independent. This person is just making decisions on their own without consulting anyone. Maybe that's because that's how they do their job. Barnaby Golden (09:35) Yeah. Yeah. Brian Milner (09:49) So they may look at that as, know, this is how I would do it, so why wouldn't this person do it the same way? Well, that's not how it's designed. It's designed to be done in concert. Barnaby Golden (09:59) Yeah, absolutely. Yeah, it's a misunderstanding of the product owner role. And it's also a misunderstanding of why the product owner role came about, which is the reason it was there was to solve the problem of too many chefs, of too many people trying to make decisions. So there's huge value in the role. But the value in the role only comes about if that person can actually take ownership of the product. I mean, the clue's in the name, isn't it? They are the owner of the product, so therefore they can make the critical on the ground decisions, but all the time talking to their stakeholders. So, I mean, as with many things in Scrum, it's about a misunderstanding, a general misunderstanding of what the roles are within the Scrum team. Brian Milner (10:41) Yeah, I think they also have the fear of the wrong decision that somehow that's going to lock them in or this person's not equipped to make the right decisions that they are the knowledge expert for the product. so they should be the one making all the decisions. They have the authority. I have had a couple of cases where I've had to have difficult conversations with leaders to say, well, let's examine the decision. because you're looking at them as making the wrong decision, but is it the wrong decision? You're disconnected from the day-to-day of the team. This person is fully connected to the day-to-day, and they're more likely to have more current knowledge. And it's not always the case that just because you assume it's the wrong decision that it actually is, they may actually be right and you could be wrong. Barnaby Golden (11:30) And funny enough, this brings on to another topic I'm greatly interested in, which is the definition of value. And that is if there is no clear understanding within the organization of value, then decisions become arbitrary. You know, we decide to do X rather than Y in the product. Well, why did you decide to do that? Well, because it was my decision to do that. Yeah, but is there a rationale behind it? Do you have a definition of the value of X and the value of Y? and why you chose one over the other. And I think that's part of the problem as well. The kinds of organizations that don't have empowered product owners also typically don't have a definition of value. Brian Milner (12:08) Yeah, I completely agree. I know I've had conversations in classes where I've talked to people about how when you're prioritizing, when you're looking at things in your backlog, and we always say you prioritize according to value. Well, what's the value? What's the value of doing that thing? And so many times, I think there are organizations that can't really identify what it is. Why are we doing this thing? because it sounded cool, because it seemed like the right thing to do, it just felt right? No, we're doing it so that it does something, it creates some outcome for us. And if you can't even really define what that outcome is that you're hoping it achieves, well, isn't that the start of the problem? Barnaby Golden (12:55) And I think part of the root cause of that as well is the tendency for these types of organizations to do long-term planning. So what they'll often do is they'll have a roadmap for the year and they'll say in this roadmap for the year, we will achieve all these things. And then it becomes less about delivering value and more about delivering the roadmap. And I've had conversations with product owners where I've said to them, you do realize what we're doing doesn't make sense. And they say, yeah, of course they do, but I'm not being measured. on sense or the delivery of value, I'm being measured on whether or not I meet the roadmap. And that was what's important to me. You can see how all these elements are tied together within the organization. Brian Milner (13:28) Right. Right? Yeah. No, that's an excellent point. And you're absolutely right. So much of our metrics and some of the things that we judge teams on or performance by is basically just a volume kind of metric. And it's how much stuff is being produced. that's not value. Volume does not equal value. Value can be achieved with much less a lot of the times. And if we're This is why sometimes I'll advise product owners in classes to say, look, start up your sprint review. Maybe go back and look at some things that you've done recently and show the metric that you're using for that thing to see if it's successful. Because if the team's done something in the past three or four sprints and it's actually moved the value needle some way, it's increased customer satisfaction. added new members to our site, whatever the thing is, right? If you can show that kind of business value to it, my experience is that people stop focusing as much on volume, because that's volumes of means to the end, which is the value. Barnaby Golden (14:40) Yeah. Yeah, absolutely. And the other thing I've noticed as well in these types of organizations is that the value they're focused on is the incremental, is not the incremental delivery. It's usually a new feature or something like that competing. And what you often find is that the teams are not end value creators. They're often parts of... the creation of value. rather than the whole creation of value, there may be a component of it. And because of that, people will say, well, there's no direct link between you and value creation in the organization. And I find that is very problematic. And it really flies against the rationale of Scrum, which is that you want within each sprint, you want to deliver some incremental value. And if you can't measure it, if you can't... clearly define what that value is. And as you were saying, if the product owner can't stand in the sprint review and say, well, this is the value we've delivered. How does the team keep motivated? How do they keep passionate about what they're doing? Brian Milner (15:50) Yeah. Yeah. I think part of that is just trying to put yourselves in the shoes of your customers and try to look about what they would find as being really valuable. I don't know about you. know, well, I'm sure this applies to you as well. But we all are consumers of different software products, whether that's a business software product or even games or other things that we would use. And when they come out with new releases of those things, they come out with release notes. Now, when they come out with the release notes, are you looking at the release notes and going, wow, I'm satisfied. There's a ton of things that's in this release. Or are you looking through the individual items and going, well, I don't care about that. I don't care about that. I don't care about this. That thing, oh yeah, that's important to me. Right? That's what we do. And that's a clear picture of value over volume. Barnaby Golden (16:49) Yeah, I mean, I think the thing that gets in the way here is a lot of it is the pride of the management team. So they often have strong self belief. They believe they make, they believe by definition, the decisions they're making are powerful decisions. So, I, it's also, think one of the reasons why a lot of organizations don't aren't data driven. You would hope they would. produce a feature and then measure whether or not that feature was a success. But that's not as common as it should be. There's very rarely business metrics tracked against deliveries. I mean, I'm generalizing here. There are many organizations do this very well. But I found there's quite a few organizations that don't really do that. And it leads to a disconnect with the customers. I mean, I can think of an example that we're... an organization I was working at where they worked on a feature delivery for six months that was on the roadmap and they got it done and they shipped it. And I think the expected users were tens of thousands and they got 16 users for this feature. And at that point there wasn't even a post-mortem. They didn't even look back and say, well, what are the lessons learned here? It was like, that's shame. Let's move on to the next item on the roadmap and hope that works instead. And it's very frustrating, especially because the feel of a good Scrum team is the connection with the customers and the feeling that you can see the passion in the engineers and in the team's eyes because they're delivering things that people want and they feel connected to it. And it means they work better and they work more effectively. Brian Milner (18:22) Yeah, there's no worse feeling than building something no one uses. I used to joke with the team, it's kind of like that old joke about if a tree falls in the woods and no one's around us, makes, if we build software that nobody uses, did we build it? It's not going to be used for anything. So it didn't serve any purpose. Barnaby Golden (18:31) You Yeah. Yeah, the way I like to think of it is that an organization should not view people's time spent in the job as important. What they should view is the value that that person has delivered as important. So sometimes people will say, know, yeah, okay, we delivered a feature that nobody really used, but you you did your job, you came in for eight hours a day during that time. And that's hard for people, I think, because they feel like this is my life. I'm investing time and energy into this. Yeah, the money is important, of course. I'm doing it as a career. But at the same time, I also want to feel reward. I want to feel like I'm achieving something. And I think with that element, you get so much better performance from the team if they feel that. Brian Milner (19:26) I agree. There's another thing I was thinking of here too, when we were talking about underpowered POs. Another cause I think that maybe you've encountered or seen as well, but screwy things that people do with kind of personnel. Like for example, having multiple product owners for a team, that leads to underpowered product owner or the opposite even putting a product owner on too many teams. That's going lead to underpowered POs as well. What's been your experience with that? Have you seen that? Okay. Barnaby Golden (19:54) I have one extreme example where there was an engineering team and the organization was an international organization. And politically within the organization, it was unacceptable to have one backlog. They had to have a backlog for the UK, a backlog for the US, a backlog for Australia, backlog for other areas of the world. And the team then had to... prioritize them kind of in this wild order. So they would say, right, we'll take number one from UK, number one from US. And so there was no coherence to what they were building at all. It was really just about satisfying people within the organization. And it kind of brings you back to that key point about why do we have product owners? Because product owners, they narrow down all the ambiguity, they narrow down all the possibilities to the thing that's most effective for the team to do next. Brian Milner (20:47) Yeah, I like your example because it highlights kind of what I think about those scenarios a lot of times is that they're theater. They're an act. They're not really serving the purpose, but they're making someone or helping someone to feel a sense of security about something that really they shouldn't feel. It's not there, but it has the appearance of it. It has the stage set. Barnaby Golden (20:55) Hmm. Yeah. Brian Milner (21:11) of something that looks secure, you know? Barnaby Golden (21:13) Yeah. mean, whenever somebody mentioned that to me, the first thing I always think about is the length of the backlog. I've worked in organizations where they could not achieve the backlog in 10 years if the team kept at it. And yet people within the organization say, yeah, I'm not worried. My feature request is on the backlog. And I'm thinking, yeah, but we're adding 10 new items a week and we're only completing eight. So in fact, you're moving further down the backlog. You're not actually getting closer to. being done. And it's, it's, it's a disconnect to gain. And this is what it's all about. Good agility, good scrum is when there's a strong connection. And if you start having that, that just doing things for appearances sake, then you lose that connection. Brian Milner (21:55) Yeah, and it really is kind of that fundamental flaw that we try to address throughout Scrum of transparency. When you do those kind of theater-ish things to give the appearance of something, it's the opposite of being transparent. You're trying to make it more difficult to see the reality. Yeah, it's on the backlog, so you have this false sense of security. It's on the backlog. It's never gonna get done, but... that's not transparent that it's never going to get done because it's on the backlog. Yeah, mean, part of that I put on the product owner a little bit, but that could also be that the organization demands it. Like your example with it having different backlogs across different geographies, does it serve a purpose? Well, maybe the purpose is to make someone feel better. That, hey, my thing's number one on our list, but... Barnaby Golden (22:39) Yeah. Brian Milner (22:43) That doesn't mean it's number one, that's the next thing that's going get done. It's theater. Barnaby Golden (22:47) And it was done exactly for that reason. I mean, it was done because they didn't want to alienate the heads of the individual countries. So they wanted to make them feel like they were going to get something even though they weren't going to get it. Which is really frustrating. Brian Milner (22:59) I've seen that as well with the multiple product owners. When there's a team that has multiple product owners, a lot of times that's a theater kind of thing as well, because there's a, I don't know if there's a fear that someone's gonna feel undervalued if they're not called the product owner. But it just seems like, yeah, we want all these voices to be involved with it, which again, maybe it's a misunderstanding of the product owner role. That's okay, you can have multiple voices involved, but you gotta define who's the decision maker. And if a team doesn't know that, that's gonna cause a whole host of problems. Barnaby Golden (23:34) Absolutely. I mean, I've been in scenarios where you would have multiple product owners. The team has been instructed by a product owner to go in a direction and then midway through a sprint, the other product owner will come along and say, yeah, that's not really what I had in mind for this sprint. Can you please switch onto this other thing? And as a, you know, I was a scrum master at the time and what I ended up doing in my sprint report was I would say, and the team lost 20 to 30 % of their capacity in switching. between what one product owner wanted and what the other product owner wanted. And that at least got a reaction because people said, well, OK, maybe that's not a good thing if we're losing output from the team. But it's a failure of the organization to make value judgments and make genuine decisions. Instead, it becomes political decisions. Brian Milner (24:19) Yeah. Well, I'll give you my trick for when I've encountered it as a consultant a couple of times, I usually just ask one question and it'll clear it up. I'll just go to them and whoever the leader is that's insisting that there's multiple product owners on the team, I'll just go and say, all right, what happens when, let's say it's two, what happens when those two people disagree? And usually the immediate thing I hear back is, oh, no, no, no, they get along. They usually understand. Barnaby Golden (24:45) You Brian Milner (24:47) And I always just counteract it really quickly and say, yeah, but what happens when they don't? What happens when the day comes when one of the product owners wants something that's number one and the other one wants an entirely different thing as the number one priority, who makes the call? And usually they'll point to one of them and say, push comes to shove that one. right. I mean, at that point, I just say, well, you just told me that's your product owner, right? Barnaby Golden (25:08) got a little bit more authority so they make the decision here. Brian Milner (25:15) That's the product on the other person's a stakeholder, which is fine. There's nothing devaluing about someone who's a stakeholder. They can work all day every day with that product owner. Barnaby Golden (25:24) Yeah, absolutely. I think that people feel if they're not in the product owner role, then they will just be another stakeholder and maybe they won't have as loud a voice. But what's so frustrating about the situation is when you see it done well, when you see it done effectively with a really good empowered product owner, a very motivated team, it's such a powerful thing. And I mean, it's why I stayed in Agile for so long is because I know how good it can be and It's very frustrating and I guess I have sympathy for organizations because maybe if they've never seen it done well, it's difficult for them to understand how just how effective it is. Brian Milner (26:00) Yeah, I agree. Well, this has been a great discussion. I really like this topic. It's great to focus on product owners a little bit. And hopefully, maybe there is a leader out there or somebody listening who heard some of these things and thought, you know what? Maybe it is time to give our product owner a little more power. We talk about testing things all the time, inspecting and adapting as we go. Well, leaders, try that. Barnaby Golden (26:25) Yeah, maybe just try it as an experiment. You know, if you're concerned, give it a go. Brian Milner (26:27) Yeah. Yeah. Give it a shot and see what happens. You may like it, and you may decide this is the best way to go. So yeah, I think that's a great suggestion. Well, Barnaby, this has been great. I really appreciate you making time for this. thanks for not only being on the show, but for the contributions you made in the Agile Mentors community as well. Barnaby Golden (26:47) Well thanks a lot Brian, I really enjoyed that, it was a great conversation.

Join Brian and Scott Dunn as they unpack what “buy-in” actually means and what it takes to move from surface-level support to genuine commitment in this episode of the Agile Mentors Podcast. Overview In this episode of the Agile Mentors Podcast, Brian is joined once again by Scott Dunn to tackle a listener-chosen topic: how to get real buy-in for Agile initiatives, especially when shifting from a non-Scrum environment. They explore why buy-in isn’t about enthusiastic cheerleading or deep Agile knowledge, but about leaders and teams aligning on desired outcomes. From the cost of performative support to the emotional side of change, Brian and Scott share practical strategies for securing support at all levels of the organization. Along the way, they dive into influence tactics, the importance of shared purpose, and how co-creation—not compliance—drives lasting change. Whether you're guiding a large transformation or simply trying to influence up, this episode will help you rethink how to earn trust, build alignment, and inspire meaningful momentum. References and resources mentioned in the show: Scott Dunn Elements of Agile Assessment Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Auto-generated Transcript: Brian Milner (00:01) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And I also have with me today someone that you probably know pretty well because he took over this podcast for about a month there. Mr. Scott Dunn is with us. Welcome in, Scott. Scott Dunn (00:19) Hey, thanks Brian. Yes, that podcast takeover was a lot of fun. So thank you for that opportunity. That was a hoot. Had a great time. Brian Milner (00:25) Absolutely. Well, I don't think I publicly thanked you for that. just ⁓ a public thanks. Scott Dunn (00:28) No, you didn't. No, not even an email. Not even a Slack message. Brian Milner (00:33) Well, very public thanks to you for doing that. Those episodes were great. I enjoyed them and it was fun to be a listener. It was fun to listen to it and just kind of hear the conversations and be a fly on the wall for those. So thanks again for doing that. Scott Dunn (00:47) Yeah. Yeah. It's a real treat. Brian Milner (00:48) We're having Scott on we kind of ran an experiment on this one because we were Scott was teaching a class for mountain goat and We thought maybe we'll just see what the class thinks so we pulled the class to see what topic do you want us to talk about and We thought we'd just go with the winner the winner that came out of that class was how to get buy-in How do you get buy-in in a? move from a non-scrum place to a Scrum kind of way of working. How do you get buy-in in the organization and buy-in from others? So when I was thinking about this as a topic, I think the first thing that popped in my head Scott about this was What do we mean by buy-in? So what does that mean to you? Scott Dunn (01:33) Right. So sometimes what I'm hearing is people saying like, buy in, you know, they, I would hear a common complaint, like they don't get it. They don't understand. don't, for me, buy in isn't that they need to understand agile or scrum and these types of things and how it works. Buy in is they get, they give their support kind of regardless. So my favorite example of that is walking into, this is a multi vendor effort we're doing on a Salesforce implementation. And we'd asked for the VP of the whole thing to come down and say some words before we had our first retrospective. You can imagine it's going to be kind of heated with different vendors trying to make each other look bad or whatever. And he'd said, yes. So we're coming down into this, you know, big high stakes meeting. And I just remember him saying, you know, I'm so excited to be doing this for you all. It's great. And he kind of falls in and looks at me says, what am I doing again? Cause he didn't, he didn't know, he didn't know what a retrospective was. He just knew he was asked to come and do something around that. And to me, Brian, Brian Milner (02:21) Ha Scott Dunn (02:28) That's fine. He's showing up. He's letting everyone know this way of working is important. It's important to me. It's important to success. And he probably couldn't tell you any of the meetings or artifacts or anything in scrum, right? But that's still what we need. Brian Milner (02:39) So. Yeah, I think that's a good way to think about it because I think a lot of people sometimes think of buy-in, like everyone's clapping and waving scrum flags around and all that stuff. And I don't think that's really buy-in. I think it's just the willingness to honestly try it, to give it a shot and be open about what would work and what doesn't work. The opposite of that is the resistance, know, of just being resistant to it and saying, I'm gonna put up hurdles and walls in the way of this being successful. That's, think, what needs to be avoided. Scott Dunn (03:18) Right, right. think that some of what was helped is to give them the, for me, the mindset of their buy-in isn't about doing things right. They're not saying, we're really wanted. We really want a new process. We were getting asked to come in because they're not getting the results they want. So buy-in for me from their perspective is how to help get the results that they're looking for. And they'll support us to get those results. So I don't talk to them about some of the aspects of an empirical process or any of that. I sort of say, you in order to get things faster or in order to improve quality, right? And that's how they get behind that. I think sometimes people are preaching some of the process part, even if they could understand that's not really what they're about. But I think they even struggle to understand what we're talking about. So yeah, it's hard for them to get behind and support us when they're not tracking. They simply know there's a pain point we're having. Can we talk about that and how to get what we need and what do you need from me to get that? Great. But I think we We can do ourselves a favor by helping point to the same target, make sure we're aligned with the same target they want. And maybe they'll give us more support if they feel like, yeah, you're tracking with me. I want to come in talk about, you know, more collaboration. Like we already have enough meetings. That's what, that's what I heard. Right. But I'll come and talk about faster time to market. Well, yeah, now they're interested in talking about what they need to do, you know, that I'm asking them to get behind that. I think that's fair. Brian Milner (04:28) Right. Yeah, I think there's also an element there, because I know we're both kind of fans of and users of kind of the path to agility framework from our friend David Hawks. And I love the part of that that's trying to establish the motivation, the purpose from the outset to try to say, What's the thing we hope to get out of this? And I think that's really crucial in getting buy-in that you can't just tell people, hey, we're gonna be a Scrum organization now. Why? Because I tell you that's what we're gonna do, because we're gonna check off the box and say that we're now Scrum. That's not motivating to anyone. if I can say, no, we're gonna... go through this change because here's the end result. Here's what we're trying to get to. Here's what we think will be better. If I can lay that out, then I've got a purpose behind it. And now I have motivation to go forward with this difficult change and learning what's expected of me and all that stuff. But if that's not done, I feel like that's a crucial misstep in that. Scott Dunn (05:44) Yeah, I wanted to add to that, that that point about the clarity of the goals is really something that has sticking power. And we had a client, I came and was working with him this year that he had remembered from the last year as the CTO. He's remembering from last year that we had done that same exercise or what are the goals that leadership has. And he remembered it was quality and customer satisfaction. That had been over a year since we had done that, but that not only stuck with him, but we came back to the group and kind of had a fun poll. Like, everyone remember? They remembered. And so every time we're having a decision we're trying to make about should it be this way or that way on the process, the different, were doing the race, the matrix work, et cetera, people kept coming back to, well, is that going to help us in terms of quality? Is that going to help us in terms of customer staff? We're not going into the nuts and bolts of Scrum or these other approaches. It's simply what's the business goal. will that help us hit the goal? And when the leader hears you using their language that they get, like that's my goal, they're feeling like, okay, whatever you need to do, sounds like you understand what I'm after, right? It's really powerful. But I like that you mentioned that, because when we go through that exercise, always super clear, we don't get confused. Times when we lead with, especially on the executives trying to lead with explaining Scrum, you can tell sometimes they're not really tracking or they're following along, okay, so what's the point? Brian Milner (06:59) Yeah. Scott Dunn (06:59) Yeah, you start off with what's their goals. They're like, great, this is exactly what I want to talk about. And then, Hey, you're not doing the things you need to do to hit those goals. Oh, okay. What are they? I mean, I remember one time a couple of years back, literally when the coach was presenting the results of that assessment towards their goals, they cut them off in the middle of his presentation. Just says, well, why, why is it, you why is that red? Why are we not hitting the goal? What do need to do? And they just started solving the problem right then he couldn't even finish his presentation. Talk about getting support. And he had been there six years saying, Brian Milner (07:23) Wow. Scott Dunn (07:27) Scott, they're not gonna buy into doing this transformation team and the scrum work. He couldn't even finish, I think, a couple of slides and they gave him everything he wanted, right? Powerful, powerful. Brian Milner (07:36) Yeah. Yeah. I think that's a good point. I also think one of the reasons that there's, you know, and that kind of parallels it. One of the reasons there's a lack of buy-in in general is that it's sort of targeted to just one area. You know, like this is a team thing. The teams are going to get trained, but the leaders have no idea really what's going on. They're kind of separated off from this. And I think that's a big part of the problem as well is you get buy-in when they see the leaders have bought in. So are the leaders bought in? Are the leaders on board with this? If they're not, then the rest of the group isn't going to be bought in either. Scott Dunn (08:18) People are smart. They're watching which way the wind's blowing. to be honest, Brian, I'd love to hear your thoughts. I tell people, I don't even care if they genuinely believe in that or not. If they're getting behind it because that's the way the politics are going, hey, they're getting out of the way. We're getting things done. Fine by me. Right. So partly when we're getting that by now, so make sure leaders, are you communicating this clearly? Because some of your people are either not on board or they're kind of waiting to see, this a fad or is this going to blow over? I need you to really communicate that clearly, et cetera, to see if people are get on board with that or not. Or, and on the other side, if I feel like some of these folks are not on board and I do feel like I have leadership support, I need to escalate that pretty quickly and make sure you understand, know, because they might get mad at you or me for talking about scrum and changing things. I'm like, I didn't knock down the door and come in myself. I was asked to come in here by someone who has authority. So maybe you need to clarify that with them, whether we're doing this or not. But don't get mad at me. Brian Milner (09:04) Right. Scott Dunn (09:11) So I will check them on that and clarify with the leadership to say, let's make sure your people are in alignment as well. If we do have that buy-in for sure. Brian Milner (09:20) Yeah. I saw another kind of quote about this that really got my brain working a little bit. Cause it was talking about the cost of fake buy-in and it was, it was kind of saying, you know, performative buy-in might actually, you know, it was asking the question, is performative buy-in worse than just outright resistance? And I don't know. Let me ask you that. What do you think? Do you think performative buy-in is worse than just someone who's resistant? Scott Dunn (09:28) Interesting. Yeah. As someone that just gave an example of performative buy-in. So if you would ask me a week ago, I might have gave a different answer, but someone was talking about this is a wildly different aspect of this, but you did ask me to join. So you get what you get. ⁓ They're talking about the difference of discrimination in the US versus South Africa. And they said, what's the difference? And they said in South Africa, it was blatant. no, you're a person of color. You cannot buy property here. That's how it is. Here, it's more like Brian Milner (09:59) You Scott Dunn (10:14) Yeah, we're looking at your loan application and I don't know if you can buy in this way. So it's subtle. And this person actually said, I'll take the outright blatant discrimination of South Africa, where at least you know what the issue is versus the subtle one. So maybe to that point with what you're saying, maybe it is better to have outright resistance and then say, well, at least I know who's on board or not. Rather than the person says they're on board, but every time they're in a meeting, they come out meeting and we don't get the decisions made we need. That's funny. Brian Milner (10:39) Yeah. Yeah. When I read this and started to think about it, I kind of had that same conclusion that like when someone's being outright resistant, yeah, it's an obstacle, but it's honest. And, you know, I'd rather have the honesty because they're trying to, they're still acting their way because they have a belief that their way is the right way to do it. And so they're throwing up a resistance because they're honestly resistant to it. Whereas someone who just sort of nods in meetings and claps along and, know, oh yeah, sure, great. But then they're kind of in the quiet, you know, behind the scenes and the hallway conversations. That's insidious. That's something that I can't really deal with. And it's like, you know, let's have the discussion. Let's talk about it. And, you know, if you win, then great. Why not have the courage to just have the conversation and see which idea wins? Scott Dunn (11:39) Right. on that note, think for everyone's sake, Brian, if we could be honest for a moment, not that we haven't been honest in these other podcasts, but in this, in this moment, we're really going to be honest. Would you, would, do you feel at times that our culture, our company cultures actually teach people to do just what you said to not be honest, but then like be like, you know, politically savvy, don't say what you really think, but then you're going to kind of be subversive and undermine that thing. And I've dealt with that so many times, I'll show up to a meeting like, I would have swore we were on board. had that one-on-one and now you're not saying in the meeting that you go on board with that. So people might've gotten coached. It's actually not safe to be honest and have good clear spirited debate because there's a price to pay if they do that. And they maybe 10 years in corporate can kind of teach you don't be honest or they're trying to read the tea leaves about what you think it's going to be. And so, yeah, I definitely would rather take it. Maybe it's part of the mindset of trying to really check, you know, where people are at. If I go back to my early days of coaching, those one-on-ones of having the level of honesty to really know where people are at. That was, think, some of the power. And I think some of that came from genuinely caring about the people, wanting them to succeed, wanting them win, even if it wasn't going to be at this company because of all the change or whatever. I did feel people felt like I really was open and honest with them and transparent and had their back. I would hear some real things about how they really felt because they didn't feel like there was a payback for that. And that allowed me to actually say, well, you know what, if you're really not on board, let's see what we can do as far as another opportunity. Maybe it's a positional switch we can do or whatever that was. Because I mean, this did affect people's jobs in some ways. And I think maybe if I don't have those one-on-ones, they're probably just going to give lip service because they don't know if anyone there really has their back in a turbulent time of change. AI is a great example of that, right? Hey, we want to move forward with AI. Well, what's the impact of my job if we do? But no one's really talking about that, right? It's all positive and all that. So I think people are trying to read that too. But you bring up a good point. I think I would take the direct as long as they feel like they can safely be open and honest. Brian Milner (13:31) Yeah. Yeah, well, even that question, right? What effect is AI gonna have on my job? And the honest answer I think that someone has to give right now is, don't know. I feel like I understand what it is today, but I don't know that that's gonna be the same way tomorrow because this technology changes so fast, so I can't promise anything. But here's what it is today and this is the paradigm we're trying to live in. So I think that there's an honesty component there that you've got a mirror to say, hey, I'm going to be honest with you. You be honest with me about this. And we'll be upfront with each other as we make our way through this. yeah, so yeah, think that kind of being honest and taking that approach, I think, is the right way to go. I also think that being kind of a reverting back before you get into things like, here's what a Scrum Master is, here's what a product owner is. You've got to start with the basics and mindset kind of culture things. You have to start with transparency, inspection, adaptation. That's really the way to go. And if we buy into those sorts of things initially, then we can start to say, well, here's a practice that supports that. Now you understand why we're doing this practice because it does this thing. Without it, it's just sort of one of those things of do as I tell you, you know, and that doesn't get buy-in. We've got to see the why behind it. Scott Dunn (14:48) Yes. Yeah, I think so. That's a great point. I was just making a note because sometimes we come in about agile. Some of the folks when I'm sharing this, it's maybe is new to them that I try to really present it. I want what you want. So even down to the words and then I kind of map back to that. So for example, if if we have quality problems now, I might believe in say an agile practice like mob programming, but I don't want to bring up like, hey, we should try mobbing. because it's cool or because you know, whatever, they don't care about that. But oh, they have a quality concern. Hey, boss, I've been thinking about, you know, these quality issues. I got an idea that I think it really could help with quality. But if I was to ask you, Brian, is is Bobby gonna, does Bobby help with quality? Does Bobby help me with, you know, cross training and tearing down knowledge silos and sharing learning? And I think, well, it does a lot of things, I pitch it towards what management wants. So agile as a means to an end. So I want what you want. And if I can't get that clarity that I want what you want, I need to be listening more because if I feel like I come to them talking, I've seen from my own experience, I come talking about better collaboration. That's not what's on their mind. I'm literally losing credit with them because they're like, why are you bringing this up? Like this isn't even our concern right now. Right. So I'm losing trust. I'm losing political capital. So I listen intently what their concerns are, the things I think that are important or that can get that. Then I'm going to pitch it. I'm going to pitch it in that language even like, you know, that what these are the things that would help on. I want what you want. Brian Milner (16:00) Yeah. Scott Dunn (16:18) the sport, I'll even research stuff to find out. So maybe I gave an example recently, when I was a manager for a web development, team that they wanted bigger monitors, of course, and I couldn't get approval for the bigger monitors. so I went and researched, I knew that always we had pressure to deliver more. I researched until I found somewhere someone had to study the show that larger monitors help productivity. And then I brought that to him and like, Hey, I'm looking for ways to improve the team productivity. I think I found something. What is it Scott? Brian Milner (16:30) Mm-hmm. Scott Dunn (16:46) Well, larger monitors, you can tell us, Smollick, really? You've been asking for this for months. I said, no, there's a study that proves it. Now he approved it right then. But partly I wonder, Brian, is I was also giving him air cover for when he gets flack from the other departments. Why does Scott's team get the special monitors? Well, it improves productivity. And right. He's got a reason now. Otherwise, it looks like maybe he's just playing favorites or something else. Right. We're all watching costs. So I will do the research to say, hey, I want what you want. I'll go and I'll go and dig it up. Brian Milner (17:04) Yeah. Scott Dunn (17:13) Someone somewhere must've said it's gonna help. So I'll bring that to them. It ⁓ worked. Brian Milner (17:17) Yeah. Yeah, I think you're right. you're giving him the why behind it. You're telling him, hey, here's something that's in. It's the old outcome argument that the outcome from having larger monitors is this, that we have this productivity. I know you want greater productivity, so here's a means to do that. And I think that's kind of the way that this, you in a nutshell, what we're trying to say here is, you know, I can't go into a company, your boss comes into your company tomorrow and says, hey everyone, we're switching to pens that write in green ink, because we're a green ink company. We just, we want to be known as the green ink company from now on, because it's better. So everyone, make sure you switch to green ink. I mean, they do it. But there's a difference between compliance and real commitment. ⁓ And that's the difference, I think, is, all right, you wanted to switch to green ink, but why? What's the point behind it? I'll do it, but I'll be committed to it if you tell me, well, studies show that when people read in green ink. I mean, that kind of thing can make an impact. But otherwise, it's like you're Scott Dunn (18:08) Yes. ⁓ Absolutely. Brian Milner (18:31) It's almost like an insult to the intelligence of someone, you know, to say, we're going to do this crazy new thing called a standup, you know, or daily scrum or whatever. And well, why are we doing that? I don't know. Cause right. That they tell us that's what we're supposed to do. Well, we have to stand up for a meeting. Why are we standing up? Why aren't we just sitting down? It's more comfortable. I don't know, but that's what you do in a daily scrum is you stand up. Right. I mean, it's, it's, it's that kind of a thing that I think. Scott Dunn (18:34) yeah. Yeah. I don't know. Brian Milner (18:58) if you don't lay the groundwork of here's why, then they're gonna just react with the way that you would switch to green ink. ⁓ Scott Dunn (19:05) I love that example. love that. And we've all been there, right? When someone says, why would we do this? I'm like, I actually don't know. It's a terrible feeling. I don't know. We go through all this effort to do just that. And you mentioned that compliance, compliance will never have their heart and soul and energy into this. So think that that's a big deal for them as well. When leaders are, we had something happen where it's a large financial institution and their data engineering group. Brian Milner (19:11) You're right. Yeah. Scott Dunn (19:33) You're like, yeah, AI is not really, you know, for us, not important to us. Which is interesting, right? Then the next week, like that, the head of that group, their boss's boss says, we need to be using, AI. Well, guess who makes it announced at the very next week. We need to get going with AI, So some of this is like, look, if they're pushing those things, we also want to make sure that they're in a position to look good for their bosses, those types of things. Right? So one, you know, giving them air cover, but two, listen to the winds of those things. If we make them successful, I mean, this is old school, right? Make your boss look good. My goodness. If they feel like that's happening, then you're going to get a lot more support. And this is a good example of a radical change for a whole data engineering team, just because the boss's boss says so. So now we're going to do it. I think looking for even those opportunities and following through on what that might be bringing them ideas that make them look good and generating that as well. I love the green ink one. just now it makes me want to be that we're the green ink company. You're we're going to be known for this. Brian Milner (20:23) Yeah. Scott Dunn (20:29) ⁓ But why? Brian Milner (20:30) Yeah. I think it's also kind of important that you acknowledge that there is an emotional impact here. And this gets into kind of the idea of the whole Satir model of change and that kind of thing. And so I think maybe part of the equation of getting buy-in is really comprehending and understanding that you're not going to get buy-in right away. ⁓ Scott Dunn (20:56) Hmm. Brian Milner (20:57) you know, there's going to be chaos and resistance. There's going to be a point where people are going to be resistant to it. And if you do the rest of it well, then that they'll turn that corner. But what makes them turn that corner is, is that they're connected to the purpose behind it. And so if you're, if you're going to try to implement this, if you're to try to do a change, and just expect it's gonna be, know, hunky dory from day one, you're fooling yourself. Humans don't take to change well. It's got an emotional aspect to it. I love the way David Hawks used to always say this. You know, I knew how to be a hero the old way, and I have no idea how to be a hero in this new thing. So I don't feel comfortable with this change because I don't know how to win. Scott Dunn (21:41) So true. Brian Milner (21:47) And I think that is a really accurate reflection of that emotional kind of impact of it. Everyone wants to do their job well and be seen as a smart person at work and everything else. And I knew how to do that before, but now I don't know how. And so I'm afraid I'm gonna look bad. Scott Dunn (22:02) Right? And I think that lack of awareness or knowledge is some of the things that we're asking them to do. Like you said, uncomfortable or new doesn't feel good. And we kind of think that, oh, if I don't feel good, this must be bad. It's just uncomfortable. But I think I love what you're saying. We can map it out and say, by the way, it's going to look like this as we go through that. And that hero part, a lot of our management, like 90 % of the management is going to be in that, you what we call expert or achiever. Like they're the smartest ones in the room, or they're ones that coordinate everything and they know who to talk to. you're trying to introduce something to someone who thinks they already know all the things. So how we're presenting that to them, including the fact that they're human too, right? They're gonna feel some things and maybe uncomfortable. It wouldn't hurt to explain a bit more, even if they're not gonna necessarily admit it, but like, hey, it's gonna feel different. The people might push back on this. So even when you're first beginning that, it reminded me of how I just knew I'd need to ask my boss like five times. Look, lots of people are asking him for stuff. They're partly just going by the simplest way of Who keeps coming to my office the most? And maybe on time five, like, wow, Scott, this sounds like a problem. Well, yeah, I've been here five times. Because they're kind of waiting, like, is it really a problem or do you just come in once or twice? So repeating that and then maybe framing it to say, and doing the change looks like this and that, giving them information so they don't have to admit that they don't know if they're priding themselves on knowing all the things. I really think that's a great addition to that. The Satir change model, knowing that it's going to get uncomfortable. I've seen execs jettison this just because people are bothered or upset or they're uncomfortable. So therefore this must be a bad idea. So I think we can do ourselves a favor by explaining a little bit like it's going to look like this moving forward as far as their support. Some people may not like it and here's why, but here's how I would answer those people. Like you're literally feeding them the responses. And I'll also do the get behind the expert and say, well, this is, this is what Harvard business review says, or this is what this expert says. You might be surprised because Again, back to them being experts, if you ask them what they think they know about Agile, I might have mentioned before, they score themselves on average about 8.5 out of 10. But their people would score them about 4.5 out of 10, right? It was what I've seen when I did the study, the surveys. So they think they know, so they're not gonna admit they don't know, but go ahead and give them the information they wish. If you know they don't know, I like what you're saying, kind of shrink the chain so they can understand, it's gonna look like this and feel like this. People might ask this way. But here's how I'd respond to them. know, remember this is where, you know, 90 % of the companies are doing X, Y, and Z. So they have backing. They can answer to the people. We kind of set them up for success. Otherwise that satiric change curve is going to hit them. They won't have answers. That feels really awkward. This must be a bad idea. And they're going to undo what you just asked for. Right. I've seen that happen. You just got approval and then a week or two later it got put on hold or undone. Brian Milner (24:44) Yeah, no, I agree. one of the areas, one of the other kind of things that I found in thinking about this in advance was a quote that was from the five dysfunctions of a team book that we all talk about quite a bit. But there's a quote from that that says, people don't weigh in, they won't buy in. And I love that. And I thought, you know, that really is a good point that there, it's not about Scott Dunn (25:00) Woo! Brian Milner (25:08) people need to feel like they're co-creating with you. And to do that, you need to be able to listen to them. If they don't feel like they have a voice, mean, put yourself in their shoes. If you felt like there was a big change happening and you had no say in it, that would feel pretty oppressive. But if they felt like they're building the change with you, then I think then that's what kind of can turn people around and say, no, I have a say in this, I'm a part of this. and I get to shape a little bit about what this is going to look like. They're going to shape it a lot. I mean, that's part of just the Azure way of working is that, hey, we're going to individualize this for this company, for this team. It has to fit here. And the more we can help people see, no, you're a co-creator in this. You're not just being told, but you're going to shape this with us. Scott Dunn (25:54) Right? Even with the leadership, I mean, it's easy. think everyone listening would agree. If you look at the common leaders, that's, even the, let's say director level and above personality types, right? For, for disc, it's going to be a high D for a strange pattern would be like command, um, computing values framework. They're going to be blue, get results, make it happen. But we need it to be, we need to be their decision for some of these folks. So when I would come to one of my bosses and say, I think we should do X every time he'd say like, yeah, let me think about. I'll get back to you. I kept thinking like, I don't understand because these are my people. I thought you trusted me. I realized, it has to be his decision. So part of what you're saying is invite him into the solution. So then I'd say, hey, we've got three options, good, better, best. What do you think we should do? Or I'd say, hey, I've done all the research, option A looks great, option B looks terrible. What do you think we should do? I mean, I try to simplify it. I tried to make it obvious, but I couldn't tell him I need to do X or we need this from you. It needed to be his input and to decide. Brian Milner (26:44) Right. Scott Dunn (26:51) once I framed it that way, he agreed every single time. I simply frame it, put it right in front of him so it's kind of an obvious decision, but I had to let him have that voice to decide. I'm really glad you brought that up. That one literally went from zero to 100 % if I changed my approach of how I had addressed it to let him be the one to decide and weigh in on that. Or even pitch it as a sales. Hey, I think it'd be great to move forward. What would that look like to you? Well, now he's talking about moving that change forward. without even realizing it, because you said to move forward, what would we need to do? And now he is co-creating, but it's already a yes, right? But by default, a little bit of sales, a little bit of sales effort there. Brian Milner (27:24) Yeah. Yeah, no, that's a, that's a good example. And that's a good example, I think for like the scrum masters listening and other people out here that are, feel like, you know, I'm not the leader in the organization. I'm not way up here and I can't, you know, have my decisions trickle down to other people, but, you know, kind of the, influencing up kind of mentality there. Yeah. It might sound like a little bit of a trick, but you know, if you can help. the boss co-create with you, right? Here's the problem. I've done some research. Here's some solutions. How would this look for you? Or what do you think of these options? Which one do you think sounds best? If I'm a boss and someone comes to me and says that I've researched this, here's the solutions that are possible. Which one do you think sounds best? That's really a service to me because you've just done a lot of work for me and I know that I'm doing my job by making the decision, but you've presented it and now I don't have to do anything but make the call. Yeah. Scott Dunn (28:24) Yeah, yeah. Simplify the decision-making or frame the decision-making is, think we might actually be kind of, I don't want to say teasing. I just hear some feedback from people at times like, leadership's was like, bright, shiny squirrel, right? And they get frustrated. But in some ways I'm thinking, well, at least someone in the org is decisive. I'll take that. But we can help them leverage that decisive trait they have. Brian Milner (28:43) Yeah. Scott Dunn (28:48) But for the good, instead of these random crazy things, you know, when the leader's like, I love Agile, I can change my mind all the time. We can, we can, we can guide them to better decision-making too. I love the influence both up and down what you're saying the Scrum Master can do. I think we miss, that we all have that ability to try to influence decision-making and shape some of this. Maybe there's more agency than we realized, I think for some of these folks, Scrum Masters, product owners, cetera, that you might be surprised. Like run an experiment, try some of these things out that we're talking about and see for yourself. I mean, all these personality types are different and your orgs are different. I totally understand that. Do something, inspect and adapt and see what you get. might, cause once you strike gold, you're like, you know, you're set on getting influence and buy-in from folks. It's really powerful network. Cause we don't need to give you a title or change the org chart in order to have results happen with you involved if you're that kind of a person. And I think you can really write your ticket in your career if you're able to do that soft skill of influence and buy-in up and down. It's great. Brian Milner (29:43) Yeah, yeah, that's awesome. Well, I hope that for at least the people that were in your class, this is is hit it right on the nail on the head for what it is they were they were thinking this would be about. But I think this is good. I think this is a good conversation and it's important, I think at all levels, because there's you know, this this affects us whether we're doing a massive transformation in an organization or Scott Dunn (29:51) Yeah. Brian Milner (30:06) We're just trying to influence up a tiny bit, you know, the food chain. Scott Dunn (30:10) Yeah, absolutely. Yeah, I hope that for the folks who were in that class, you better let us know if that was it. If anyone else is interested in other things, absolutely. We love hearing what your what those topics would be and bring on the right people. I will say that Brian, you brought in so many different voices. It's really, really great. So again, influence us. You can practice what we're talking about by putting those ideas up there. Other folks that we'd love to hear, because I love the the slated speakers you brought in. Brian's been really awesome. Thanks for this opportunity. Brian Milner (30:34) Thank you. Yeah, absolutely. Thanks for coming on again, Scott.

Join Brian and Mike Cohn as they unpack the five essential pillars that take Agile from “just the motions” to meaningful, measurable impact. Plus, get a behind-the-scenes look at their revamped course built for real team transformation. Overview In this episode of the Agile Mentors Podcast, Brian is joined by longtime collaborator and Agile thought leader Mike Cohn for a deep dive into what really makes Agile stick. They explore the five foundational pillars—mindset, practices, roles, teamwork, and support beyond the team—and share stories of what happens when teams get them wrong (like obsessing over story point math or demoing a copyright update in a sprint review). Along the way, they introduce the newly available Working on a Scrum Team public course and explain why it’s designed for entire teams, not just isolated roles. Whether you're new to Agile or knee-deep in transformation, this episode will help you rethink how to build an Agile approach that actually works. References and resources mentioned in the show: Mike Cohn #80: From Struggling to Success: Reviving Agile Teams with Mike Cohn Scrum Team Roles and Responsibilities Working on a Scrum Team Course Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection. Auto-generated Transcript: Brian Milner (00:00) Welcome in, Agile Mentors. We're back for another episode of the Agile Mentors podcast. Thanks for joining us. I'm with you, as always, Brian Milner. And today, I have the one and only Mike Cohn back with us. Welcome in, Mike. Mike (00:12) Thanks, Brian. Good to be here. Brian Milner (00:14) Always happy to have Mike on the show and really appreciate Mike making time to come on. Wanted to have Mike on because there's some things Mike's been talking about recently that are really interesting and people have been asking a little bit about this and I thought maybe it'd be just a good opportunity to talk through some of the stuff that Mike's been writing about. I know you spent, Mike, a lot of time helping teams to not just do Agile but to really get solid results from it. to see impact from it. And I know the topic you've been talking about recently is sort of these five pillars of supporting real agile improvements, the mindset, practices, roles, teamwork, and support beyond the team. So I thought maybe we could just dig in and drive through those and maybe learn a little bit about those as we go. Obviously also to talk a little bit about the exciting new course that's being launched here, the working on a Scrum team course, because I know that was originally just for private classes, right? And now it's being open to the public. Mike (01:23) Yeah, we've done working on a Scrum team as a private class for probably 20 plus years. It's been kind of our main offering to private clients. But we're hearing from a lot of people that they have one team and they can't really get a private class approved with the budget and such. So what we're doing is going ahead and making that course available as a public course. So two people from your company, five people from another company all in the same class the way we've done our certified courses for decades. And so we're going to start offering this as a public course. And the exciting thing there is that it's really meant to be a team-based class, where things like Scrum Master training, great class, but it's really meant for the Scrum Master, right? And working on a Scrum team is really designed, and you and I helped you and I design this course together, but it's designed to be something that is a whole team training, right? So good for anybody on a team. Brian Milner (02:16) Yeah, yeah, it's been really great teaching those in the private classes and I'm excited to think about the public being able to come in and take that now. Let's talk a little bit about these pillars and, I think people are gonna be really intrigued by the concept here. The first one is mindset, I think, and just wanna start there and say, what does it actually mean to... think Agile and what is the found, why is that kind of the foundation for successful transformations? Mike (02:43) Remember the kind of the early days of agile and there was a lot of conversation about could you be agile without understanding the principles, right? If you just did the practices, were you agile? Other people were saying, no, you have to start with the principles, right? And so do you start with principles? Do you start with practices? And I remember these early debates and they often devolved into a discussion of the karate kid movie, right? Remember that one, right? And, you know, can you just wax on? Brian Milner (03:12) Ha Mike (03:12) for long enough, just do the practices. And then all of a sudden, your karate instructor or your agile coach is, OK, you're agile. And it's like, wait, all I know how to do is wax a car, right? And so there were these discussions about practices versus principles. And I was kind of always on the side where you better understand the principles to do this. Just knowing the practices, waxing on all day, is kind of just going through the motions. And so you have to understand the principles. And the idea that I wanted was that if a team truly understood all of the principles underneath Agile, I don't just mean just the manifesto, but all the principles that are there from Lean, from Kanban, from everything, that if you really understood those, you'd kind of invent the practices, right? You do those and you go eventually to go, hey, we should probably meet every day. Or hey, if we tested first, that might be a really good thing. Brian Milner (03:57) Yeah. Mike (04:05) So you'd invent the practices if you really had that type of agile mindset. And so for me, when we're working with organizations to get them truly agile, and I don't mean like more agile than less agile, but agile in a way that's going to stick, you got to change mindsets, right? You've got to do more than just the wax on. So people have to get the mindset. Brian Milner (04:27) Yeah, I love that. I know that I've experienced some things in the course of working with people that's it's sort of like you, if you're not on the same page with the principles, then you start to talk through the practices and you run up against a problem. And really what you find out the core of it was, well, we weren't aligned on really the principle behind this. So why would I want the practices then, right? ⁓ Mike (04:49) Yeah. Well, that's where you also end up then with a lot of team debates about things, right? Because you're arguing about the practice. if you'll say you and I are arguing about the benefit of some practice, if we agree on the principle, we might just have different views on it. But deep down, we'll probably agree on some practice, or we might find an alternative one. But if you don't agree on the principles, you end up with a lot more of these kind of annoying. mean, team debates are great. I mean, I love. Brian Milner (04:54) Yeah. Mike (05:12) you know, having a team debate, arguing stuff like that, but not about pointless things, right? And not without some sort of foundation. They just kind of get in the way. It's just frustrating for everybody. Brian Milner (05:21) Yeah. Well, I'm kind of curious, what kind of signs or signals do you think teams should look out for to kind of clue in and let them know that what might actually be going on here is more of a mindset issue? Mike (05:36) think sometimes it's when you hear the appeal to authority, right? Somebody says, you know, well, we got to do it this way because the scrum guide says, right? Or the one that annoys me is we have to do it this way because Mike Cohn says, ⁓ you know, that was like, no, I, somewhere else also said, think, right? Don't just, you know, don't just, you know, blindly do story points or something. Cause I say they're a good thing. I want you to think too. Brian Milner (05:50) You You Mike (06:01) And so I think that kind of appeal to authority when teams are debating things. It's where we also see teams who think they're agile because they do a set of practices. We use a particular agile tool, so we must be agile. We do daily meetings. We must be agile. And those are not the things that make you agile. Those are artifacts of being agile. If you're agile, you're going to meet a lot. You're not going meet a lot, but you're going to talk a lot. Um, and so those are the artifacts of behaving in an agile way. And so I want to understand why we're doing those things. So I look for those kind of appeals to authority. Um, you know, emphasis on that type of stuff in an argument talking about how this is the right way saying there's only one right way to do something. Brian Milner (06:49) Yeah, yeah, that's great. How does working on the Scrum team deal with this? How does that address it? Mike (06:55) Well, one of the things we do, it was actually one of my favorite exercises. We do this exercise at the start of the class where we ask people to kind of map out how the organization talks about certain adsel principles and then how does the organization behave. And so for example, if a company says, people are our greatest asset, and then they treat people like dirt, we've got this kind of problem between what we say and what we do. And so I like to kind of map this out. And so we do this with the principles in the Agile Manifesto. And once we map those out and we start to see things that we say we value, but we don't behave that way, really helps us understand if we've really embraced that mindset. Or are we just doing things because an Agile coach told us to, or a boss told us to, or we did it that way in our prior company. Those are all bad reasons to do something. Brian Milner (07:48) Y eah. So this is great. So I agree. The mindset's really foundational. And there is this symbiotic relationship between mindset and practices, which came first and which comes first, as we talked about. I know a lot of teams get stuck doing Agile, though, in really only name only. So when we talk about practices, what makes the difference between going through the motions? Mike (08:00) Mm-hmm. Brian Milner (08:11) and actually doing things that work. Mike (08:13) Well, practices is kind of our second pillar, right? You have to have the mindset, right? But you also have to have the practices that come from having that mindset. so, again, I try to think of that team on a desert island, right? And they're isolated from the world. They've never talked to anybody, but they have an agile mindset. What practices are they going to invent, right? And I think those are kind of the core practices. We see a lot of problems with as an example, teams that misunderstand sprint planning. And I know when I first started teaching about sprint planning, I'd have a slide up there to have a picture of a sprint backlog. And the sprint backlog listed tasks like code this, design this, test this. And then there were estimates next to code this. It's going to take four hours testing. It's going to take three. And so we were able see all these numbers and think the point of a sprint planning was these numbers. And Even in the early days of this, I was always saying, no, it's not about those numbers. It's about deciding what product backlog items you can pick. if taking a, I don't even want to call it an estimate, but taking a wild guess about, it probably can take four hours to code. If that helps you decide how many backlog items you can commit to, great, put those numbers up there. But it was never about the numbers. And it's one of the most common problems that I see with teams in sprint planning is they get obsessed with How many hours did we bring in? How many points did we bring in? And I remember one team I worked with where we did sprint planning. Having those estimates were helpful for them on their sprint back. They were helping. And we finished the meeting. And we're using Google Sheets in a meeting to do this. We've got a row with the estimates in there. And as we start to wind down the meeting, I deleted that column that they'd spent so much time talking about. They're all kind of pissed off at me. Why'd you delete that? We spent all this time talking about it. I said, because we got the benefit, right? You got the benefit of those numbers. The benefit isn't a week from now remembering that you said five hours, because it's going to take what it takes. The benefit was the discussion that it led to of can we take more or are we already full? So I see teams get obsessed with that. This is one example, but that's one of the problems with sprint planning as a practice. Brian Milner (10:25) Yeah. Yeah. I think you're absolutely right. And that's one of the things I know I've talked about with people going through the course is sort of understanding the purpose behind the things. Just going back to, know, harkening back to what you said about, don't just do it because someone told you, you know, understand why the purpose behind it. And, know, otherwise we, I'm sure we've all had that experience before where someone just tells you to do something and says, you know, why? Cause I told you so, you know, that, that doesn't, that's not very convincing. Mike (10:52) Thanks, Mom. Brian Milner (10:53) Right, right, thanks mom. Yeah, not very convincing, but it's much more convincing when they can tell you, well, no, you do this because this is what we're trying to do. And I think you're right, that makes all the difference there. ⁓ Mike (11:05) It just, don't know anybody that responds well to being told what to do, right? My instant reaction is no, right? mean, you it could be, you know, a really, you it could be a really good thing. Eat more vegetables, you spend more time outside. No, right? Don't tell me what to do. So. Brian Milner (11:09) Right. Right. Yeah. It's almost like our default response is no until you convince me. Are there other common practices? We talked about sprint planning. Are there other kind of practices you see teams struggle with? Mike (11:28) Yeah, yeah, for a lot of people. think a huge one is product backlog refinement. I don't know what a better word would be than refinement. refinement is about making the backlog better. It's not about making it perfect. And I see teams that get stuck on backlog refinement and feel like they have to resolve every open issue, that everything has to be tiny and answered and buttoned up before we can start a sprint. And that's not the case. For me, the goal in refinement is to make sure things are small enough and sufficiently well understood. I don't want to bring in a backlog that's bigger than my velocity. If our velocity is 25, I don't want bring in a 50-point story. how about the problems of a 50-point story anyway? But I don't want to bring in some massive epic like that into a sprint. And so refinement is about making it small, making sure it's sufficiently well understood. Sufficiently well understood, not perfectly. And so Brian Milner (12:18) Yeah. Mike (12:28) The problem is these teams, and I know you've seen this, but teams who get in there, want to resolve every open issue. It's like, no, we can resolve that during the sprint. If we think about the goal and planning to make sure we know what to bring into the sprint, not too much, not too little, we're fine just enough that you're at that point. Is the button blue or red? Who cares? If it's a log in story, we're going to lock people out after some number of failed attempts. Who cares how many? Figure that out during the sprint. If it's five or three or eight, who cares? Figure that out later. So I think refinements won. Another big one would be reviews, ⁓ where sometimes teams demo too much in a sprint review. And they feel like they have to justify their existence, show everything you did during the sprint. And the most egregious example of that was this was a handful of years ago. But I literally remember a team showing Brian Milner (12:58) Yeah. Yeah. Mike (13:18) how they had updated the copyright notice on the footer of the web page, know, copyright, you know, whatever year our company, right? And it's like, my God, you didn't need to show that to stakeholders, right? We all either know there's a copyright notice on the bottom of the web page or we've seen one before. I don't need you to bring it up and scroll down to it. Now only took 15 seconds of the meeting, but that was 15 seconds of people's lives. They were never going to get back. you know, show stuff that you need feedback on, right? If you'd... Brian Milner (13:41) Right. Mike (13:45) You fixed a bug and you fixed it only way it could be fixed. Mention it perhaps, but you don't need to show it, right? Brian Milner (13:51) Yeah, yeah, know teams I've been on often it's just it's suffice it to have a list sometimes and just say here's a list of things if you want to know more about these come talk to us but we're move on to the stuff you care about. Mike (14:02) Yeah, I always have like a will show, will not show list. you know, I often, if I'm writing the meetup present, that'll put that up on Zoom or, you know, show it on a screen if we're in person. And often somebody wants to see something that's on the will not show list. Or they just want me to describe what bug was that again? What was that? You know, and I'll explain it really quickly. But if nobody wants to see it, don't bother showing it. So. Brian Milner (14:26) Yeah, I know we talk about these scrum practices quite a bit in the working on the scrum team class, but if someone signed up to take this class, what can they expect to hear or what can they expect to learn about these practices in the course? Mike (14:39) Well, I think one of the things that you and I did together in creating the newest version of the course was to look at what do you actually need to practice doing, and it's feasible to practice doing in a classroom setting, versus what should you just kind of talk through. And not everything needs to be practiced to get the hang of it, right? Everybody in the world has taken something big and split it up into smaller things before, right? I need to make. spaghetti dinner tonight. What do need to buy? Right? OK. Well, that's that's that's test decomposition by noodles, by sauce, by tomatoes. Let's make it from scratch. Right. By some garlic. Right. So everybody in the world has done decomposition. We've broken a big thing into small things. And I remember, you know, iterating over I'm still on sprint planning, I guess. But I remember iterating over exercises in sprint planning and in courses over the decades by now. And I would have one where you're planning a party for your kid, break it down into tasks. It's like, nobody learns anything from this. And so that's one where I'd rather say, OK, this problem occurs in sprint planning. How could you solve it? Other things like, let's say, splitting user stories or splitting job stories, that's a skill worth practicing together, getting feedback on. And so those type of things we try to practice in the course. other things we just talk about. mean, I'm curious on your thoughts on that. What do you think about some things being worth practicing, some things worth being better talked about? Brian Milner (16:01) Yeah, I agree. I agree fully. it's, it's, you know, there's some things, it's kind of like what you said before, there's some things that's not worth spending the time on, and it's better to just have a discussion and move on. Mike (16:13) Yeah. Yeah. I guess that's one of the things we always talked about. We always talked about return on investment of the exercise. What's the return on the exercise? And if you're going to have a one hour exercise, cool. One hour exercise. But it better have a pretty healthy return because that's a lot of time in class. And so what's the return on exercise? Is this worth a practice? Is it worth just a discussion? And if we can discuss two hard problems and give people advice on two common problems, they're probably going to face. Brian Milner (16:21) Yeah. Mike (16:41) Might be better than spending 20 minutes practicing something that they've probably done before. Brian Milner (16:45) Yeah, I completely agree. Let's move to the third pillar then, because I know this is a big one, just thinking and talking about the roles. And just as far as communication issues are concerned, even outside of Scrum, I know that's part of the big problem with teams and organizations just not being clearly defined about who does what and who's responsible for each thing. So those misunderstandings are really common failure points. ⁓ Mike (17:09) Mm-hmm. Brian Milner (17:10) How do you see teams getting that wrong and how's that derailing a Scrum team? Mike (17:15) Well, think we see it all the time on Scrum teams between Scrum Master and Product Owner and even the development team, right? Who does what? I was responding to some comments on LinkedIn this morning on some post I'd made last week and somebody had some comments. And it had to do with whether the Scrum Master or Product Owner does something. And it was interesting because in the comments on that post, I... I don't remember which one it was, but I shared a certain perspective. I feel pretty strongly that I have it right. I mean, I this is how we do it. But there were other people saying the opposite, right? And so, you know, these are people that are probably fairly experienced with Scrum, if they're following me on LinkedIn and feel comfortable commenting on a post, probably feel comfortable with it. And so there's a lot of confusion about what role does what thing. And I don't think this is something where the Scrum guy is going to have the answers for you. I think it's, I mean, you can look at the Scrum guy, oh, this. Here's my starting point answer, but we always want to play to people's strengths, right? And if you've got a scrum master who's got a lot of skill in one area, maybe they shift a little work from the PO to themselves, right? With the PO's permission, right? And the opposite, right? Between maybe PO and team. So it's fine to have default starting positions on who does what, but you always want to play to people's strengths. So I think PO scrum master, I think we see it with project managers and scrum masters, roll confusion on those type of roles as well. Brian Milner (18:38) Yeah, completely agree. A lot of those roles that are not named Scrum team roles and how they interact with the team, that's often a source of confusion as well. What are maybe some signs or symptoms that teams might be having confusion or problems in this area that maybe they don't even recognize or realize they're having an issue with roles? Mike (18:59) Any sort of conflicts, right? You know, you and I arguing over which one of us should do something. The other one would be kind of the opposite, which would be like a dropped ball. I was watching some YouTube video. I love baseball. I was watching some YouTube video the other day of like missed catches or something like that. And some team hit a baseball way up in the air and it was landing near three players, right? Three players are all looking at it. Brian Milner (19:12) You Mike (19:23) One guy waves the other two off, he's going to catch the ball and he must have been blinded by the sun because he's like six feet from the ball when it lands on the ground, right? And, you know, if we have a responsibility to catch the ball, run this meeting, right, right the backlog, the kids dropped, right? And so I think either arguing over who does something, two of us trying to do the same thing or neither of us doing it. I don't mean trying to get out of the work, right? All three players have been happy to catch the ball, but I think you've got it. You think I've got it, right? Those type of things are pretty good signs. think getting clarity around these roles can really optimize how a team works. And I think a really key thing here is that it changes over time. So I'll go back to my example of maybe the Scrubmaster has some skills that can help the product owner early on. Because maybe the product owner is new to the company. The product owner doesn't know the product as well. So they might rely on the Scrubmaster for guidance on things. Well, a year from now, we might shift responsibilities a little bit because now the PO is the expert on all things related to the product. So it's not like we want to establish clarity on roles one time and leave it forever. It's going to change. We get a new tester on the team, things might change. Product owner moves. It's going to change again. So we need to realize these responsibilities are dynamic. Brian Milner (20:39) Yeah, that's a great point. Your point about baseball just made me think about how, when you watch any youth sport in the world, when you go watch your kids play a sport, what's the one thing you always hear people scream from the sideline? Talk to each other. Call the ball. Well, that too. That too. Ump your blind. Those kinds of things. Well, let's talk a little bit about Mike (20:52) I thought you were going say, put my kid in. Brian Milner (21:00) I know this course addresses the roles and how would you say this course really helps address that issue of role confusion? Mike (21:07) think a big part of it is that we designed it to be for everybody on the team, right? Suppose you send a scrum master to a class, and it's a great class. Scrum master is going to back to the certain set of impressions about their role. Product owner goes to an equally good class about the product. They might have different impressions. Even if they took the course from the same instructor, they're hearing it a little differently. They're hearing it through their filters, right? And so when they're in a course together, there's more opportunities to clarify their understanding about those things, especially in the classes designed as we did with this one to bring out some of those differences. So I think the course helps with that. we've also designed it to mention the rules we haven't talked about, like managers and things like that. Brian Milner (21:53) Yeah, yeah, I think those are so important. And there's a lot of great discussions that come out when we have those topics. ⁓ Let's talk about the fourth pillar then, teamwork, because this, I think, builds really well on what we just talked about. And the idea that there's actually, Scrum is a team sport. ⁓ So beyond just normal human personality conflict type issues, what do you see that gets in the way of teams actually Mike (21:58) Mm-hmm. Mm-hmm. Brian Milner (22:18) working as a team. Mike (22:19) think ego is probably one, right? I can do everything better, just leave me alone. There's an old book that says basically, beware of a lone developer in a room, right? You know, it was referring to the developer who wants to close their door and say, I'll it done in a month, trust me, right? And one of the companies I worked with, and this one's going back like 15 years ago, but it was a really good story. Brian Milner (22:36) Yeah. Mike (22:43) is they would literally grab one unit of work. Each person on the team would grab a unit of work and take anywhere from three to 12 months to do the thing. So they were big things, but the person would do everything on it. They'd coded, tested everything. And the organization was putting out very little because of this. When they moved to Scrum in the first year, by their estimate, they said they delivered 540 % more work. over five times the amount of new features delivered. And that was through the collaboration, through the short iterations, those type of things. But it was about getting people to collaborate more. So I think there's huge opportunities to do that. One of the problems I see is when we don't overlap work. If we think about that organization I just described, you grab your thing, you're done in six months. I grab mine, I'm done in seven months. If we'd work together on those things, what's not make us any faster? No faster. But you and I could have worked on your one thing and been done in three months. OK, we're delivering value in three months, right? And so one of the things I look for a lot is how much teams are overlapping work, right? And if we're not overlapping work, there's huge opportunities to improve at that. I'll a little example of this. One of my favorite restaurants is, I don't know, barely call it a restaurant. It's a fast food deli. It's called Jimmy John's. Have you been to Jimmy John's, Yeah. Yeah, there's one near my house where I can go there and the wine will be out the door. Right. And you know, normally you see a wine out the door and it's like, crap, I'm going somewhere else. Right. These guys are so fast. They're so fast. When I get to the front, I place my order. I play this little game of can I fill up my cup? You know, I get an iced tea and they give me an empty cup and can I go fill up ice and put the tea in before they hand me my sandwich? And it's about 50-50. Right. It doesn't take long to fill up your iced tea. But the way they do that is the overlap work. As soon as I order my Italian club sandwich, somebody's already got the bread open, somebody's got a slab of meat they're ready to drop on there, somebody else has their hands over the vegetables and they're dropping the vegetables on there, and then a fourth person wraps it up. And so like four or five people touch my sandwich. Hopefully their hands are clean, but four or five people touch my sandwich as opposed to like most delis where I go and it's like you watch one person plod along making the sandwich, right? Overlap work is huge. Brian Milner (25:07) Yeah. Yeah, this episode sponsored by, no, just kidding. Use code Mike Cohn when you go to, no, just kidding. Yeah, I agree. And yeah, yeah, I'm familiar with Jimmy John's. Probably too familiar. ⁓ Yes, yeah, no, that's, I think that's part of their shtick is that they're, you know, they're known for being fast. So yeah. Mike (25:10) You Is yours just as fast? Yeah. Yeah. They call it Freaky Fast. They actually have a competition. I've seen YouTube videos of this where they get like the best teams at various restaurants race, right? And so they have like the Jimmy John sandwich making Olympics or something, but it's a skill. Brian Milner (25:36) wow, wow, yeah. You should pair that up with the hot dog eating challenge in some way and see if we could have a team sport going there. ⁓ Mike (25:48) Well, that's a good point because think about the hot dog eating. That's one guy, right? That's Joey Chesnett shoving hot dogs down. The Jimmy Johns is a team. They get the best crew at a restaurant and it's a team, right? How fast can the team go? Not how fast can one guy make a sandwich, right? Brian Milner (25:51) Yeah. Yeah, yeah. That's awesome. So what are some tips? What are some ways that you can really unite a team, especially those new teams? Because that's the fascination point for me is, how do you take this group of humans that really don't know each other and haven't worked together in the past and unite them together and have them gel as a team? How do you do that? Mike (26:21) I'll give you a couple. One, I think having really crisp sprint goals helps. So we all know exactly what we're trying to get done in the sprint. We don't lose sight of that because sometimes in the middle of a sprint, you lose sight of it. And you get myopic and you just focus on a list of tasks. And I'm going to say that it's probably similar to the team doing sprint planning and just getting them assessed with the numbers. It's not about the numbers. It's not about the tasks. It's about the backlog items that lead to some goal. So crisp sprint goals help. That's a hard phrase. Crisp Sprinkles helps. The other one I'd say is having a shared vision about where you're headed over a little bit longer term. Probably the biggest change to the Scrum Guide ever that I've liked is the inclusion of a product goal. And that was something I'd been talking about forever. mean, literally since I started doing Scrum was that sprinkles are great, but they're pretty short, right? You want to have something bigger. Brian Milner (26:52) It is. Mike (27:14) And so I like having product goals that are a few months out there. And one of the things I like doing for product goals is have teams do something like write a press release that describes their goal or create a vision in some way, write a review that you want to see come out on the App Store, Play Store, and a magazine. And one of my clients made software and they were reviewed by a major magazine and they were given an editor's choice runner up award. And they actually estimated that being runners up for that was probably worth about $10 million. First place, first time was worth about $10 million a year to them. And so they decided to get serious about this and they wrote a review. Their scrum master, she was actually combo scrum master product owner, Erin. She had the team write a review and she said, let's go earn this review. And I literally remember the email I got from her three months later. It was because it was Halloween night. I just like, you know, brought in the candy from outdoors. We're done trick or treating. And I checked my email. I a three word email from her from Erin. said we did it. And the magazine had let her know, hey, we're reviewing you. be out on, you know, like Tuesday's edition. And the review had quotes in there that were from their vision review, right? The things that they had wanted to achieve. Brian Milner (28:22) Ha ha. Mike (28:35) And that team had just really jelled around that and just became so much more productive and collaborated so much better because of that shared vision. Brian Milner (28:43) Yeah, that's amazing. getting back to the course then, I know in the course we're trying to kind of some of those collaboration muscles. What are some of the ways that the course helps to build that? Mike (28:56) think one of the key things that we're doing, and I'm excited about this, is that we're, you know, we of course use Zoom breakout rooms, right? You you go talk about this, we'll see you in eight minutes or something like that. And for this course, we're doing something where a group of three or more, when they register, can have a private breakout room. And this to me is exciting because people get the benefit of having a private breakout room. They can have sensitive discussions if they want. They can talk very specifically about. you know, what do we do about our jerk product owner? mean, whatever it is, right? You know, they can talk about their specific issues, yet have the context of a broader class. Because I think in one of the benefits of any public class is hearing how other teams are doing things. And sometimes that's because you get a good advice, you know, how did you solve that problem? We have that problem. Other times, it's just feeling that you're not alone in the world. they've got that problem too, right? And they don't have any solution for me, but I know I'm not alone in the world with this. And so I like these private breakout rooms for three or more. I think it's a novel thing we're doing with this class. And it's with the intent of combining the best of both worlds of private and public training for this. I'd the other thing is probably consistency, having everybody on the team hear the same message, having those discussions with an experienced instructor like you or me in the room to provide guidance when they have questions. know, go back to the role clarity, right? You know, they can talk about it and they're there. Then they're back in the main room with you or me and we can kind of answer questions. So I think that consistency will be huge as well. Brian Milner (30:25) Yeah, yeah, I love that idea of the private private breakout rooms that that's that's gonna be huge for a lot of people I know. ⁓ Mike (30:31) I'm excited to try it with this. This will be the first classes we do that for. I'm excited about it. Brian Milner (30:36) Yeah, yeah. Well, let's bring it home then and talk about the fifth pillar because the fifth pillar is really interesting as well. It talks about support beyond the team and teams can only do so much. Every team struggles when they're not supported well. And there's lots of studies that show leadership support is one of the biggest hurdles or obstacles to the adoption. Mike (30:46) Mm-hmm. Brian Milner (30:59) What does that support look like from outside the team and how can a team influence that? Mike (31:06) Yeah, if you're trying to be agile and your HR group has quarterly reviews of personnel that are all based on individual performance and has nothing to do about teamwork in there, it's going to be hard to focus on collaboration. So we have to kind of fix these issues. I think what we have to do here is to have team members educate those outside the organization. And we have information that we share about, you here's how to talk to a boss that's maybe mandating deadlines, things like that. And so we try to coach people through having some of those challenging conversations. And one of things I want teams to do is kind of become an example of what good agile looks like. And if you have a team that's excelling with agile and they're doing it from a kind of principles first, that mindset first approach. You're going to see other groups look at that and let's say the marketing group. They're going to look at that go, hey, that's an interesting way to work. I wonder how we could do that, right? And it's going look different for a marketing group than a tech team. the mindset is going to be the same. Principles will still be the same. And so when we get teams to do really well with this, other parts of the organization start to get interested. And then they stop being as much in our way. Brian Milner (32:20) Yeah. I know one of the most important aspects here and that we talk about is, is that you don't need to, to wait, right? If you're the team level, you don't have to just sit around and wait for the organization to make changes. you, you have opportunities to make changes as well. So how does that happen? How's the team change, you know, bring about those changes that, improve the agile process, the results. Mike (32:42) I think that's by being the example so that people see it. I think it's by having those conversations. You know, one of the things that we'll get is, you know, it's so common is the product owner that wants to change their mind all the time. I was reading something, I guess this is in our Agile mentors community, I think is where it was, but it was about the, you know, the product owner who said his favorite thing about Agile is that he can reprioritize every week. ⁓ And it's like, you can, you know. Brian Milner (33:05) Hmm. Yeah Mike (33:10) I'm not sure it's good. And I think about that, a team gets momentum, right? And you're working on a certain feature. Next sprint, it would be nice to work in that same area of this system, right? Your head's there. Just kind of keep going a little bit. And I've often described this as like, let's say you're working on three backlog items that are in a certain area of this system. Let's make it concrete. Let's say it's the spell checker in Microsoft Office, right? And you do three backlog items related to the spell checker this sprint. Next sprint, maybe your top priority is not more spell checker stuff, but maybe items, I don't know, 25, 26, and 27 on the backlog are still in the spell checker. You know what? It might be better to do those. There are probably two or three sprints away. Let's bring them into this sprint. Just get them done while my head's into spell checking. And so getting product owners or stakeholders to stop doing that, one of the ways that I like to talk about doing that is using an example of ordering a meal at a restaurant. I can order, let's say, the chicken entree. And then as the waiter is taking the orders around the table, I change from chicken, no, bring me the fish. Not a big deal. The waiter is going to cross off chicken and write down fish. If the waiter goes away, brings me back my salad, and I change my mind then, I say, hey, bring me the fish. Might not be a big deal. It's going to be a big deal if I've already taken three bites of the chicken. right? Or if he brings me the chicken. So yeah, we can change our mind, but there's a cost, right? And we want to educate stakeholders about that cost. They don't overdo it. Brian Milner (34:31) Yeah. Yeah. Well, speaking of the leaders and the organization, managers, leaders, do you think this course is appropriate for managers and leaders to attend as well? you feel like they might need to in order to really have this be an impact? Mike (34:55) Yeah, that's a good question. Is it appropriate? Yeah, I think it's appropriate. When we do this privately, we've had plenty of leaders and managers attend. I think it's great. I don't think that's required because they're not on the Scrum team. You said the name of the course is working on a Scrum team. And so they're not on the Scrum team. They benefit by knowing more how their Scrum team works. But I think what we found is that having just a key subset of people who hear the same message work through the training together, and then go back to the organization. That's enough to bring the passion, conviction, and skills that we want. So we don't truly need leaders. They're great. I would never talk a leader out of going, but I wouldn't. If I were a team and I could take the class this month or with my leader next month, I would just get the class done, right? And educate the leader afterwards. Brian Milner (35:41) Yeah. Yeah, yeah, I think that's a good plan. All right, well then we've made our way through the five pillars and for people who have come this far with us and are at this point, if they're listening and they're recognizing some of these problems we've been talking about, what would you recommend to them as next steps here? Mike (35:49) if Well, take a look at our website. If you go to mountaingoatsoftware.com. And then I think there's a courses link on the top. You can go up there and find the link to this course. It's an exciting one that we're doing. I've literally been teaching this, I think the first time I taught a class called Working on a Scrum Team was 2003 or 2004. it's a time tested course. You and I kind of redesigned it a couple of months ago to make it appropriate for public. or little better just in general and more appropriate for public. But it's a time-tested course that's now designed to be available for public settings instead of, you know, have to have 25 people or something. Brian Milner (36:36) Yeah, yeah, that's really exciting. I can't wait to see kind of how people are in, you know, react and interact in the course to some of these concepts and ideas. And we'll, we'll of course link to all these things that we've talked about in our show notes and make it easy for everyone to find the course listing and, and, you know, where the dates and everything that we're going to offer them. So make sure to check that out. Mike, thanks so much for coming on. This has been really enlightening and I appreciate you making time for it. Mike (37:01) Of course, thanks for having me, Brian. Always a pleasure.

We’re taking our own advice and hitting pause to recharge this July. While we’re off the mic, revisit past episodes packed with timeless insights and conversations you may have missed. Overview This week, we're pressing pause to model the sustainable pace we teach. Brian shares a quick update about our summer break, what’s ahead in August, and how you can make the most of the podcast archive while we’re away. Whether you’re poolside or simply stepping back from the daily sprint, we hope you’ll join us in creating a little breathing room and we can’t wait to be back with a fresh season soon. References and resources mentioned in the show: Subscribe & Listen to Previous Episodes of the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Auto-generated Transcript: Brian Milner (00:00) Hey there Agile Mentors, this is Brian Milner and I'm just gonna take a moment of your time today because we're actually going to be practicing what we teach here at Agile Mentors and we're gonna be working at a sustainable pace. So for us that means we're gonna take a few weeks off. It's summer and I know many of you are going to be taking time off with your families and we're gonna be doing the same thing. So we won't be around for the next month. We're gonna be out of here for July, but already have some plans for when we come back in August. So stay tuned when we come back in August, we've got a new season of shows that will begin there in August that I think you'll really enjoy. While we're off, might I suggest you go back through our archive. Look at some of the previous podcast episodes we've done. There's quite a few now. And maybe you've missed some of the episodes from the past. Go back and find some of our great guests that we've had over the years when we've been doing this. I think you'll find some really great guests and some really interesting topics. So fill your diet of Agile Mentors with that while we're at taking a little bit of a break here at Agile Mentors. I hope you're having a great summer and we look forward to seeing all of you back here in August. Take care.

Is AI underdelivering? Or are we asking the wrong questions? This episode breaks down what actually leads to business ROI with AI (and no, it’s not more automation). Overview What if AI isn’t the silver bullet—yet—but the bottleneck is human, not technical? In this episode, Brian Milner chats with Evan Leybourn and Christopher Morales of the Business Agility Institute about their latest research on how organizations are really using AI, what’s working (and what’s wildly overhyped), and why your success might hinge more on your culture than your code. References and resources mentioned in the show: Evan Leybourn Christopher Morales Business Agility Institute From Constraints to Capabilities Report Delphi Method #93: The Rise of Human Skills and Agile Acumen with Evan Leybourn #82: The Intersection of AI and Agile with Emilia Breton #117: How AI and Automation Are Redefining Success for Developers with Lance Dacy AI Practice Prompts For Scrum Masters Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Evan Leybourn is the co-founder of the Business Agility Institute and author of Directing the Agile Organization and #noprojects; a culture of continuous value. Evan champions the advancement of agile, innovative, and dynamic companies poised to succeed in fluctuating markets through rigorous research and advocacy. Christopher Morales is a seasoned digital strategist and agile leader with over 20 years of experience guiding organizations like ESPN, IBM, and the Business Agility Institute. As founder of Electrick Media, he helps U.S. and European businesses harness AI to make smarter, more sustainable decisions in a rapidly changing world.

Laura Kendrick and Cort Sharp hijack the mic to share what it’s really like behind the scenes at Mountain Goat. From Zoom bloopers to unexpected team bonding, they unpack how a fully remote team built a thriving, human-centered workplace. Overview In this special takeover episode, Laura Kendrick and Cort Sharp pull back the curtain on what goes into running hundreds of Scrum and Product Owner classes virtually—and why Mountain Goat's remote team still feels so close-knit. With stories of early tech headaches, Slack banter, hilarious costume moments, and the quiet rituals that keep the team connected, they explore how remote work can actually foster strong relationships and top-tier collaboration. If you’ve ever wondered how to make a distributed team work (or just want a peek at some Zoom-era growing pains), this one’s for you. References and resources mentioned in the show: Laura Kendrick Cort Sharp #61: The Complex Factors in The Office Vs. Remote Debate with Scott Dunn #147: The Power of Quiet Influence with Casey Sinnema Run a Daily Scrum Your Team Will Love Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: 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. Laura Kendrick is the producer of the Agile Mentors Podcast and a seasoned Scrum Master who keeps virtual classes running smoothly. Outside the podcast, she helps clients apply Scrum techniques to their marketing and business strategy, bringing structure and momentum to big, creative ideas. Auto-generated Transcript: Laura Kendrick (00:00) Welcome in Agile Mentors. As you may have noticed, I am not Brian Milner. I am Laura Kendrick, and this is Cort Sharp. And if you have taken a class with us at Mountain Goat in the last five years, there is a good chance that you have met one or actually both of us. Cort Sharp (00:19) I think it's like 90 % chance, 95 % honestly. We've been in so many of these classes. Laura Kendrick (00:26) Definitely, and oftentimes together too with one of us TAing, one of us producing, sometimes one of us teaching court. Cort Sharp (00:33) once in a while, once in a while. Yeah. Laura Kendrick (00:37) So we thought we would come on over here and hijack the podcast to share a little bit about some of the insights that we have gained from doing about a billion, maybe a little exaggeration. Cort Sharp (00:49) Roughly. Roughly. We've done roughly a billion classes with Mountain Goat. Yes. Laura Kendrick (00:56) We have seen a lot in the certifying of Scrum Masters and product owners and advanced product owners and Scrum Masters and all of the evolution of the classes that we have done. We actually hold quite a bit of insight into what is happening in this world. And so we thought we would come in, steal the podcast, and share a little bit of what we have seen, learned, observed, and really just kind of Honestly, some of the laughs and fun that we've had along the way. Cort Sharp (01:25) Also, I think, I don't know, just your intro right there is talking about, hey, we've seen the evolution of these classes. That just got my brain going of like, remember the first class that we did? Way like 2020. I mean, I was in my parents' basement with really terrible internet. It was a struggle. Laura Kendrick (01:40) Yeah. Cort Sharp (01:49) But we were working on like Miro boards or mural. One of the two, forget which, which tool it was, but that was, yeah, that was before team home. And then we got to see the first version of team home. We helped do a little testing with it. And then we've seen it grow all the way into this awesome tool that we have nowadays. And I don't know, just, just to me, I think it's cool to see how we've been iterating and be part of that process of the iteration process, um, to develop these classes and these courses into. Laura Kendrick (01:52) Mm-hmm. Mural. Yep. Mm-hmm. Cort Sharp (02:20) the truly awesomeness that they are today. Personally, I'd rather take a virtual class than an in-person class with Mountain Goat at this point. Laura Kendrick (02:27) It's funny that you say that because I notice actually the iteration of the experience like outside of the tech piece because you know, that's where my brain goes. Here's the difference between court and I. I'm noticing the interactions. But I've noticed, mean how people are interacting a little bit differently in the online space, how even our team interacts, like all of those things has become so much more sophisticated and amazing and Cort Sharp (02:39) Yeah, just a bit. Laura Kendrick (02:54) I mean, honestly, we sometimes talk on our team between like the producing and TA team where like I've referred to it as a perfect game if we don't need anything from the outside team, which occasionally we need a lot of support from the outside team, but we've we've got this down at this point. And it is it's become those first classes. I remember them being super stressful, like, my gosh, the breakout rooms and all the things and just being like, I mean, you couldn't do. Cort Sharp (03:17) Yes. Laura Kendrick (03:21) It was almost like learning how to drive where you felt like if you turned the radio knob up, you might actually turn the whole car. And it was like, so much anxiety. Cort Sharp (03:31) I mean, but we just didn't know Zoom then. Zoom didn't even know itself then, right? What Zoom is, ⁓ for those of you who don't know, we host all of our virtual classes on Zoom. And learning that platform, like I'd used it once maybe for some just, yeah, here's Zoom exists in one of my college classes. That was about it. But yeah, totally. was like, man, what does this button do? Hopefully it doesn't end the meeting and kick everyone out. Laura Kendrick (03:34) Yeah. Yeah. Yeah. That's so true. Yeah, no kidding. But you know what's really interesting too, though, is that it's been over five years now for both of us being part of the Mountain Goat team. And we all work remotely. And other than you and Mike for a little while being right down the road from each other, none of us had any actual interpersonal interaction with each other outside of Zoom email and Slack and the occasional, know, fretted text message of like, are you late? Where are you? Cort Sharp (03:58) Absolutely, yeah, totally. Yeah. Laura Kendrick (04:26) But other than that it like we truly were of and still are a fully remote team and the crazy thing about it is we have at this point once gotten together as a full team in person and it was such an interesting experience being having been fully remote and then being in person and in particular the team that is live on the classes Cort Sharp (04:39) Yep. Yep. Laura Kendrick (04:51) It was a very different interaction because we have this time built into our classes where the team gets on the Zoom call 30 minutes earlier than the students do. And we get this time to just honestly have like water cooler chat and like friend chat or occasionally see Mike get on and you can't hear him, but you can see that he is quite angry at his very elaborate tech system that is not working correctly. Cort Sharp (05:14) you That does happen. Yes, it does. ⁓ Laura Kendrick (05:21) these moments, I feel like they really bonded us together. Because when we got together in person, it was old friends. wasn't even fast friends. It was old friends. And the banter even that goes on in Slack is fun and engaging and not rigid and confining. Cort Sharp (05:31) Yeah. Yes, absolutely. I agree with that. I mean, I'm just thinking back to like the first time because that was the first time I met you in person. aside from being like, wow, she's a lot shorter than I thought she would be. Laura Kendrick (05:47) Mm-hmm. shorter. By the way, court is like 6-4. Cort Sharp (05:55) Yeah, yeah. Not that you're short. But I've just always ever seen like, the profile like the profile picture. That's all that it's really ever been. So I'm like, yeah, you're like, what I would consider normal height, which you totally are. But in my mind, I was like, yeah, it's weird seeing, you know, your legs. That's funny. ⁓ Laura Kendrick (06:14) We digress. Cort Sharp (06:15) But aside from that, was like we've known each other for three, four, four years because we've had that time to get to know each other. We've had that time to talk about just life events, what's going on, where we live, what's happening, what the deal is going on with life. Because we've been very intentional about having that time with that. The 30 minutes before each class were originally very much so used to take care of any tech problems. As the years have gone by, we've for the most part figured out the tech problems. Sometimes, you know, we'll change something out. Laura Kendrick (06:48) Except, hold on, except last week in Lance's class, we were talking about his dog and suddenly it looked as though Lance in his entire room did a cartwheel because the camera just fell. This is not a small camera. Cort Sharp (07:02) It said, nope, I'm out. ⁓ man. Laura Kendrick (07:06) So we still occasionally have the tech problem. Cort Sharp (07:09) Yes we do, yes we do. That's why we still do the 30 vimits. Laura Kendrick (07:14) The crazy thing about that is that when we landed at this in-person meeting, there were members of the team that at that time, and I in particular had never had any interaction with. so like other than the odd email or Slack message, so it was like really knew their name, but didn't really work with them up until that moment. And it was really interesting because at one point, the way that the leadership team had mentioned of like, well, if you need somebody to step in and talk to Mike for you, if you're not comfortable. And I remember looking at court and being like, Mike's the one I'm most comfortable with in this room because of that 30 minutes. I feel like I know Mike. I feel like we have an actual interpersonal relationship where I have no problem speaking up and saying the things that I need to. And that has made like those little water cooler times, those little Cort Sharp (07:54) Yeah. Laura Kendrick (08:06) bantery questions, them asking about my kids or hobbies or whatever. And just knowing those things made a huge difference in our team functioning. The communication across time zones was so much better and easier and safer. Cort Sharp (08:24) Absolutely. We were talking a little bit before we were recording about just people who want pure in-person no matter what. I think at this point, I will always push back on that and say, you might not get that quote unquote collaboration time that's naturally built in, but if you're intentional about it and you provide the space and provide the resources, Laura Kendrick (08:32) Hmm. Cort Sharp (08:50) And also, kind of push people along, have some, I don't know, working agreements or something of, hey, our cameras are on whenever we're talking with each other, unless something like drastic is going on or something's happening, right? Which I think we're going to get into in a little bit, but it's massive. It's crazy. Laura Kendrick (09:03) That's huge. Yeah, I mean, it is. I think we can definitely speak to that in our own experience because we've had, of course, there are moments where people don't have cameras. There are moments where people have bad connections and we'll encourage them in class, like turn off your camera, save your bandwidth. But there are also moments where we are doing private classes for companies. In particular, we've done some with companies that work with like Department of Defense. So there's like real security. issues there and so they don't turn their cameras on. Their cameras are totally disabled on their computers. And it is, I have to say those classes are some of the most like energy draining classes I'm ever present in because I'll be there with the trainer and I feel like I have to give all this emotional feedback because when you are talking to a black screen, that's, it's really hard to just. Cort Sharp (09:47) Hmm. Laura Kendrick (09:58) survive that because you're not getting any feedback from anyone. So you don't know what's happening and you're constantly questioning and the kind of banter in your own mind is like, God, is it landing? Is it not? And you're just not getting any of that physical feedback. So I feel like when I'm on a class with a trainer like that, I feel like I have to be like, that's funny. I'm like, yeah, good point. Cort Sharp (10:19) Yeah, you're kidding. Laura Kendrick (10:21) I'm tired Cort Sharp (10:22) You No, I get that. And I've had some pretty similar experiences too. I might not be as in tune with the emotional side as stated earlier. So I might not help the trainers out nearly as much as I probably should. But I do think cameras on just can make all the difference. And again, situations where it's just not possible. Absolutely understand that. One of our trainers, Lance, he Laura Kendrick (10:39) Mm-hmm. Cort Sharp (10:47) He always likes to throw out the phrase, look, let's approach everything with grace, patience, and mercy. So I like, which I really appreciate, and I like that he throws that out there. But I think that's a good thing to keep in mind of like, know, even though you have the company policy, you have the working agreement, whatever it is that says, look, camera's on all the time, sometimes it's just not possible. Sometimes it just doesn't happen. I recently had to figure out internet in the middle of nowhere, because that's where I live now. Laura Kendrick (10:52) Mm. No. Cort Sharp (11:15) And I was worried for a while that I wouldn't be able to put my camera on. But, you know, if if they came down to that, I know that it would be, hey, you know, it's a it's a unique situation. It's something different. And we're going to do we're going to work the best that we can with it and try to figure out maybe you can turn your camera on for any time you're talking or just any time you have something to say or, you know, if you're agreeing with something, you could briefly turn your camera on to show like, yeah, I'm nodding. I'm agreeing. I'm doing whatever. Right. But Laura Kendrick (11:45) Honestly, I think recently I had a very busy day and we communicate in back channels, of course through email, but also we use Slack as a team. And so I sent a direct message to court about something and I just like, I sent it in a voice? No. And court's response was, didn't know you could do that in Slack. But in those moments, I think there are other ways of doing it too, where you can bring the humanity out, where it's not just words. Cort Sharp (12:01) Yeah. Laura Kendrick (12:09) So often I'm actually thinking about there was one time that you and I were talking about something and I misread it as like, I like kicked something, like some hornet's nest in there. Like you were upset with me, but you were like, no, that was not my intention. And it's an amazing thing that that's only happened once in five years. There was that subtle nuanced miscommunication of I thought I had offended in some way and I hadn't. Cort Sharp (12:18) So. Yeah. Laura Kendrick (12:34) Just keeping that in mind though, in written word, tone is interpreted because probably what happened is I like offended my kid or my partner and was bringing that into the conversation with court. And it had nothing to do with what was actually happening, but adding in those personal things of your face, your voice, those things really do help move that human connection, which enables the teamwork that we've seen at Mountain Go. Cort Sharp (12:42) Yep. Yep. Mm-hmm. Laura Kendrick (13:00) I mean, it's amazing the way this team functions and it is not perfect. There are definitely communications missteps. There are definitely like, oops, forgot to leave that piece out of the information packet. It happens. It happens to everybody, but we're able to recover really quickly or even it's a safe enough space to be able to speak up and say, I think I got left out on this. And it's responded to in a really gracious and amazing way. Cort Sharp (13:26) It absolutely is. I mean, Mountain Goat's been remote for longer than the COVID stuff, the pandemic stuff happened. Laura Kendrick (13:33) Yeah. Well, Lisa's been with them for what, 10 years? I think it was nearly 10 years when we started, maybe 15. And Hunter's around the same. So yeah, they've been spread for a long time. Cort Sharp (13:42) Something like that, Uh-huh. ⁓ I know that they had an office space and that office space changed just in case people wanted to like come in, come to the office. I think at one point, one of them was in Colorado, which is kind of funny because several people live on the West coast. And then it's like, okay, yeah, come on, come on, swing by the... Colorado office on just a random Tuesday. Yeah, fly in, have fun. I don't know. Yeah, why not? I don't know what the deal was or what it was like, but they've been fully remote. And I think with the kind of runway that they've had leading up until the time where everyone had to be fully remote has really benefited Mountain Go in a lot of ways, because a lot of those early, like, how do we work remote? How do we do this? Laura Kendrick (14:09) I'd do that. Yeah, let's do it. Cort Sharp (14:31) kind of was ironed out, but back to your, your point to just like, it's, it's incredible how much support there is. It's incredible how much, how well communication again, it's not perfect, but how well we're able to communicate with each other and how well we're able to just say, yeah, let's, let's hop on a call real quick or here. I think most of us have like personal phone numbers. We, we use that as a very much so last resort type deal. Laura Kendrick (14:57) Yeah. Cort Sharp (14:59) But even then, it's nice to just have those open lines of communication and know that those are always available, but also know that people are kind of in our corner all the time too. And I think you have a pretty good story about this one. Something happened in a class a few years ago. Laura Kendrick (15:09) Mm-hmm. Yeah. Yeah. It was early on we had, it was a non-Mike class. So it was one of the other instructors and there was a student who was just challenging. And in the end, it didn't go well in the moment, to put it, just to kind of like not go into grave detail about it. But Mike wasn't there, right? And so The thing that was interesting though is the first piece of communication that came from Mike, which was before that class even broke, right? Because it was one of those things of like, we have to share. As a team, we can't hide it. We have to share that something happened in class that was less than ideal. And so we did. And the immediate response from Mike was in support of the team. And later on, he did go and review the tape of the, because the classes are recorded, not for this purpose. They're recorded actually so that the students get a recording of the class afterwards and can return to what, you know, all the things that they learned because it's a lot to take in in two days. But in this one instance, it was beneficial in this way because Mike could actually see rather than taking people's words, what happened. And I think the important thing is not even what happened after, but what happened in the moment. that he instantaneously was like, I've got you. Like no matter how this goes, we're a team and I'm gonna support you as well. And that was actually, that was pretty early on for me. And it was in a moment where I didn't know Mike that well yet. And it was actually this very solidifying moment for me that was like, I'm in the right place. Like I am part of this team, not just a minion or an employee. Like they care about all of us. Cort Sharp (16:48) Mm-hmm. Laura Kendrick (16:56) and we're in this together, even if it turns out that we're in some form of trouble, it's still going to be thoughtfully managed and handled rather than just the kind of lashing out that can happen in so many environments. Cort Sharp (17:12) Right. And, and that experience, cause I think we were all included on that email. Like I, I wasn't in the class when it happened, but I do remember getting that email and it just was a clear communication from kind of head honcho Mike, right? A top dog saying, yeah, no, we, we got your back. on, we're on the same team. We're all working towards the same goal. And when I, when I read the email, I was like, wow, that was an eventful class. but. Laura Kendrick (17:26) Mm-hmm. us. Cort Sharp (17:38) My second thought, my second thought was, huh, this very similar to what you were saying of like, wow, this is a great place to be. This is a great company to work for. These are great people to be working with and alongside. ⁓ but also like, I know so many people whose managers, whose higher ups would say, Nope, you're in the wrong. You should have done better. Your toast, blah, blah, blah, blah. Like putting all the blame on you. Absolutely. Yeah. Yeah. Laura Kendrick (17:52) Mm-hmm. Yeah. The knee jerk. Yeah. Yeah. Cort Sharp (18:07) And it just, makes me think all the time of like one really blessed, like very fortunate to be here, very fortunate to work with mountain goat. but also people don't quit jobs. They quit managers. They quit leadership more often than not. And, not that I'm talking about quitting mountain goat, but, neither, neither of us are throwing that out there right now, but just like, Laura Kendrick (18:20) Mmm. Yeah. No, but interestingly in five years, I've not seen anybody quit. I mean, we've had people kind of go down separate paths, but nobody has been throwing their hands up and been like, I'm done. I can't be in this. There have been people who have taken other opportunities that they needed to take for their own businesses. But yeah, nobody's quit. In five years, no one has quit, which speaks volumes to the culture that is created in an environment where Cort Sharp (18:37) Mm-hmm. Laura Kendrick (18:57) And I also want to be clear that that response from Mike also, it wasn't disparaging to the other party either. It was simply a, like, it just let us know that I see you and this, you were in a hard moment in the moment and you had to react like a human being and you as a team, I've got your back and this is, you know, great. And to be fair to that was like in the heat of COVID. Cort Sharp (19:24) Yes, yeah It was yeah Laura Kendrick (19:27) good times. But there's also been a lot of fun that's happened in class too, which is, I think that makes a big difference. Like where we are, I don't want to say allowed because I don't think that's right, but like part of the culture is to have fun. Like Mike is a pretty funny guy. Brian's a pretty funny guy. Like honestly, the whole team is quite humorous and it's, we're allowed to like make these really fun things and Cort Sharp (19:48) Yes. Laura Kendrick (19:52) in response to like when we see them in class, like, we foster those two and it becomes this really fun working environment, not only for us, for our students. You brought up one that I had totally forgotten about with the costume. That was good. Cort Sharp (20:06) ⁓ yeah, I, I, yeah, I'll, I'll get into the costume thing, but I think the word you're looking for instead of allowed is enabled. Like we're, we're enabled to have fun. We're encouraged. Absolutely. Yeah. A hundred percent. If you ever hung out with Mike or, or taking a class with him, you've probably heard some funny stories. Laura Kendrick (20:13) Yeah, Encouraged, in fact. And my gosh, the one class too where Mike was asked how long they'd have access to like the videos and stuff. my gosh, Mike ended the class and it was a super engaged Chipper class. Everyone was laughing and Mike brought it down. Cause he did his usual thing where he talked about, what does he say? You have access as long as the internet exists and I'm alive. And then he went into great detail. great detailed speculation about what will happen once he's not alive. It went on for like five minutes. Cort Sharp (20:58) Yeah, where where he's like, yeah, you know, my kids will probably be like, what's this? What's this old website that dad's still hosting? Guess we'll we'll close that up 10 years down the line or whatever. Laura Kendrick (21:09) Dumbfounded. It was so good. But anyhow. Cort Sharp (21:13) man. But there was, I don't even remember why this happened in the class. don't think it was around like Halloween time or something. think the person, actually, I think the person does this to go to like local children's hospitals or local hospitals and just visit. But I get on and I'm normally the PM producer. So I normally hop on in the afternoon. And I took over from Laura and Laura Kendrick (21:22) No, it wasn't. think so. Cort Sharp (21:39) Laura was like, yeah, you know, pretty normal class. This happens, whatever. We're good. And I hop on and people start turning their cameras on. And then all of a sudden there's this dude in a Captain America costume. Like what? He's got the mask. He's got the, the, the uniform. He's got the shield and everything. And I was like, what is happening? What is going on? Come to find out he was telling his story. Laura Kendrick (21:50) Like full on math. Cort Sharp (22:04) Yeah, I do this. This is cool. And Mike was like, that'd be awesome to see. He went out, put it on and took the rest of the classes Captain America. So we have certified Captain America. Laura Kendrick (22:12) Awesome. We've had, there was the guy who was put on like a crazy hat for the first session and then came back for session two with a different crazy hat. And then other people started wearing crazy hats. And by the end of it, like by the final session, almost the entire class was sitting there with some like their kids stuff on their heads. it was. Cort Sharp (22:34) You Laura Kendrick (22:36) But was this one, like it stands out of the billion classes we've done. It stands out in our minds as these really fun moments. I remember the class where it was a private class, so it was for a company or team. And there were, it took me until the very end to, it was early on, so it took me until the very end to get up the gumption. There were five mics in the class. And finally I was like, I'm just gonna put them all in the same room and see if anybody notices. Cort Sharp (22:36) People just... Yes. Didn't they notice like right away, they all came back and they're like, team Mike is back in action or something, right? Laura Kendrick (23:04) I don't think they said anything, but they did. The instructor went into the room and like, yeah, they noticed. Good. My passive aggressive humor worked. Cort Sharp (23:10) Hehehehehe It's fun. It's all good. But it's also like going back to us being able to do this before I figured out kind of my background situation, I would always put up virtual backgrounds and I would just change your background every time and see if people noticed. And it wasn't, it was a lot of Disney. Yes. Laura Kendrick (23:23) Mm-hmm. Disney. That's the thing though. That also, that kind of stuff built a little bit of a relationship as well. like it was, court was always going to have something for Disney. I had one that I would, when I finally found the one I liked, I kept that one for a long time. And Mike would occasionally, when I wasn't in a class, he would send me a screenshot of somebody via email and be like, somebody's in your house with you. Cause they would have the same background. Cort Sharp (23:52) Yeah! Laura Kendrick (23:56) those little tiny things make the relationships and make the team function and make us giggle. So I'd be like out with my kids and see an email and be like, oh no, Mike, what does he need? And then click in and be like, you know, actually more often than not, it would probably be like, am I missing class? See, I'd be like, oh, that's funny. But you know, it builds that relationship. And I think it's why this remote working has worked so well for us. And I'm totally with you where I, when people are Cort Sharp (24:13) You Yeah. Laura Kendrick (24:26) railing against it because of my experience. like, you're crazy. This is great. Cort Sharp (24:31) Exactly. I'm like, how can you not want to just chill out, hang out in your home, chat with some people, get some work done, and like, you're good. Who despises that? Who doesn't like that? don't know. It's, Exactly, yeah. But I do think it does, it comes down to being intentional with it. We were talking about that 30 minutes before that used to be primarily tech troubleshooting. Laura Kendrick (24:47) I know, you get to do things on your own time too. Cort Sharp (25:01) but has since kind of evolved into, okay, so everything, like, I don't know about you, but the vast majority of time, unless a camera's fallen, the vast majority of time, it's, all right, does everything look good? Yeah? Cool. Sure does. Whoever I'm working with, awesome. So, what'd you do this weekend? how was this? ⁓ sorry, sorry that the Avs lost to the Dallas Stars. Yeah, I'm sorry too. Stuff like that, right? Where it's just, Laura Kendrick (25:19) Yeah. It's water cooler talk. Cort Sharp (25:29) It's fun, but we're very intentional with having that time to do that. And I think if you're not intentional in setting up that time, whether if you're working remote hybrid, you're not going to get it. And it's not just going to naturally happen because it is so much more difficult to produce. it's impossible for it to just kind of naturally pop up without taking away from some other intentional time. so I think in, in this this world that we're living in where there is the option to work remotely and there is this really big push to go back in person. I'm saying stick with remote, take your 15, 15 minute daily standup, and turn it into, you know, say, Hey, I'll be on 10, 15 minutes early. If anyone wants to come hang out, come chat. And make it worth it. Make it a valuable time because that is the time to connect and that is the time to say, yeah, cool. How are the kids? How was your weekend? Did you grill up some good hot dogs during this last weekend? What'd you do? Like, what was going on? ⁓ Build up that stuff. Laura Kendrick (26:23) Yeah. We also have Slack channels too, that are like that. Like there's a Slack channel for our team that's just movies, books and TV shows. That people, it'll get active at certain times and it'll be totally dead for a while and nobody's cultivating it. It's simply that somebody will pop in like, I just watched this and it's great. And they've set up also like the automatic bots, cause Mike's a big fan of James Bond. So like if somebody mentions James Bond, the Slack bot will say something quippy and it- Cort Sharp (26:39) Yeah. ⁓ Laura Kendrick (26:58) But it adds that little, like, little bit of humor, little bit of humanness to even though, like, the people that we have time to interact with like that is the team that's in class. So I don't, I mean, it wasn't until we were in person that I met our CTO. He was kind of an enigma, you know? Cort Sharp (27:10) Yeah. Mm-hmm. He was just in the background. Things just magically showed up digitally. Laura Kendrick (27:23) It was in my email and my Slack sometimes, but it creates that thing of like, now I know things about Hunter. Yes, of course it was because we were in person. I heard lots of stories and all that fun stuff. But also I know about like some of his like TV watching stuff. I know occasionally like what his wife likes to watch because sometimes he'll like pepper in something that, she dragged me into this and not my cup of tea. But it's those little bitty things that you start to learn about the people. Cort Sharp (27:39) Mm-hmm. Laura Kendrick (27:50) that makes them human and gives that space. And I also, think it's important to have it be a little bit of white space. so often we talk about cultivating the conversation and like, can you have icebreakers and get people engaged? And yes, those things are so important, but when it's with a team, you need to do those things, but you also need to create the empty space where maybe you have that daily standup or that... weekly meeting or monthly meeting, whatever that is for your team. And maybe at the end of it, it's just leaving the call going and allowing people to just talk. I mean, we did that as a producer team that we would have a meeting as producers that would be very structured and then kind of the official meeting would end. And there would be times where as a team we'd be on that Zoom. I'm like, thank goodness nobody needs this channel. Cause like we'd be in there for like two and a half hours. Cort Sharp (28:26) Yeah. Yeah. Laura Kendrick (28:42) just talking. And of course, it wasn't, you know, it wasn't billing time. It wasn't, you know, it was just us being friends and hearing each other and sometimes ranting and complaining and doing the things of like, this part was hard and like, yeah, well, people need the space to do that and feel seen and heard. And the only place they're going to get that is in the white space. Cort Sharp (29:01) Yep. Exactly. Yep. And where my head went when you were talking about the white space, I love where you just went to because that's absolutely very true. But where my mind went was the newest kind of Slack channel that that's been set up, which is the artificial intelligence. Yeah. Where we just we just it's cool because I'm interested in AI. I think everyone's interested in AI right now. Things are things are going in all sorts of wild directions with it. There's there's all sorts of possibilities that we can do with it. Laura Kendrick (29:17) ⁓ Yeah, that one's Yeah. Cort Sharp (29:32) And Hunter just threw out, who wants in? If you want in, cool, I'll get you in. If not, and you're not interested in AI, let me know when you are, because it'll be at some point, I was going to say. It's just another full group one. Yeah, we just. Laura Kendrick (29:39) Yeah. Pretty sure the whole team's in there. But it is fun. Like Hunter and Mike do deep dives and Brian too. And I'm like, wow, I just get to swim in that pool. It's really Cort Sharp (29:50) Yes. Yeah, yeah. You just kind of get a glean from what's posted in there and say, oh yeah, I am really interested in the automation side of AI. I want to do, I think I threw in there one time, like this whole GitHub repository that has just from zero to hero AI, here's a two week crash course. And I've been working my way through that. It's taken a lot longer than two weeks for me. I've been working my way through that. And it's opened my eyes to say, okay, now this awesome thing, think Mike just threw in there something about someone using it at Disney, I think it was, and how they were using it at Disney to propose, here's a cool way that we can use AI to help our proposals go faster or help our marketing campaigns go faster or whatever it is. And just learning and seeing and... Laura Kendrick (30:38) Yeah. Cort Sharp (30:44) growing together as a team as well and having that space of, yeah, you know, here's what here, here are these articles that I'm reading. Here's the ones that stuck out to me. And to have that space, I think also is, is really interesting to me too, not just because I like learning, but it's also like, I feel like, okay, I can talk with Mike about AI. I can talk with Hunter about AI. I can talk with whoever about it. And we're all relatively on the same page because we're all relatively getting the same information. Laura Kendrick (31:14) Yeah, yeah. I feel like having the Slack channel has been really helpful and all the white space and even honestly the in-person event, there was white space built into that too. There was definitely a lot of structured meetings because of course when you are bringing everyone in from all over the country and actually the world, have a team member who is in the UK too. Cort Sharp (31:26) yeah. Laura Kendrick (31:37) flying a great distance and being in a space together, it's got to be structured. You have to make that worth the time and effort and investment. But also there were dinners, there were shows that happened, there was fun built into it, and there were options of not just like, I'm forcing you to go to this, but like, here's a choice. Would you like to do this or that? And those things have made a huge difference in breeding the like belongingness. Cort Sharp (31:55) Mm-hmm. Laura Kendrick (32:05) and the feeling like we are actually a team. And even though there are definitely times where the frustrations arise, of course, I mean, who doesn't have frustrations, but it's a space where they can be vocalized, they can be talked through, and it's all due to that togetherness that we have, that connectedness that has been built through, honestly, Cort Sharp (32:05) Yeah. Mm-hmm. Laura Kendrick (32:30) just being in these like casual fun spaces is where that comes from in my opinion. Cort Sharp (32:36) Yeah, I agree with that. Just having the space to talk about whatever. But I think it's all rooted in communication, right? So in various methods of communicating and various ways of communicating too, where it's not just exclusively Slack, email, written text, we have that space there. But we do still run into some communication problems, right? There's... Laura Kendrick (32:41) Yeah. For sure, for sure. Cort Sharp (32:58) there's all sorts of communication problems that we're gonna run into because especially we are text-based heavy, but we're not exclusively text-based. But I think you were talking about a story where Mike was late one time or Mike's late story about communication and what was going on with that. Laura Kendrick (33:12) he tells it in class. He tells a story in class with that. It's one of his examples that he will pull into fairly frequently with an experience with a team where somebody was always late to the daily standup and they realized that it had to do with the fact that they had to drop their kid off at school. And so it was that simple communication shift of asking instead of assuming, asking which... They've put into practice too, like I recall early on hearing like, do you prefer to be communicated with? And like we've had these conversations that court and I have a tendency to be more slack people. But Brian has stated that for him, like when he's teaching slack is like his emergency line. And so like knowing that I'm not going to send him something through slack unless I desperately need him to see it when I can land it in his email versus Lisa and Laura are much more Cort Sharp (33:43) yeah. Mm-hmm. Mm-hmm. Laura Kendrick (34:04) they're going to be in the email. Like that's just where they live and they are less likely to be in Slack. So it's just knowing those things have also helped us build the right kind of streams of communication. I'm pretty sure Hunter is everywhere all at once. Like he's omnipresent. You can get him anywhere. I know it. I'm in New York and he's in California. I'm pretty sure if I whispered his name, he's hearing it right now. Cort Sharp (34:06) Right. my gosh. He's the enigma. He's the enigma everywhere. I was gonna say, I'm surprised he hasn't popped into this. We've said his name three times. It's, he just knows everything and he's always got everything coming through and no matter what you need, he's any message away. Slack, email, could be carry your pigeon. I don't know, something like that, right? Laura Kendrick (34:43) Yeah, his next Halloween costume needs to be Beetlejuice, so I'm sending that to him. my goodness. But I think at the end of the day, the practices that have been put into place that you may have felt in our classes too, have helped really grow this team into what it is. There's a lot of strength here. There's a lot of fun here, but there's a lot of hard work here too. And a lot of, there have been hard moments where we've all just kind of put our heads down together and moved through the hard moments as a team with a lot of support and a lot of. Cort Sharp (35:12) Mm-hmm. Laura Kendrick (35:15) Just trying to be in it and be like kind of move things where it needs to go. I don't know what the right word is as a team. It's redundant. Cort Sharp (35:22) I think it. Yeah. But I think that that does show in our classes a lot, right? You and I have both taken a class outside of the mountain goat sphere, ⁓ and I'm not I'm not dogging on anyone. I'm not trying to talk down on anyone. But I got out of that class. I was like, man, we are light years ahead of that. Laura Kendrick (35:30) Mm-hmm. Mm-hmm. Cort Sharp (35:49) that kind of interaction and that kind of experience. was the information that I got out of that class was awesome, superb. It was great. But just the amount of energy and effort and time that has been invested into these Mountain Goat courses, it's far and away just, it shows. And it shows how much of a level up it is to take a class with Mountain Goat. And I do think partly, you know, I'm boosting my own ego here. But I do think partly it is because we are surrounded with some awesome people and we have some awesome people working together and awesome support on every call, every class that you take with us, right? You don't have to, like the instructor can focus on just instructing. And we, more often than not, we are typically in charge of everything else. Make sure that any tech problems, any issues, anything that's going on, right? Yeah. Laura Kendrick (36:32) Yeah. Yeah. I remember the early days. Like you just brought up a memory that apparently I had stored in the trauma bank. I remember the early days though being, because I would often, because I'm on the East Coast, court is in mountain times. So, often I would be the early person just because it's easier for me. was mid morning for me. we would start class and it would be just, especially honestly when like people were figuring out Zoom and all this stuff, it was... stressful. Like they were just, it was just question, question, question, problem, problem, problem. And we would get to the first breakout and I would send everyone away and the instructor would be like, that was great. And I'm like, was, you know, just totally frazzled. But the point was, is no one else felt that. And it was, I was in my Slack and working with the team, working with Hunter, things fixed, working with Lisa, making sure the person was in the right place. Cort Sharp (37:20) Yeah, glad. Mm-hmm. Laura Kendrick (37:33) and doing all these things. And though that has died down because we've all gotten very good at our job and the systems in place are amazing at this point, it still is like, that's the whole point. We worked as a team so that the instructor could deliver an amazing class and be present with his students. And we could be here or her, because we do have hers too, I should say. They're students. And we were here taking care of the things that needed to be taken care of, which was, yeah. Cort Sharp (37:54) Yes. Laura Kendrick (38:00) Though I had forgotten about that. Thanks for that. Cort Sharp (38:02) Yeah, sure. Yeah, it's gotten easy, right? ⁓ Laura Kendrick (38:04) Yeah, it does. But that's at the end of the day, that's how a good team is. I think that we can kind of end it with this thing of Mike has created this environment and it definitely comes from him. Like it's is rooted in the founder for us because we're a small team, small but mighty. But he it's rooted in his like engine of creativity, efficiency, and just love of innovation. And that has kind of Cort Sharp (38:18) Mm-hmm. Laura Kendrick (38:34) folding that in with seeing all the people as humans, and with flaws and different talents and all those things and human interaction is messy and folding all of that in has actually been what has bred these amazing class experiences for our students and also this rewarding and fantastic team experience for the people behind the scenes as well. And I think the lesson Cort Sharp (38:39) Yes. Yep. Laura Kendrick (38:59) comes from that, that if we can fold those things in together and make space for humans to be humans and also have this amazing expectation of creativity and innovation, then it's all going to happen. Cort Sharp (39:06) Mm-hmm. Mm-hmm. Yeah, absolutely. I 100 % agree with that. I mean, it does come down to Mike and Mike is a fantastic leader. It's awesome. I also want to raise Mike, but. Laura Kendrick (39:28) Nice. Not passive aggressive at all. On that note. Cort Sharp (39:29) Yeah, you know. No. I'm just joking, right? We're able to have fun. We're able to joke around. But it does come down to leadership, right? And I think that's true on any team. And we have just we've been so fortunate to be able to experience it firsthand and go through this awesome transformation from being in person to fully remote, even in the class teaching stuff. And it's been really, really fun. really, really enjoyable. I, you know, you don't love every day. There are jobs, right? It's a job. But I'm not gonna lie. I'm not gonna lie. It has been fun. It has been enjoyable. But I don't look back on it and be like, wow, these last five years were just all terrible. No, it's we've had great leadership. We've had great interactions with with everyone. And I think Laura Kendrick (40:05) You should have just left it at really, really fun and enjoyable. Mic drop, goodbye. Cort Sharp (40:28) It's just come down to the people that we're working with and the people that we're engaging with consistently. And our leadership, Mike, has fostered an environment very, very well that is around fun, around communication, around enabling us to grow, to learn, to try new things, to move forward. And I really feel bad for companies who don't have that kind of leadership. that's, it's a tough spot to be in, but, I'm really, we're really blessed and really fortunate to, to be able to work here. And I hope this, this little peek behind the curtain, kind of encourages you to you, the listener, guess, whoever, whoever's out there to take a, take a little step back and say, okay, what, what am I doing as a leader within my sphere of influence to help my team be a little more human and embrace the humanity side of stuff? Not just pushing for more, we need more, more productivity, more AI, more everything, right? Yeah. Use AI, make it a tool, but just remember you're, building stuff for, for people. You're working with people all the time. And I think that's something that Mike has never forgotten and never will forget and never will let fall to the wayside that we're all people and we're all here working with each other. Laura Kendrick (41:43) Yeah. Couldn't agree more. Well, on that amazing note, thank you, Cort, for joining me in this hijacking of the podcast, the Agile Mentors podcast. And we're going to turn it back over to Brian, who's going to walk you right on out. Cort Sharp (41:54) Happy to.

What does it really mean to have a bias toward action and how do you build that into your culture without skipping strategy? Boris Gloger joins Brian Milner for a deep dive on experimentation, leadership, and the difference between tactical work and true strategic thinking. Overview In this conversation, Brian welcomes longtime Scrum pioneer, consultant, and author Boris Gloger to explore the tension between planning and doing in Agile environments. Boris shares how a bias toward action isn’t about skipping steps—it’s about shortening the cycle between idea and feedback, especially when knowledge gaps or fear of mistakes create inertia. They unpack why experimentation is often misunderstood, what leaders get wrong about failure, and how AI, organizational habits, and strategy-as-practice are reshaping the future of Agile work. References and resources mentioned in the show: Boris Gloger LinkedIn Leaders Guide to Agile eBook Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Boris Gloger is a pioneering agile strategist and Germany’s first Certified Scrum Trainer, known for shaping how organizations across Europe approach transformation, strategy, and sustainable leadership. As founder of borisgloger consulting, he helps teams and executives navigate complexity—blending modern management, ethical innovation, and even AI—to make agility actually work in the real world. 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 as always, Brian Milner. And today I have the one, the only Mr. Boris Glogger with us. Welcome in Boris. Boris Gloger (00:11) Yeah, thank you, Eurobrein, for having me on your show. Brian Milner (00:14) Very excited to have Boris here. For those of you who haven't crossed paths with Boris, Boris has been involved in the Scrum movement, I would say, since the very, very earliest days. He's a CST, he's a coach, he's an author, he's a keynote speaker. He had a book early called The Agile Fixed Price. He runs his own consultancy in Europe. And he has a new book that's been, that's going to be coming out soon called strategy as practice. And that's one of the reasons we wanted to have Boris on is because there's kind of this topic area that's been percolating that I've heard people talk about quite often. And I see some confused looks when the, when the topic comes up, you hear this term about having a bias toward action. And, we just wanted to kind of dive into that a little bit about what that means to have a bias toward action. and really how we can apply that to what we do in our day-to-day lives. So let's start there, Boris. When you hear that term, having a bias toward action, what does that mean to you? Boris Gloger (01:12) The fun thing is I was always in tune with the idea because people said my basic mantra at the beginning of doing agile was doing as a way of thinking. So the basic idea of agile for me was always experimentation, trying things out, breaking rules, not for the sake of breaking rules, but making to create a new kind of order. the basic idea is like we had with test-driven development at the beginning of all these agile approaches and we said, yeah, we need to test first and then we have the end in our mind, but we don't know exactly how to achieve that. So there is this kind of bias towards action. That's absolutely true. On the other hand, what I've always found fascinating was that even the classical project management methodologies said, Yeah, you have to have a plan, but the second step is to revise that plan. And that was always this, do we plan planning and reality together? And actually for me at the beginning, 35 years ago, was exactly that kind of really cool blend of being able to have a great vision and people like Mike and all these guys, they had always said, we need to have that kind of a vision, we need to know. Yeah, if the product owner was exactly that idea, you have to have that vision, but you really need to get the nitty-gritty details of, so to say, of doing this stuff. Brian Milner (02:40) Yeah, that's awesome. And the thing that kind of always pops to my head when I think about this is, we hear this term bias toward action and there's sort of this balance, I think a little bit between planning and action, right? I mean, you wanna plan, you wanna plan well, but you don't wanna over plan. You don't wanna waste too much time trying to come up with a perfect plan. You wanna... you want to do things, but you also don't want to be, you don't want to rush into things. So how do people find that balance between not just, you know, going off, you know, like we say in the U S half cocked a little bit, you know, like just not, not really not ready to really do the thing that you're going to do. Cause you didn't really invest the time upfront, but on the other hand, not spending so much time that you're trying to get the perfect plan before you do anything. Boris Gloger (03:28) You know, the problem, for me, the issue was solved by when I figured out that the teams typically struggle not to achieve, for instance, the sprint goal or the end or whatever they wanted to accomplish when they have not the right know-how. So it's a knowledge problem. So for instance, I don't know if this is still the case, but sometimes developers say, need to... to immerse myself with that I need to figure that out. I need to get the new framework before I can do something about estimates or something. So whenever you hear that, that you know that person that just tries to give you an estimate or the team that would like to come into a sprint goal or whatever it is, they are not really knowing what topic is about. It's a knowledge gap. And then people tend to go into that analysis paralysis problem. They don't know exactly what they need to do. So therefore they need to investigate. But by doing investigation, you start making that big elephant in the corner, larger and larger and larger and larger because you go that ishikara diagram, you have too many options. It's like playing chess with all options at hand and not have enough experience. What kind of gambit you would like to do. So everything's possible and by, because you have not enough experience, you say everything's possible, that creates too much of a planning hassle. And Agile, is the funny thing is, made us very transparent by just saying, okay, let's spend maybe two weeks. And then we figured out two weeks is too much. So let's do a spike, then we call it a spike. The basic idea was always to have a very short time frame, timeline where we try to bring our know-how to a specific problem, try to solve it as fast as possible. And the funny thing was actually was, as if I I confess myself that I don't know everything, or anything, sorry, that I don't know anything, then I could say, I give me a very short timeline, I could say I spend an hour. And today we have chat, CVT and perplexity and all that stuff. And then we could say, okay, let's spend an hour observation, but then we need to come up with a better idea of what we are talking about. So we can shorten the time cycle. So whenever I experienced teams or even organizations, when they start getting that planning in place, we have a knowledge problem. And a typical that is, is, or the classical mindset always says, okay, then we need to plan more. We need to make that upfront work. For instance, we need to have backlogs and we need to know all these features, even if we don't know what kind of features our client really would like to have. And the actual software problem is saying, okay, let's get out with something that we can deliver. And then we get feedback. And if we understand that our kind of the amount of time we spend is as cheap as possible. So like we use the tools that we have. We used to know how that we have. We try to create something that we can achieve with what we can do already, then we can improve on that. And then we can figure out, we don't know exactly what we might need to have to do more research or ask another consultant or bring in friends from another team to help us with that. Brian Milner (06:46) It's, sounds like the there's a, there's a real, kind of focus then from, from what I'm hearing from you, like a real focus on experimentation and, you know, that, that phrase we hear a lot failing fast, that kind of thing. So how, do you cultivate that? How do you, how do you get the organization to buy in and your team to buy into that idea of. Let's experiment, let's fail fast. And, and, we'll learn more from, from doing that than just, you know, endlessly planning. Boris Gloger (07:12) I think the URCHAR community made a huge mistake of embracing this failure culture all the time. We always tell we need to call from failure because we are all ingrained in a culture in the Western society at least, where we learned through school our parents that making failures is not acceptable. Brian Milner (07:18) Ha ha. Boris Gloger (07:32) And I came across Amy Atkinson and she did a great book to make clear we need to talk about failures and mistakes in a very different kind of way. We need to understand that there are at least three kinds of mistakes that are possible. One is the basic mistake, like a spelling error or you have a context problem in a specific program that you write or you... You break something because you don't know exactly how strong your material is. That is basic mistake. You should know that. That's trainable. The other is the kind of error that you create because the problem you try to solve has too many variables. So that's a complicated problem. You can't foresee all aspects that might happen in future. So typical an airplane is crashing. So you have covered everything you know so far. But then there's some specific problem that nobody could foresee. That's a failure. But it's not something that you can foresee. You can't prevent that. You try to prevent as best as possible. And that's even not an accepted mistake because sometimes people die and you really would like to go against it. So that's the second kind of mistakes you don't like to have. We really like to get out of the system. And then there's a third way kind of mistakes. And that is exactly what we need to have. We need to embrace that experimentation and even experimentation. mean, I started physics in school and in university and an experimental physicists. He's not running an experiment like I just throw a ball around and then I figure out what happens. An experiment is a best guess. You have a theory behind it. You believe that what you deliver or that you try to find out is the best you try to do. The Wright brothers missed their first airplane. I mean, they didn't throw their airplane in the balloon. Then it gets destroyed. They tried whatever they believed is possible. But then you need to understand as a team, as an organization, we have never done this before, so it might get broken. We might learn. For instance, we had once a project where we worked with chemists 10 years ago to splice DNA. So we wanted to understand how DNA is written down in the DNA sequence analyzer. And I needed to understand that we had 90 scientists who created these chemicals to be able to that you can use that in that synthesizer to understand how our DNA is mapped out. And we first need to understand one sprint might get results that 99 of our experience will fail. But again, management said we need to be successful. Yeah, but what is the success in science? I mean, that you know this route of action is not working, right? And that is the kind of failure that we would like to have. And I believe our Agile community need to tell that much more to our clients. It's not like, we need to express failure. No, we don't need to embrace failure. We don't want to have mistakes and we don't want to have complicated issues that might lead to the destroying of our products. need on the other hand, the culture, the experimentation to figure out something that nobody knows so far is acceptable, it's necessary. And then, edge our processes help us again by saying, okay, we can shorten the frame, we can shorten the time frame so that we can create very small, tiny experiments so that in case we are mistaken, Not a big deal. That was the basic idea. Brian Milner (11:04) That's a great point. That's really a great point because you're right. It's not failure in general, right? There are certain kinds of failures that we definitely want to avoid, but there's failure as far as I run an experiment. at that point, that's where we start to enter into this dialogue of it's not really a failure at that point. If you run an experiment and it doesn't turn out the way you expected, it's just an experiment that didn't turn out the way you expected. Boris Gloger (11:30) Basically, every feature we create in software or even in hardware, we have never done it before. So the client or our customers can't use it so far because it's not there. So now we ship it to the client and then he or she might not really use it the way that we believe it is. Is it broken? it a mistake? It was not a mistake. It was an experiment and now we need to adapt on it. And if we can create a system, that was all that was agile, I think was a bot. On very first start, if we can create a system that gives us feedback early. then that guessing can't be so much deviation or say in a different way, our investment in time and material and costs and money and is shortened as much as possible. So we have very small investments. Brian Milner (12:13) Yeah, that's awesome. I'm kind of curious too, because, you know, we, we, we've talked a little bit at the beginning about how, you know, this is part of this bias towards action as part of this entrepreneurial kind of mindset. And I'm curious in your, experience and your consultants experience that you've worked with big companies and small companies, have you noticed a difference in sort of that bias toward action? Uh, you know, that, that kind of. is represented in a different way in a big company versus a more small startup company. Boris Gloger (12:48) The funny thing is I don't believe it's a problem of large corporations or small, tiny little startups, even if we would say that tiny little startups are more in tune in making experiments. It's really a kind of what is my mindset, and the mindset is a strange word, but what is my basic habit about how to embrace new things. What is the way I perceive the world? Every entrepreneur who tries to create it or say it different way, even entrepreneurs nowadays need to create business plans. The basic ideas I can show to investors, everything is already mapped out. I have already clients. I have a proven business model. That is completely crazy because If it were a proof business model, someone else would have already done it, right? So obviously you need to come up with the idea that a kind of entrepreneur mindset is a little bit like I try to create something that is much more interesting to phrase it this way. by creating something, it's like art. You can't, can't... Plan art, I mean, it's impossible. I mean, you might have an idea and you might maybe someone who's writing texts or novels might create a huge outline. But on the other hand, within that outline, he needs to be creative again. And someone will say, I just start by getting continuous feedback. It's always the same. You need to create something to be able to observe it. that was for me, for me, that was the epiphany or the idea 25 years ago was, I don't know what your background is, but I wasn't a business analyst. Business analysts always wanted to write documents that the developer can really implement, right? And then we figured out you can't write down what you need to implement. There's no way of writing requirements in the way that someone else can build it. That's impossible. And even philosophers figure that out 100 years ago is written, Shanti said, you can't tell people what is the case. It's impossible. So, but what you can do, you can create something and you can have it in your review. And then you can start discussing about what you just created. And then you create a new result based on your observations and the next investment that you put in that. And then you create the next version of your product, your feature, your service, et cetera. Brian Milner (15:12) Hmm. Boris Gloger (15:25) And when we came back to the entrepreneur mindset and starting companies, Greaves created exactly that. He said, okay, let's use scrum to come up with as much possibilities for experimentation. And then we will see if it works. Then we can go on at that. And large corporations typically, They have on the one hand side, have too much money. And by having too much money, you would like to get an investment and they have a different problem. Typically large corporations typically needs to, they have already a specific margin with their current running products. And if you come up with a new business feature product, you might not get that as that amount of of revenue or profitability at the beginning. And therefore, can't, corporations have the problem that they have already running business and they are not seeing that they need to spend much, much more money on these opportunities. And maybe over time, that opportunity to make money and that's their problem. So this is the issue. It's not about entrepreneurial mindsets, it's about that. problem that you are not willing to spend that much money as long as you make much more money, it's the same amount of time on your current business. It happens even to myself, We are running a consulting company in Germany and Austria, and Austria is much smaller than Germany's tenth of the size. And if you spend one hour of sales in Austria, you don't make that much money in Austria than you make in Germany. this investment of one hour. Where should you focus? You will always focus on Germany, of course. means obvious. Brian Milner (17:08) Yeah. Yeah. Boris Gloger (17:10) Does it make sense? Maybe I'm running so. Brian Milner (17:14) No, that makes sense. That makes sense entirely. And so I'm kind of curious in this conversation about action and having a bias toward action then, what do you think are some of the, in your experience in working with companies, what have you seen as sort of the common obstacles or barriers, whether that be psychological or. organizational, what do you find as the most common barriers that are preventing people from having that bias toward action? Boris Gloger (17:44) the they are they are afraid of the of that of tapping into the new room endeavor. So that was always my blind spot because I'm an entrepreneur. I love to do new things. I just try things out. If I've either reading a book, and there's a cool idea, I try to what can happen. But we are not And most organizations are not built that way that they're really willing to, when most people are not good in just trying things out. And most people would really like to see how it's done. And most people are not good in... in that have not the imagination what might be possible. That's the we always know that product adoption curve, that the early adopters, the fast followers, the early minority, the late minority. And these inventors or early adopters, they are the ones who can imagine there might be a brighter future if I try that out. And the other ones are the ones who need to see that it is successful. And so whenever you try implementing Scrum or design thinking or mob programming or I don't whatever it is, you will always have people who say it's not possible because I don't have, haven't seen it before. And I sometimes I compare that with how to how kids are learning. Some kids are learning because they see how what is happening. They just mirroring what they see. And some kids are start to invent the same image in imagination. And but both that we are all of us are able to do both. It's not like I'm an imaginary guy who's inventing all the time and I don't, people, maybe there's a preference and the organizations have the same preference. But typically that's the problem that I see in organizations is based on our society and our socialization, on our business behaviors and maybe the pressure of large corporations and all that peer pressure is Brian Milner (19:34) Yeah. Yeah. Boris Gloger (19:54) The willingness to give people the room to try something out is the problem. Well, not the problem, it's the hinders us of being more innovative in organizations. Brian Milner (19:59) Yeah. Yeah. Well, that brings to mind a good question then too, because this experimentation mindset is very, very much a cultural kind of aspect of an organization, which speaks to leadership. And I'm kind of curious from your perspective, if you're a leader, what kind of things can you do as a leader to encourage, foster, of really nurture? that experimentation mindset in your organization. Boris Gloger (20:34) Let's have a very simple example. Everybody of us now maybe have played with chat, CPT, Suno, perplexity and so on. So that's the school AI technology around the corner. And what happens now in organizations is exactly what happens 30 years ago when the internet came here. You have leadership or managers who say, that's a technology, I give it to the teams, they can figure out whatever that is. And the funny thing is, if you have a technology that will change the way we behave, so it's a social technology, a kind of shift, then I need to change my behavior, I need to change the way I do I'm doing things. Yeah, everybody of us has now an iPhone or an Android or whatever it is, but but we are using our mobiles in a completely different way than 30 years ago. And to lead us and manage us, we need to train ourselves first before we can help our teams to change. So the problem is that Again, a lot of Agilist talks about we need, first we need to change the culture of organizations to be able to do Agile and so on and so on. That's complete nonsense. But what we really need to is we need to have managers, team leads, it with team leads, to help them to do the things themselves because Agile, even in the beginning, now it's technology change, now it's AI, is something that changes the way we do our stuff. It's kind of habit. And we need to help them to seize themselves. Maybe they can only seize themselves by doing that stuff. And that goes back to my belief that leadership needs to know much more about the content of their teams and the way these teams can perform their tasks and the technology that is around to be able to thrive in organizations. Brian Milner (22:40) Yeah. Yeah. I love this discussion and I love that you brought up, you know, AI and how that's affecting things here as well. how do you think that's having a, do you think that's making it easier, harder? How do you think AI is, is kind of influencing this bias toward action mentality? Boris Gloger (22:59) Yeah, it depends on if you are able to play. mean, because the funny thing is, it's a new kind of technology. really knows what all these tools can do by themselves. And it's new again. It's not like I have done AI for the next last 10 years and I know exactly what's possible. So we need to play. So you need to log in to adjust it. Yesterday, I tried something on Zulu. I created the company song in 10 seconds. I went to ChatGVT, I said I need a song, I need lyrics for a company song. These are the three words I would like to have, future, Beurus Kluger, and it needs to be that kind of mood. ChatGVT created the song for my lyrics, then they put the lyrics into the... And they created a prompt with ChatGVT and then put that prompt in my lyrics into Sono and Sono created that song within 10 seconds. I mean, it's not get the Grammy. Okay. It's not the Grammy. But it was, I mean, it's, it's, it's okay. Yeah. It's a nice party song. And now, and just playing around. And that is what I would like to see in organizations, that we start to play around with these kind of technologies and involve everybody. But most people, the very discussions that I had in the last couple of weeks or months was about these tools shall do the job exactly the same way as it is done today. So it's like... I create that kind of report. Now I give that to Chet Chibati and Chet Chibati shall create that same report again. That is nonsense. It's like doing photography in the old days, black and white. And now I want to have photography exactly done the same way with my digital camera. And what happened was we used the digital cameras changed completely the way we create photography and art. changed completely, right? And that is the same thing we need to do with ChatGV team. And we need to understand that we don't know exactly how to use it. And then we can enlarge and optimize on one hand the way we are working, for instance, creating 20 different versions for different social media over text or something like that, or 20 new pictures. But if I would like to express myself, so, and... and talk about my own behavior or my own team dynamic and what is the innovation in ourselves, then we need to do ourselves. And we can use, that is the other observation that we made. The funny thing that goes back to the knowledge issue, the funny thing is that teams typically say, I don't know if it's in the US, but at least in my experience, that we still have the problem within teams. that people believe this is my know-how and that is your know-how and I'm a specialist in X or Y set. So they can't talk to each other. But if you use maybe chat GPT and all these tools now, they can bridge these know-how gaps using these tools. And suddenly they can talk to each other much faster. So they get more productive. It's crazy. It's not like I'm now a fool with a tool. I can be a fool and the tool might help me to overcome my knowledge gaps. Brian Milner (26:20) Now this is awesome. I know that your book that's coming out, Strategy is Practice, talks about a lot of these things. Tell us a little bit about this book and kind of what the focus is. Boris Gloger (26:30) the basic idea when I started doing working on the on strategies, we be in the the actual community, we talk about strategy as what is a new idea of being OKR. So OKR equals strategy, and that is not true. And I came up with this basic idea, what is the basic problem of of strategic thinking and we are back to the in most organizations, we still believe strategy is the planning part and then we have an implementation part. And years ago, I came across a very basic, completely different idea that said every action is strategy. Very simple example. You have the strategy in a company that you have a high price policy. Everything you do is high price. But then you are maybe in a situation where you really need money, effort, revenue issues, liquidation, liquidation problems. Then you might reduce your price. And that moment, your strategy is gone. just your obviously and you have now a new strategy. So your actions and your strategies always in line. So it's not the tactic for the strategy, but tactic is strategy. And now we are back to Azure. So now we can say, okay, we need kind of a long-term idea. And now we can use for creating the vision. For instance, you list the V2MOM framework for creating your vision. But now I need to have a possibility to communicate my strategic ideas. And in the Azure community, we know how to do this. We have plannings and we have dailies and we have reviews and retrospectives. So now I can use all these tools. I can use from the bookshelf of Azure tools. I can use maybe OKRs to create a continuous cycle of innovation or communication so that I get that everybody knows now what is the right strategy. And I can feed back with the reviews to management. that the strategy approach might not work that way that they believed it's possible experimentation. And then and I added two more ideas from future insight or strategic foresight, some other people call it. So the basic idea is, how can I still think about the future in an not in the way of that I have a crystal ball. But I could say, how can I influence the future, but I can only influence the future if I have an idea what might be in future. It's like a scenario. Now you can create actions, power these kind of scenarios that you like, or what you need to prevent a specific scenario if you don't like that. And we need a third tool, that was borrowed from ABCD risk planning, was the basic idea, how can I get my very clear a very simple tool to get the tactics or the real environmental changes like suddenly my estimates might not be correct anymore or my suggestions or beliefs about the future might not get true in the future. So I need kind of a system to feed back reality in my strategy. it's a little bit like reviewing all the time the environment. And if you put all that together, then you get a very nice frame how to use strategy on a daily practice. It's not like I do strategy and then have a five-year plan. No, you have to do continuously strategy. And I hope that this will help leaders to do strategy. I mean, because most leaders don't do strategy. They do tactic kind of work. and they don't spend They don't spend enough time in the trenches. to enrich their strategies and their thinking and their vision. because they detach strategy and implementation all the time. That's the basic idea. Brian Milner (30:30) That's awesome. That sounds fascinating. And I can't wait to read that. That sounds like it's going to be a really good book. So we'll make sure that we have links in our show notes to that if anyone wants to find out more information about that or learn more from Boris on this topic. Boris, can't thank you enough for making time for coming on. This has been a fascinating discussion. Thank you for coming on the show. Boris Gloger (30:40) Yeah. Yeah, thank you very much for having me on your show and appreciate that your time and your effort here. Make a deal for the, it's very supporting for the agile community. Thank you for that. Brian Milner (30:57) Absolutely. Yeah, yeah, thank you.

Can you lead meaningful change without burning people out—or yourself? Sherri Robbins thinks so, and she’s sharing how she’s done it in high-stakes, high-complexity environments (with her sanity intact). Overview In this episode, Sherri Robbins joins Scott Dunn to talk about what it actually takes to lead large-scale change across teams, departments, and vendors without losing sight of your values—or your people. From agile leadership lessons and real-world mistakes to personality-aware management and learning how (and when) to let teams fail forward, this conversation goes far beyond frameworks. If you’ve ever tried to implement something new and wondered why it didn’t stick, this one’s for you. References and resources mentioned in the show: Sherri Robbins Switch: How to Change Things When Change Is Hard by Chip Heath & Dan Heath Start With Why by Simon Sinek Five Lessons For Agile Leaders Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Sherri Robbins is a 20+ year veteran in the medical device industry, blending strategic execution with deep regulatory and quality systems expertise to lead enterprise-wide transformations. She’s a thought leader in Agile implementation, known for aligning cross-functional teams, building psychological safety, and driving change that actually sticks.

How do you lead change when you’re not the boss? Casey Sinnema shares what it takes to build trust, influence outcomes, and make Monday feel a little less dreadful. Overview What happens when you give a self-proclaimed utility player the freedom to poke holes in broken systems and lead cross-functional change without official authority? In this episode, Scott chats with Casey Sinema about navigating ambiguity, building trust without a title, and leading impactful change through curiosity, clarity, and a deep understanding of what people actually need. References and resources mentioned in the show: Casey Sinnema Wolf Pack by Abby Wombach The Let Them Theory by Mel Robbins Micromanagement Log Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Casey Sinnema is a self-described utility player who’s built a career by asking great questions, poking holes in broken systems, and leading meaningful change across teams—without ever needing the official title to do it. With a background in accounting and a talent for cross-functional problem solving, she brings curiosity, empathy, and real-world savvy to every challenge she tackles. Auto-generated Transcript: Scott Dunn (00:01) Well, welcome everyone to another episode of the Agile Mentors Podcast. I am your takeover, not your normal host, of Brian Miller, who's done a smash up job over a hundred plus episodes if you haven't checked those out. But part of the podcast takeover was not only a fresh voice, but also perspective and a lot of what I typically focus on for the people who know me. On leadership and culture and leading change. And I thought of no one better that I'd rather talk to about some of this. Casey Sinnema and I'll give you a little bit of introduction about who she is, what she does. Maybe also I think it'd be fascinating Casey on how you yourself in the role that you have. I think it's kind of a cool role, at least on paper. You can flesh that out a little bit more but I'll hand off to you. Tell us a little about yourself. Casey (00:46) Yeah, hey, thanks for having me. Yeah, so I currently am most often referred to as a utility player. And I'm still trying to figure out my elevator speech for how I talk about what I do because my role, my title is manager, which doesn't say much, right? And I actually don't do a function, but the easiest way to talk about it is I'm a project manager of sorts. I'm involved in a wide variety of projects from a varying level of involvement, from leading the project to leading the change to being a key stakeholder to just being the voice to leaders or executives or that type of thing. So yeah, I am a little bit of everything. And I got here on accident. I have... Scott Dunn (01:32) I was... Casey (01:34) You know, way back in the day when I was, you know, doing the like, what am I going to do for the rest of my life? I'm like, I just want a marketable skill. So I have a business degree and I went into accounting and I quickly became the troubleshooter. So I would go into a company, troubleshoot, fix the process, fix something broken, and then find myself in another company doing the same thing. And, so throughout my career, I've just sort of built this unique set of skills that allow me to poke holes in processes. and help companies fix them and then kind of find the next thing. So that's just kind of how I wound up here. I've been at my current company for almost a decade, which is going to be a record for me. And, but I'm still doing the same thing. I'm moving around the company and finding new places to, you know, rock the boat a little bit. Scott Dunn (02:20) Cool. Very cool. Yeah. It does sound like you have a number of things on your place to where that makes kind of expand on that a little bit and where you comfortably share those stories as we go through some of this because there's a lot, there's a lot more underneath based on what Casey shared before. And I love it that you found yourself like a happy accident and I guess have enough challenges and learning and growth there as long as they move you around that you're, you know, you need to be working on that are meaningful. things to be working on. Casey (02:51) Yeah, absolutely. That's the biggest thing, right? Is to like find work that you find valuable and that has an impact on the people around you, which is, know, squarely aligned with my values. Scott Dunn (03:01) Well, you touched on one thing that I know a number of other people could relate to and I could too as well as the kind of troubleshoots process can just easily see that things aren't working at a larger view. Some of that. maybe add on a little bit. What is it like about your role? For those who are kind of thinking they're in quasi space, they can hear you talk about that role and like, hey, that sounds like me too. What are the points of that different projects, different things you're involved with that that's what really lights you up? Casey (03:27) Yeah, I, it's so interesting because a lot of us find that the things that we're good at are the things that, you know, give us energy and that motivate us, right? I happen to be uniquely skilled at poking holes in things, including in my own life. So it works in my personal life as well. I could just sort of see things from different perspectives and find the gaps. And so it just sort of on accident. I think what's interesting is Scott Dunn (03:43) You Hmm. Casey (03:53) throughout my career and throughout my life, the biggest challenge has been to hone that skill for good, right? To lead with kindness and to manage my expectations along with the expectations of the world around me and troubleshoot the things or poke holes in things that need holes poked in instead of like everything. You know what mean? Scott Dunn (04:15) I love that. Two things that I want to, I guess, add on a little bit more there. One, you mentioned something and the other thing is I think you might just put out there like, same thing from different perspectives. I imagine for the people, we've all been around folks who just they only think their way. And you're just kind of reflecting on that. But Keith, it sounds like you can go into a meeting and you can hear three different state views and you can genuinely understand from their perspective why that's important to them or why that's a problem to them, right? If I'm hearing you. Casey (04:42) Yeah, absolutely. That's really key in all of the different types of projects that I've played a part in, right? Like hearing things from different people's perspectives and really understanding what they're looking to get, what they need and what's in it for them and being able to connect those things across stakeholders. Scott Dunn (04:59) Yeah, that's powerful. Yeah, but looking for commonality, alignment, et cetera. I do think there's a specialness, and we've talked about it a bit, like in the facilitation class, that looking for those folks having common and generating alignment is a unique gift that we just don't see a lot in corporate people kind of lobby for what they want. And actually, it's, it would be an afterthought to think about other people's perspectives and yet who draws different areas of the company together who are to get some new about the door or whatever like that. So you're kind of touching on that, which I think is really powerful. Is there anything that you see as like a go-to mindset that you bring in those situations or go to like tools that you're kind of using, whether that's things you're doing in writing down or in mural or even just how where your head is at when you walk into some of those meetings where you feel they have different perspectives and on the same page, you're supposed to walk out of that session on the same page. Casey (05:51) Yeah, the first one is to sort of leave my ego at the door, right? What I think is the right thing can't come in the door with me, right? Like I, of course I'm influencing, right? Where I feel like it matters. But it's not, I'm probably not the decision maker and the people that are not on the same page, when they need to get aligned, they need to be able to get there on their own. So what I think is the right way, I got to leave it at the door. So that's my number one thing. Scott Dunn (05:57) heheheheh. Casey (06:18) And then the next thing I do is just really stay curious, ask lots of questions, actively listen, model that active listening behavior so that everybody else is also actively listening. That's a big thing. And really just sort of helping people find a common language, I think, is really important. So I do a lot of restating what I'm hearing so that other people can maybe hear it from a different set of words and connect it. Scott Dunn (06:29) Hahaha Casey (06:42) more readily to the way that they're thinking about the topic. Scott Dunn (06:45) Yeah, you say these as if they're like, I mean those are short little pithy statements, but boy, powerful. I think it reflects an attitude beginning with what he said as the ego is like, we might know a whole lot, we gotta leave that at the door. Just at work, awesome. Here and you say something, I'm making notes like this would be good in life too, right? In personal life and relationships, stay curious, active. Don't assume that the way you see it is reality, right? So, I think that's super. The other thing you mentioned though was about Go ahead. Casey (07:17) I will say I'm better at it at my job than in my personal life because, Scott Dunn (07:23) Of course, I think, yeah, for everyone listening, they're like, me too. Why can't I do this? I can tell some stories. So the other one, though, you should just poke holes as if like, it's this little thing we're doing. But there might be something inside. I think I might be able to relate that is driving perhaps towards this isn't running as well as it could, or this isn't running. I think we know that, or this could be better. Something inside you that that you feel is churning, that you're seeing holes no matter what that is, if it's a small process, large process, a team, multiple teams. Tell me a little bit more about what does that mean to you when you say poke holes in things? What's running through your mind? Casey (08:01) Yeah, it's complex, right? Because sometimes it's really easy. This is broken. you know, right? Or there's a bottleneck, something that's really like you can, it's data driven, you can see in the data where something is not working well, that those are the easy ones, right? And you can just start asking sort of the five whys or the finding the root cause of what's happening there. Scott Dunn (08:06) Those are the easy ones, yes. Casey (08:26) But in the case where there's friction or there appears to be barriers or there's just this. any kind of challenge or even when there's not a challenge, quite frankly, I have this unique ability to like listen across people and across like data and technology. That's a weird thing to say is listen across technology, but I sort of just find where things are misconnected or disconnected and start to ask questions there. And so I can find something that maybe isn't working as well as it should without anybody else noticing which. Scott Dunn (08:35) Yeah. Casey (08:59) I've learned I need to be careful with. Scott Dunn (09:01) That's great. So at least the next question was any hard lessons, anything so you could do a redo on that one that you could pass on so someone else doesn't have to learn the hard way from Casey's experience. Casey (09:11) Ha yeah. Everything I learned, I learned the hard way. So if you feel like that's what you're doing, you're not alone. Yeah, the thing that I have learned probably the most often, and I will learn it several more times in my career, I'm sure, is when I think I have found something, go make sure it's true before you start to really socialize it. So like, I'm going to go ask the question of the expert. Scott Dunn (09:20) Ha Whoa. Casey (09:42) before I bring it up because maybe I'm not seeing it from all of the right angles or maybe I don't understand exactly what it's doing or quite frankly maybe I'm missing some context. And so really talking and building relationships with people who are experts on the topic or in the field is really kind of where I start. Scott Dunn (10:00) was great, great period. the number of times we miss out on relationships, especially in that one, really key. Casey (10:00) And. Yeah. Scott Dunn (10:08) I think I'd add to that though. sometimes I'll phrase it as rather wait to be sure than lose capital because if I go out saying things that aren't true. So sometimes we'll jump in on the outing side and they'll be like, why haven't you gotten yet? And I'll be clear, like, I'd rather wait and be sure than hurry and be wrong. And then we got to that mess before we get back to the work we're supposed to be doing. And sometimes it's a while to pick that up, depending on who got affected by We'll put out there sometimes innocuously, we thought, well, here's the numbers results. And someone's like, that's actually not correct. But now everyone knows we have now we have a PR problem, something like that. So I'm not alone in that. I've been there. That's a tough one. But also on the coin, though, what would you point to as wins if you look back like that's talking about? That's why this is important. That's what you feel good about. Casey (10:54) Yes, absolutely. Yeah, I think from a win perspective, the, a really good example, I'm going to go way back in the day. I had a, a chance to work, in a motorcycle dealership and we had huge, was, you know, weird economic times, right? And so there's weird financial things happening in this, you know, motorcycle dealership company and, and, everybody's just trying to stay afloat and You find the like the friction between either the mechanic shop and the, the sales shop. And when you find those and you can solve those problems and make the experience smooth for the, for the client, right. For the customer and make that like walk in the door experience consistent and smooth. This in this case was just people, right? It wasn't even technology. wasn't really a process. It was just people. And the biggest wins are when like. the people start to notice. And then what happens is everybody's life gets better and everybody has more fun doing whatever it is that they're doing. And it just changes the vibe. Scott Dunn (12:08) I love that. I love that. I do believe very much like the work that we could be doing here. People enjoy their work more people enjoy coming to work. doesn't have to be a place that people don't want to be in or watching the class. I love you touching on that's great. Casey (12:21) Yeah, there's a balance there, right? Like, because they call it work for a reason. It's a job. We don't love everything that we do all of the time. But, you know, are we doing the things that we can do to make life good for ourselves and for others? Scott Dunn (12:33) Yes, so nice segue because what I feel like I've learned later in my career, we'll just phrase it that way, that the importance of self-care, taking care of ourselves so that we have the energy and attitude to keep doing work that we're doing, especially if you're a leading changer, in some ways you're a change artist trying to bring that about, change agent, it can be taxing. So are there things along the way that are either You just know a good way that you take care of yourself could be learning, could be space, could be the road you carry, or that you actually do to protect yourself and that work-life balance emotionally, mentally. you aren't kind of aware of, what does it look like to do good self-care and help make sure you're taking care of yourself to deliver good value in the workplace. Share what that means to you and maybe some of the things that you do. Casey (13:21) Yeah, it's so important, right? Like I am also not in the early stages of my career and still learning how to take care of myself and protect myself and, you know, build good boundaries, right? I, yes, yes. So I have good personal routines, right? Like I do yoga, I meditate. I'm a big fan of podcasts and. Scott Dunn (13:31) Hahaha Right. Boundaries is a good word, yes. Casey (13:46) I'm a learner, so I'm always learning. Maybe there's a boundary there too, like how much can you self-improve before it becomes, I don't know, toxic? But when it comes to boundaries, really it's, I start with the relationships, right? Like at work, making sure that my expectations are clear and that of my leadership chain is clear no matter what job I'm in. Scott Dunn (13:47) Hmm. you Casey (14:11) and setting boundaries that are clearly expressed so that I can protect myself and my personal life and that balance, and I can deliver the way that I'm expected to deliver. And that just makes life easier for me. Scott Dunn (14:23) Super, super, super, super. I'm thinking there's a lot of people. I it's a ways back. We cover accommodative and assertive, you know, as far as power styles and the cowl. And what's been fascinating for all these years, most people are all on the accommodative side. When I hear you say something like, hey, the expectations clear or use the word bad, that sounds like someone who has a balance of, no, I'm there for people, but I don't overextend myself to where I no good. Casey (14:23) Thank Scott Dunn (14:50) I burned something like that. So I think that's really great for everyone to hear. It hurt to define the relationship with make sure your expectations are clear for me. And then sometimes, you know, there's someone else that could take that on or might play this role, etc. But sometimes we're so helpful that we overload ourselves and actually don't do good job. We do, you know, average job on a lot of things instead of a job on a few and they could have found maybe someone else. think that's awesome. You said podcasts, there other ways, is that your way of learning? there other things that you, as far as what, for the learning side? Casey (15:26) Yeah, so books are my go-to. I'm somebody who does a lot of highlighting and note taking and flagging in books, because I'm always going back to them. And I love to learn things that are sort of outside of my lane, if you will. It's kind of how I got involved in Agile. I have a business degree in finance, and Agile doesn't really play into that until it does, right? And so I started to like, I'm curious about that, or I'm curious about Six Sigma or those types of things. And so I just sort of go find them and take the nuggets that apply directly to me and put the other ones on the shelf for like when it does apply to me, if you know what I mean. Um, so I just, I'm a learner, so I'm always looking to, to, to learn new things. I'll be frank, podcasts for me, I'm not learning things. I'm entertaining myself. Scott Dunn (16:20) I try, I try to really be focused to get, I like listening, but yeah, the actually applying is not as much. I'm definitely same about I'm a higher. Someone said the difference in studying is the pin. So I'm always like, unless I'm marking it up, am I really digging into this book or, or Kendall? So I'm to hear I'm not alone on that one. So I want to shift a little bit because some of what we've done is leading change. think the conversation we had were around. Casey (16:38) Absolutely. Scott Dunn (16:45) So moving around from just you to the broader culture, how would you describe what a great culture like or feels like? Maybe some of us haven't even been in a great company so they don't know. They can't picture, imagine what that could be like. And you've been to a number of places with different roles. What's good culture, great culture look like in your opinion? Casey (17:06) Yeah, I think that it's gotta be a cliche out there. I'm pretty sure I've seen it on a meme, but good culture is defined by how you feel on Sunday night, right? Like if you're not dreading going into work on Monday, right? Like you probably are in a culture that's a good fit for you because I think culture doesn't have a one size fits all perspective. Like big companies, small companies, different types of work, different groups of people. sort of lend themselves to different kinds of culture. I've been in companies where the culture is great for me and everybody else is miserable. And companies where the culture is great for everybody else and I'm just not a good fit. So I think that in general, good culture is... I talk about it in this like self-awareness perspective. If the culture itself is a little bit self-aware, then it is what they say it is. So if you say your culture is one thing and everybody agrees, including the culture, including the behaviors of what's expected in the environment, if all of those things are aligned, the culture is probably good, even if there are people who aren't good fits for it. I don't know if that answers your question. That's my perspective. Scott Dunn (18:03) Hehehehe That's great. Oh, it's it's better. That one's a good wrap up now. Like that really to me, it's a bit of a mic drop because it's so good. It's simple. But you're right. How you feel on Sunday night? A ton about what's happening with you and the job you have and what's happening around you. Absolutely. And that different like sometimes it is just a fit because a lot of people can be excited about it, but you're bothered by it or might rub you wrong. And I know we've gone through the values in the class as well. I've been at companies where we're absolutely about get stuff done and that's fine. But it's kind of a burnout. I love the very collaborative, but sometimes I'm like, man, I want to get stuff done. I'm getting frustrated that we're like, we really connect and talk a lot. I don't see stuff happening. So you're right. Obviously, you know, some people are sensitive to that. And that last piece about like the behavior. it should be considered. And I do sometimes see like leadership will say something or there'll be things on the walls. But you look around like, yeah, I don't actually think anyone's actually behaving that way. It's like an aspirational vibe about what they want to be, but they're not really doing it. So I think all those lenses are giving are right. And they're simple. Someone can look around and just see what you're saying. And then you make their own calculations of that. Some of the good. Some of that's a bit too. Casey (19:26) Yeah, absolutely. Absolutely. Scott Dunn (19:32) In the sense like either either change it for the better or You know what I mean? Like I don't want to be the person that's been there seven like this place is terrible What are you doing? What why have you been here 17 years hating it? I don't Casey (19:32) you Yeah, it's really important that we're honest with ourselves as much as our companies are honest with us, right? Like, what do I need from my job? What do I need from my career? And am I at a place that can support that? Scott Dunn (19:45) Good. Yes. Yeah, and and i'll serious in this case. I think there is some point where people I hear them And i'll just straight up. I don't think leadership has any intention to changing in the way you're describing Right. So in the end like so what would you like to do? And it's not even like it's a bad thing really. It's just like that's like It's a bit when you said that part some people are so passionate they forget like Yeah, and you're wrong like you could be wanting this coming to change in a way. It's not who they are or what they're about or you're Found by 80 people who are actually quite good with the way things The fact that you're so passionate doesn't mean you're right. It might just mean this is not a good fit. So don't stay here trying to change everything, which probably wouldn't work anyways if that's, you know, they're comfortable with what are. It's almost like in self-preservation, just say, I just need to exercise my agency and there's not a good guy. What's that song? There Ain't No Good Guy, There Ain't No Bad Guy. It's me and you and we just disagree. You move on to another and they'll be happier somewhere else is what I would think. So I think that's a good perspective. People can get past space about, you know, and agile and all that and then rail against something that's an immovable in some organizations. Casey (21:08) Yeah, being aware of the things that you can control, the things that you can't control, is really the crux of your own sanity, if you will. Scott Dunn (21:16) Yeah, it's a good way of saying it, Yeah, and you can control a lot of that. You can influence it. can influence it. Let me follow up on that because clearly, in my opinion, seems like you've that about bringing about change when you don't necessarily have authority. You can't dictate to some of these folks. What do you think is a key aspect of being successful around influence or people who... I get asked this all the time, how do we influence, how do we manage up, et cetera. What would you prefer as your thoughts on that about influencing others? Casey (21:50) Yeah, I actually listened to a podcast recently about leading without influence. one of the key comments, I guess I am also learning through podcasts, I guess. But one of the comments in the podcast was there are people who lead with a hammer, people who lead with influence. And I kind of love that because I haven't been a people leader in more than a decade. Scott Dunn (21:55) There you go. So they are some good. Casey (22:13) which means I don't have any authority, right? I lead all of my influence. All of my leadership is through influence. And the way that I approach that is I start with. It's a, it's a gooey word, but empathy, understanding the people that I'm talking to and working with and understanding what they need and what their challenges are, and then meeting them where they are. Right. The easiest way to gain influence with. Most people, is to build trust and to build trust, need to build relationships. And so I would say 90 % of my influence comes first from relationships. And probably the other 10 % comes from my ability to stand up and say, I was wrong when I did something wrong or when my perspective was incorrect and when I behaved outside my values, like just owning it up when I'm like, Scott Dunn (22:59) Wow. Casey (23:04) Yeah, I was having a bad day. I apologize. There's a lot of trust that comes from that kind of vulnerability. Scott Dunn (23:11) Yeah, which is not easy to do not easy to do But I've been in meetings where I like I know it like I don't play this year But I like things so in some ways people look at influence about how we phrase things or how we present but you're just saying like look happy build a real relationship Have some humility if you're willing to say we're wrong. So people know you'll also that when you're wrong or made of your core element of strength or something like that. think that's a real nice, everyone, if you think about that, that's not out of any of us to say, you know what, I'm going to try to be more honest and authentic and have some empathy and try to listen. Casey (23:45) Absolutely. It also helps to be able to connect the dots across different people and what they need and the strategy of whatever project you're working on so that you can connect the change to something that is it like what's in it for me, right? So what's in it for the people that you're talking to and being able to connect those things. So it's not just relationships and empathy, right? That's the soft stuff. It's that ability to really critically think about what it is you're driving change for. Scott Dunn (24:08) Mm-hmm. Casey (24:12) and connecting it to how each of these different stakeholders can benefit. Scott Dunn (24:18) Yeah, the part about connecting the dots and this is one thing if I'm ever in a meeting and I feel like I'm not getting it I actually will pause into my head. I'm thinking What is this person's concerns? And if I can't if I can't clear that I'd probably need to ask more questions but for any of us in those meetings just kind of go around through those stakeholders the people sitting around the desk or on the zoom and quick like in a sentence or two what what would be important to them? What are they? What's the win or what's the pain? But if you don't feel like you can articulate, then the good thing is you have to see that asking questions around that is never a problem because they're actually share because you're basically asking them about yourself. Tell me what's important to you. And they would like to share that. And it doesn't hurt to double check that. So I love what you're saying about connected dots. It won't be necessary that they're saying what you're listening and watching. I also watch what they react to. So something might jump out that would be outside of their say their role. but it's about people and there's an aspect that they really do care about how their people feel, not just the, this process is important in terms of our strategy and the technology we're using, but it might come out like, well, all their people would be really excited to put their hands on that new technology too. But they're not gonna say that because that sounds like that's a weak reason to be for a project, but you know it's important to them because they lead those people or that person. So I like what you're saying, connect the dots, think about those perspectives, because the empathy is gonna help them to connect in the dots, right? more is emotional than the logic of that stuff. So think that's great. Really, really great. On this, I believe you're remote, correct? Partially? Okay. ⁓ fully. Okay. Let's talk about that small. It hasn't come up in the last five years, but let's talk remote. So from your experience, it's always a big topic to me. I do care about this. I think we deal with a lot, every company, because some people at least that are remote, or certainly partial remote, Casey (25:45) I am. Fully. Scott Dunn (26:05) What's your thoughts on what to be worried about and what to make that successful? you're seeing more and more almost like these two sides of the aisle, maybe some aspect of demanding people come back. And yet you have a whole generation who can't buy a house. So I'm figuring out where's the balance of remote work. So yeah, your thoughts on remote work, how to make it successful scene. Casey (26:27) Yeah, I mean, I have two different ways I could approach this, right? I have the personal thing that what works for me part, right? But as somebody who is often having these conversations with people who are in various buckets of people who are, know, partially remote, fully remote, fully in the office, that kind of a thing, I find that what I think is less relevant every single day. I for sure feel I have a lot of privilege. Scott Dunn (26:33) Mm-hmm. Casey (26:50) being fully remote. Like that's really cool because it's good for me. I'm at a spot in my career where it makes sense. I'm good at building relationships in lots of different kinds of ways, including through, you know, zoom meetings and that type of thing. But I don't think that there's a right answer. I think that the each company and each team and each group of people need to find what works best for them. and make that happen. I see real benefit to being together, especially when you're early in your career or when you're doing something that you need a whiteboard. I mean, I'm pretty good at Mural. I'm pretty good at using the whiteboard in the Zoom meeting, but there's no replacement for standing at a whiteboard with a bunch of stickies and flowing out process. So I just don't... Scott Dunn (27:33) That's so true. You're so right. Casey (27:40) I don't know that there's a right answer. And I think that different size companies have different complexity of making that decision. And it sort of goes back to that comment we were making before. Like, if it isn't a good fit for you, find something that is. You know, I don't know. That's my thought. That's my thought. Scott Dunn (28:00) Yeah, true. Makes sense. For the folks that are managing or leading these remote work, are things that they do to make that go better in their context. Casey (28:12) Absolutely. are ways to, especially if you have hybrid, it even gets more complex, right? All virtual is the easiest way of virtual, right? Because then everybody's always virtual and you're always on Zoom and you're always on Slack and whatever. That's for sure the easiest way to manage teams that are virtual. When you have that hybrid space, you've got that opportunity to be in a conference room or in a huddle group or in the cafeteria. and on Zoom meetings, and it gets kind of funky, right? Because sometimes you can't hear, or you have those water cooler conversations. The key really is to have what I found is a good working agreement, right? Like, what types of communication are we going to have? How are we going to do that? What happens when we had a really great conversation in the break room? How do we communicate that to the rest of the team who wasn't there? And really just sort of build team trust through a good quality executed working agreement. And sometimes that takes a little bit more effort from the leader or even from every individual, right? But that's part of that culture, right? Scott Dunn (29:16) Right. I think the folks you make me think that's personally in a meeting and it's good that I try to get the groups together in these different locations as they're talking. I can't tell. I talking. I don't know these. I don't know them all that well. So I can't I can't tell by voice yet. If these are different groups are working with each other. The thing is, look, that person's kind of off camera or either they're on camera. They're so far back. Is that is their mouth moving? Is there a delay? I can't tell. So that sets the connection. I'm surprised for me as a more of a relator, how much it becomes a problem like nothing beats in person. So at least get that regularly. get in person. There was another client that saying that very same thing. Like they love it when we all get back together. And so they kind of have their cadence of pulling the whole group better. Could be like you're off site, could be all hands could be, but I think those opportunities to keep connection. I do like remote. I do think you have a good point about depending on the maturity of the career. Some people just know like I know I got to take care of these biopsy that they've noticed other XYZ. So they do too. So if they're new in their career, they may not even catch that I should be probably working. what is this at home on the zoom and in their PJs or something like that. I think it's a good point. Look at those and also the work. The fact that you would take that to the team and say, what do you all think is very empowering. You have an open conversation around what they all think and definitely there's a assumptions that people are making about what it should be, et cetera, but they those explicit and they kind of carry that around with them a little. Right. So that's a yeah, really nice nugget on that. That's everyone for sure. So last thing I'm to add a little bit on the back on leading change. So in this case, it could be remote, could be these other projects that we'll try to adapt. I think you'd say this earlier about there's no company that's not going through this crazy time of change right now. When it comes to change, have you seen something that's helpful, especially if it's a more significant change, you gave some good fundamentals around influence and trust and relationship, empathy, et cetera. Are there other aspects on how that change is rolled out or a process change or the groups that are leading the change that you've seen be like more systemically just successful aside that people might change, but the way we handle change is done this way. That you think there's a tip or two out there that would help out. They're trying to kick off, you know, a new way of working. We're trying to refresh remote policies or how they work, Because a lot of people in the middle of change. Have you seen overarching themes about how this lead that you found have been more successful? Casey (31:57) Yeah, think, gosh, it's the hardest thing, right? Like figuring out a way to roll out change across teams is the most challenging thing that I've ever done. And I've been doing it for a long time. And I'm always learning new ways and new ways not to do things and all that jazz, right? I have this little nugget that I got from a mentor. Scott Dunn (32:11) Hahaha, yeah. Casey (32:24) 20 years ago almost, and he's a motorcycle rider. And when you ride a motorcycle, the thing that you do to go on a corner is to turn your head, right? Turn your head to get to where you're going. And the non-motorcycle sort of connection to that is the what's my plan. And so really understanding what the plan is so that you can very clearly articulate what it is you're doing at each phase of the change. If you're prepping people for change, what's the plan? If you're starting to design a project, what's the plan? And just get really clear with where you're going, what the expectations are, what each individual person's role is, and be explicit about it because we're all dealing with a lot of things coming at us all the time. And if you're leading with kindness and you're saying, okay, your part of this is to simply accept the change. That's not condescending, that's empowering. That tells that person that like, this decision has been made, I gotta get myself there, and this person's here to help me get there. And so just being really clear about it, that's the biggest thing for me that I've seen that is successful. It's hard to do though, because that's a lot of people and a lot of Scott Dunn (33:36) Yeah. Well, yes, that's why it makes it so surprising. Number of times a company has to bring in outside help to get the change because it's not a capability or muscle they really have about how to change ourselves. Right. We execute against what we build or do here really well for help. But but that idea of getting outside the box and thinking different how we can improve, like you said, poke holes and so that's why I like it that there's someone When a company sees someone with your skill set and the way that you're wired and leverages it to say like, we kind of informally have this person like really helping things about because it's commonly not a muscle that they really have. Sometimes they have the awareness they don't, but sometimes they don't the long, really large change initiatives that take a long time and either never really get off the ground or never really where they should have gone or before they kind of just either die on the vine or we just call it, you know, just call it good. They don't draw in. It gets a group above everyone trying to lay change on top of folks instead of incorporate everyone into change and then go through it together. Learning together with someone like you that can connect the dots, connect with people, can bring that about. And think in a way it's really powerful and effective. Yeah, I was going to tease you. don't know if you have anything on that. But you mentioned books, you mentioned podcasts. Do have any favorites that you just would throw out? Classic go to book, current read, current podcast. Casey (35:01) My favorite all time book is a book called Wolf Pack by Abby Wambach. She's a soccer player, she's fantastic, and it's a book about leadership. It's like 70 pages long. It has a set of like four rules. And yeah, it's written from a like, you know, girl power, woman empowerment, leadership empowerment kind of thing, but it's universally adaptable to life, to it doesn't matter what your gender might be. what your job might be, Wolfpack. I can't recommend it enough. And then most recently, I read the let them theory and it's life changing. It's not a new topic, right? It's not a new concept. Of course you should control the things that you should stress about the things that you can control and let the things you can't control go, right? There's lots of different places that that comes up, but Mel Robbins just did a great job, like putting it into stories that you could like directly apply it to your life, or at least for me anyway. And I find myself quoting that book to myself pretty regularly. Yeah. Scott Dunn (36:03) That's a good sign. That's a really good sign. I find myself too. That's I literally will go through something. I start to realize like you've mentioned this book or this thing like three times now in the last few weeks. Like, OK, that's obviously significant. You didn't miss a time. you make another really good point. I really say like at the meta level in some ways, when it impacts you personally and you connect to it personally, it's going to be helpful and relevant in the work you do because you're going to be sharing the expression of who you are. And I say that because some people will go like, here's this top leadership book this year. I'm to read this well-known. And sometimes I'll struggle to just like really pick the book. Even if it is good content, I don't connect to it. I'm not sharing with others. It's not part. It doesn't become a home and gets spread. So I love what you're saying. Casey (36:48) completely agree with that. read, I spent a lot of time last year reading a book called Mind Your Mindset. I don't know if you've read that one. But in theory, it's great. But it's so business focused that like I didn't personally relate to it. And so I had to go find some other book that was less business structured to, to like, bolster that topic. All the words were the same. It's just the storyline really, really changes it for me. So telling stories, right, is the most important thing of how we connect. to the world. Scott Dunn (37:20) Yes, yes, yes. And I believe in that. That's how we're just wired. brains are wired. Story really sticks. And you're making me think like, yeah, those books I recommend the most are more not have a lot of stories, even if it's less directly tied to the work I do. Maybe it's not even technology. It's not even maybe it's not even around business, but it's got stories they do and stick and connect. I love that. So I'll check that out. I have not read Will Peck. I think I've seen it, but now that I know it, pages I'm also enticed to on that. I can get through it. Casey (37:52) It's one hour of your time max. Scott Dunn (37:53) us. If I can't do that over breakfast, then what's going on? Awesome. I appreciate that. This has been great. I think there's a lot of nuggets for folks that are listening. I wouldn't be surprised, by the way, that this could get chopped up into part one, part two. I think we like them. But this is great because I think it's a great part one, part two, given how we kind of split the conversations. And I love the personal aspect on that as well. So thank Thank Casey for the time. It's been wonderful. think I really look forward to people's feedback on this and a lot of takeaways, a lot of that can be, they can try out some of these things very next week in terms of how they show up and who they are and what they're about. There's just a whole lot of good pieces of this that I think are readily possible for so many people. So I really, really appreciate that too as well. I'm on automatic sites. love them. The Builder Backs, they can do something right away with that. And you gave them a lot of Thank you for that. Thank you for your time. I know you have a lot on your plate. for us, but you appreciate it. Hope to see you soon. Thanks Casey. Casey (38:54) Yeah, thanks for having me. Thank you. Scott Dunn (38:57) Woo!

What does it look like to lead a 300-person software org inside a 1,000-person company—and still stay focused on people first? Brendan Wovchko shares what he's learned about leadership, agility, and building a culture that actually works. Overview Brendan Wovchko, CTO at Ramsey Solutions, joins Scott Dunn to talk about what it really takes to lead Agile teams inside a large, fast-moving organization. From developing leadership habits to navigating team dynamics and staying grounded in purpose, this conversation is full of thoughtful takeaways for anyone working at the intersection of people, process, and product. References and resources mentioned in the show: Brendan Wovchko Ramsey Solutions #80: From Struggling to Success: Reviving Agile Teams with Mike Cohn #143: What Still Makes Teams Work (and Win) with Jim York What Is a High-Performing Agile Team? by Mike Cohn Four Quick Ways to Gain or Assess Team Consensus by Mike Cohn Elements of Agile Assessment Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Brendan Wovchko is the CTO of Ramsey Solutions and a lifelong student of what it takes to build great software, lead great people, and scale both with purpose. With roots in engineering and startups, he brings decades of hands-on experience in product, leadership, and agile culture—plus a knack for turning big ideas into results that matter.

How do you grow a remote-first team from 30 to over 100 while still being voted a "great place to work"? Ginger Boyll says it’s part Agile mindset, part trust, and part Dungeons & Dragons—and we’re not arguing. Overview In this episode of the Agile Mentors Podcast, guest host Scott Dunn sits down with Ginger Boyll, Director of Client Experience at Stable Kernel, for a refreshingly candid conversation about leadership, collaboration, and creating cultures where people thrive, even remotely. From the magic of psychological safety to timesheet woes, CliftonStrengths charts, and the underrated art of letting someone else just do the thing, this episode is a masterclass in how empathy and agility show up far beyond process. References and resources mentioned in the show: Ginger Boyll Stable Kernel The Fearless Organization by Amy Edmonson Range by David Epstein Built to Last by Jim Collins Unreasonable Hospitality by Will Guidara The Tipping Point by Malcolm Gladwell The Coaching Habit by Michael Bungay Stanier Paul Graham’s Maker’s Schedule, Manager’s Schedule 25 Questions That Will Help You Know Your Teammates Better Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Ginger Boyll is the Director of Client Experience at Stable Kernel. She is a natural problem-solver with a passion for people, bringing deep experience in Agile delivery, tech strategy, and cross-functional collaboration to every project she touches.

Real Agile forecasting runs on math, not magic. Brian and Lance dive into Monte Carlo methods, DORA metrics, and how AI is shifting the future of project management. All with a human-first approach that builds better teams, not bigger spreadsheets. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Lance Dacy unpack why Agile teams need to rethink how they forecast work—and why math, not magic, is the real secret. From the roots of Taylorism to today's Monte Carlo simulations, they explore how to navigate uncertainty with data-driven tools like DORA metrics, flow metrics, and probability theory, while keeping the heart of Agile leadership focused on trust, transparency, and better decision-making. References and resources mentioned in the show: Lance Dacy Free Chapters of Agile Estimating and Planning by Mike Cohn Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. 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.

What does soccer, soda, and software have in common? According to Jim York—everything. In this episode, he and Brian Milner break down what great teamwork really means, why shared goals matter more than job titles, and how understanding your team’s unique contribution can unlock better flow and results. Overview In this episode of the Agile Mentors Podcast, Brian Milner sits down with veteran Agile coach and trainer Jim York for a deep dive into what makes real teamwork tick. They unpack what separates a group of coworkers from a high-functioning team, explore the role of shared goals in driving motivation, and walk through value stream thinking using vivid analogies from sports and soda cans alike. Whether you're part of a Scrum team or leading cross-functional initiatives, this episode will help you think differently about collaboration, flow, and how teams can work better together. References and resources mentioned in the show: Jim York Jim's Blog Jim's Video Library Lean Thinking: Banish Waste and Create Wealth in Your Corporation by James Womack & Daniel Jones Liftoff Vision: Launching Agile Teams and Projects by Diana Larsen & Ainsley Nies GoatBot Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Jim York is a business owner helping teams discover how to delight their customers. He uses systems thinking, agile and lean to co-create resilient, learning teams. As a coach, he works with his clients to help them grow in directions that matter to them to achieve their goals. Jim is a Certified Agile Coach®️, holding both the Certified Enterprise Coach and Certified Team Coach credentials; Certified Scrum Trainer®️; Agile Fluency®️ facilitator; LeSS Practitioner. In 2007, Jim co-foundered FoxHedge Ltd with his wife, Melissa York. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We're back here for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the very distinguished gentleman, Mr. Jim York with us. Welcome in, Jim. Jim York (00:12) Well, thank you, Brian. Glad to be here. Brian Milner (00:15) Very excited to have Jim with us. We were just chatting before and Jim and I met years ago at a conference. We got introduced by a mutual friend, Mr. Kurt Peterson, who has been on the show. He came on a little bit earlier to talk about Kanban. And just for those people who aren't familiar with Jim, Jim is a co-founder of a company called Fox Hedge. And he has been an Agile coach, a Scrum trainer for quite a while now and I give him the title Luminary, kind of scrum luminary, thought leader, been around doing this for a while. I hope that doesn't sound insulting in any way, Jim, to call you that. Jim York (00:55) Nope, nope, just trying to shine my light and help others shine theirs. So that's what a coach does. So. Brian Milner (01:00) Awesome, Cool, well, we wanted to have Jim on because we had this topic that it's kind of a broad topic, but it's, I think, actually crucial to today's world. And that's just the broad topic of teamwork itself. So I'll start this way, Jim. I want to get your opinion. In today's world, with the changing kind of landscape with AI and everything else that we see that's kind of influencing how we work, has teamwork had its day? Is it time now for something new or is teamwork still the best way to build things? Jim York (01:34) Yeah, well, teams are universal. I think once you get more than one single individual and you get some task that requires more than what one person can do, it's inevitable. We've to work together. And so I don't see that going away. It might change a bit. But in many ways, think the things that we face today are, in many ways, things that we faced before. They might be showing up in a different way, but I think there's some universality. universality to teamwork. Brian Milner (02:03) Yeah, I agree. And so what do we mean by teamwork? Why don't we define that a little bit for everyone? Jim York (02:09) Yeah, I guess we have to step back and start looking at what's a team. If we talk about teamwork, there's this whole expression, teamwork makes the teamwork. So what's a team? And the classic definition of a team is it's a group of individuals working on a shared goal. And so it's kind of like built into the definition, we're working on a shared goal. So teamwork is that combined action. Brian Milner (02:13) Yeah. Yeah. Jim York (02:32) And so that's kind of the general concept. It's, you know, some of the parts, you know, is greater than the whole. And so it's taking that mix of experiences, knowledge, skills, and bringing them together and having that dynamic, that energy, and kind of focusing it in the same direction. You know, that's really what teamwork is about. Brian Milner (02:55) Yeah, it's good to clarify it, because I think the word team gets quite widely used in today's world. you'll hear people describe that, hey, that's my sales team. When you look at it and how they actually work together, there's not really a lot of teaming actually happening. It's just a group of individuals who have the same job and that. that format. I do think you're right. It's important to understand the difference between that kind of a team and what we're talking about here as a team. Jim York (03:25) Yeah, there are different kinds of teams and people in a sales team, even if they're not working with each other, the fact that they have a shared goal does create some sense of team. And there's different teamwork where everybody's providing kind of their unique thing. And then you have, I think like a team in a rowing, when you have like four people in a rowboat. they might have somebody who's steering the boat, you know, but they have the four people holding onto the oars and, you know, they're working at a similar cadence. You can say to a certain degree they're individuals. I don't know if they're fungible. I don't think they're necessarily fungible, but they're working together to accomplish that shared goal. know, the people in rowing, that's different from people on like a soccer team. You know, on a soccer team, you're... You got the whole pitch, you know, you're all over the place and the ball's moving around and there's this kind of coming together and going apart of various team members interacting at different places and at different times throughout the game. You're kind of acting dynamically to where the ball is and where the opponents are and where they are on the field. And so there's this creativity that occurs there that's kind of a different kind of creativity than you might see in a rowing type of competition. Brian Milner (04:18) Yeah. Jim York (04:42) But yeah, I think there are different kinds of teams, but I think that universal theme of being a group of individuals that are having that shared goal, I think that's the thing that's in common. It's not the nature of the work that some people might call agile versus predictive or planned work. mean, the concept of a team is more universal thing. Brian Milner (04:43) Yeah. Yeah. I like the example of kind of the crew, right? Of rowing and stuff. I think that's a good picture because you're right. I mean, it's very subtle, but there's a lot of combined movement. And if one person is off a little bit, it really affects how others are working. I've used the example sometimes in my classes as a contrast to think about like a golf team. You know, like the idea that you have the group of people who, again, I say this in classes. So anyone listening to this who's a golf expert, it really loves golf. Please, email in and tell me if I'm wrong about this. But this is what I say in my classes. You know, if you're on a golf team, it's a group of individuals who are each shooting their own 18 holes. But then at the end of the round, you just total up the score. And if you have the lowest lower score than another team, then you win, right? But it's, When I'm shooting my 18 holes, I'm not necessarily aware of what everyone else on my team has done or what they're doing at the same time. We don't play off each other, right? I don't take the first shot and then they take the second shot. It's all on me to do my best. And then hopefully everyone else has done their best and we just kind of see how it works out at the very last second. Yeah. Jim York (06:17) Yeah, so teams are different. know, teams are definitely different. And I think it's that idea of the shared goal that is the thing that kind of the glue that holds the team together and that shared goal that can be at various levels. I mean, it can be at this grand big picture level. You know, sometimes what's referred to as a product vision, it can be at a more discrete team level. Sometimes that's referred to as, you know, our our unique contribution to the product division. So that would be like our team mission. And then there's maybe, you know, a specific task. And so, you know, we might be working on a specific, very small, discrete task. And, you know, there's a potentially a group of people working on that thing. And, and, and those people have that shared goal of moving that task, you know, through a process to a completion state. And so there's, there's some variability here in the different kind of levels and Hopefully, there's some alignment between those different levels when you're talking about a team. Brian Milner (07:14) All right, so there's some different kinds of teams and it kind of is wide ranging in how we would describe it. There's different configurations, but we have a single purpose. We're working together towards a single purpose. That's kind of our unifying factor there. So then what makes teams work? What's the glue other than our purpose? How do we actually... Combine efforts, how do we play off each other's strengths? How does that happen? Jim York (07:47) Yeah, well, it depends, right? I mean, that's the classic consultant's answer. It depends. How do we play off of each other? If you're in an environment where you've got a known solution to a known problem and you're just executing steps in a plan, those dynamics are pretty well understood. People in that process can be trained to do different types of activities. They can gain experience in that. Brian Milner (07:50) Yeah. Jim York (08:08) That's a fairly predictable kind of process, but then there are others where it's emergent. And so we have to kind of figure it out on the fly as we go. And even those environments where it seems that we've got a pre-existing solution, there is a very clear variable there, and that's people. People show up different every day. I might have had a poor night's sleep, and people might think, well, Jim's normally fairly easy to work with, but wow, today he's... got a short temper or whatever it might be. And so we have to of figure out on the fly how we adapt to those variables. anything that has to do with people, you're going to have some variability. think stepping back, Brian, I think one of the things that is important to kind of understand or get a sense of what part of the system that we want to understand when we're talking about a team and they are dynamics, they actually are fitting within some sort of product ecosystem. And so where are the boundaries of what we mean by our shared purpose, our shared vision within that ecosystem? There's a classic book called Lean Thinking by James and Womack. And there's a really interesting example, simple diagram in the book of a value stream. And it's a value stream of a cola can. And it's kind of fascinating. You kind of see this very simple value stream in there and it starts with aluminum being, well, not the aluminum, but the bauxite actually being mined. And it goes through a reduction mill and then to a smelter. And then it goes through some hot rolling and cold rolling process. And so finally you get basically rolls of sheet aluminum that go to a can maker and the can maker is cutting the cans that are then formed into the cola can. You know, and that can maker is actually the middle of the value stream because all the things I've described so far are upstream. Downstream of the can maker, once they've made the cans, the cans go to a can warehouse somewhere and they sit there until a bottler says, hey, we need some cans because somebody's ordered some cola. And so, you know, the cans make their journey to the bottler and they get filled and then they get... Brian Milner (10:01) Hmm. Jim York (10:17) go to a bottling warehouse and of course there's transportation, there's trucks carrying these empty cans from the can maker to the bottler and then the filled cans from the bottler to the bottler warehouse and then ultimately they go to some wholesale operation and then to a retail store and then you and I perhaps will go into the store and buy a six pack of cola and we go home and we drink the cola. And so you see this very simple kind of journey, this little value stream. from the perspective of the can maker. And so, first time I encountered that value stream, I'm sitting there looking at the can maker and I'm asking myself the classic question that I ask my clients. One of the first questions I ask is, who's your customer? And so for the can maker, it can be very easy to look at that and go, well, it's the bottler because the bottler is the one who places the orders for the cans. So clearly the customer for the can maker is the bottler. Of course from a lean perspective we look further down the stream We were looking at the end of the stream to see you know, what's what's it all for? What's it all for? And if you look at the diagram you get to you know finally to the end of the stream and there's the home where the person's potentially sitting on their couch and enjoying you know that that cola and so you know if you think about all the different steps along the value stream from the mining to the to the smelting to the bottler and Brian Milner (11:17) Ha Yeah. Jim York (11:38) the can maker themselves, the retail store that's selling the cola. The thing that you would ask them that would be the glue that would hold them together for this would be what Diana Larsson and Ainsley Nees call in their lift off book, the product vision. And so the product vision is really kind of what's it all for? And the cool thing about a product vision is it's very concise, it's very succinct and everybody can hold it in their heads very easily because of that. It's typically one sentence. And so I'm going to speculate this because I'm not a, I'm not part of this value stream where Cola makes its journey to people in their homes. But I'm guessing the product vision for all of these various people along the value stream boils down to something along the lines of our customers enjoy a convenient, refreshing beverage. And so the cool thing about that simple statement is that Brian Milner (12:23) Mm-hmm. Jim York (12:28) If you were to go to the mine and ask a miner and say, some of this bauxite that you're mining, in the context of this soda, what's it all for? Now, they're probably mining bauxite for a variety of different customers and a variety of different products. But in the context of this particular value stream, they could look down to the end of the stream and say, it's all about that person sitting on their couch at the end of a long day who simply wants to have a convenient, refreshing beverage. And so that's what you know, this particular product vision is. And so that kind of calls into view a couple of things. One is context is important. So when we're talking about the product, we have to be very specific about what it is that we mean, who is that customer at the end of the stream, and what is the experience that we want them to have. And so this product vision is, as I said, very simple. our customers experience a convenient, refreshing beverage. Now, that makes it simple in terms of this particular value stream, but it also makes us aware that it's very complex for the miners because they've got to deal with competing interests from a whole lot of different customers. And so if they've got limited capacity, they may be trying to figure out, which customer do we satisfy? And so the usefulness of the product vision is being able to go to that mining company and say, do you find value in, do you want to support this activity of creating this experience for this customer with convenient refreshing beverage? And if they buy into that, if they agree with that, that's your leverage, that's your argument. why you should deliver against this value stream versus some other value stream. Now, you don't always win that argument, which is really what life is about, is we're always dealing with trade-offs and we're dealing with different options or opportunities. And so I think that's one aspect of this. But when we talk about the team in the context of a product vision, The team is huge. The team is absolutely huge because it's not just a can maker and the can maker team. It's also the bottler and the bottler team. It's maybe the truckers union that's providing transportation between these different things. the retail store. It's the retail warehouse. All of them potentially have their own concept of team. And in order to create value, it's not just what you do and provide to your next partner on the value stream. You have to really pay attention to the entire value stream because ultimately anything that doesn't come together in the right way at the right in the right place right time It puts it all at risk It puts it all at risk. So I think it's important that we kind of understand the product vision this highest level glue that holds us together and then at a more discrete level look at your team, for example the can maker and What is their unique contribution? In Liftoff, Diana Larsson and Ainsley Niece call this the team mission. And so what is the team's unique contribution to the product vision? And so for the can maker, it's also fairly simple. It's like, we make the cans. And they could flavor that a bit with, they use the latest technology and they use environment. sensitive manufacturing processes, know, they source things using sustainable, you know, approaches and the like. at the team mission level, we're getting a little bit more discreet in terms of what it is that that team is contributing to the greater whole. So think part of this is just kind of stepping back and thinking about what it means to be a team. Brian Milner (16:12) Hmm. Jim York (16:24) You know, are we talking about we're a team that's the collection of all of these things? At times that might be a useful way of thinking about it. At other times we need to kind put our heads down and focus on what our unique contribution is and make sure that we're doing the appropriate job there. Brian Milner (16:24) Hmm. Yeah, this is fascinating because so what I'm hearing is that really we have to expand our thinking a little bit about teams because teaming teams are, know, in one sense, the small group that you're working with on a on a regular basis, but it's there's a larger team concept as well of the entire value stream from end to end. All the people who are contributing, they all are are working towards that ultimate goal of, in your example, someone having a refreshing beverage at the end of their long, day at work? And how often do we actually realize that or look at that? Are the miners really even aware of the fact that they're contributing to that sort of a larger team goal? I think that's a great question. Jim York (17:21) Yeah, that's an excellent point. And what are the implications of either that awareness or lack of awareness? And I think this kind of comes to play when we think about what motivates teams. If all I know is that I'm mining bauxite, that might work for some folks. That's enough motivation. Sometimes people say my paycheck is enough motivation. Brian Milner (17:44) Ha ha. Jim York (17:45) But if you really understand what it's all about, that maybe ties into a bit of self-worth, that I'm a contributing member of society. It could also help you make the right decisions and perform the right actions if you know ultimately what this is gonna lead to. And sometimes that's a calculation that's done in terms of the quality. of the work that you're doing or the output that you're creating. For certain applications, the quality might have certain characteristics where the quality has turned up very, very high in some areas or maybe it's lower in other areas because it's good enough. And if you overbuild quality, you might be introducing some waste because it's not. It's not necessary for the job at hand. In other places, if you deliver below quality, you introduce some risk that the product is not going to be, or the ultimate customer experience is not going to be what it is. I don't know about you, but I've occasionally gotten one of these plastic soda bottles where they've made the plastic so thin for the soda bottle that the liquid is actually needed inside the bottle to maintain the structural integrity of the bottle. Brian Milner (18:54) Yeah. Jim York (18:54) And if I were that customer sitting on the couch at the end of a long hot day, let's imagine it's a white cloth couch and I'm drinking orange soda and I reach over to pick up the soda and my hand, you know, grasping around the soda bottle, all of sudden the soda bottle just collapses in my hand and orange soda goes all over me and the couch and everything else. mean, that's, you know, there's some quality characteristics, some specifications around that. Brian Milner (19:02) Ha ha ha. Jim York (19:18) container that that plastic container that has to integrate well into the rest of the process. It has to work with the bottler and it has to work with the consumer when they're actually using it. So it's understanding the whole can certainly help teams feel a sense of purpose and also can guide that decision making in those actions around it. Brian Milner (19:30) Yeah. Yeah, I think that's an important thing to keep in mind and remember because, you you mentioned, you know, some people would say paycheck is a motivator. And I, you know, I, I kind of subscribe to the Dan Pink kind of motivation philosophy that, know, that, can only do it so far that it is a motivator, but it is a motivator only to a certain point. Beyond that point, we need more. We need more to motivate what we're going to do. Cause you know, there's a million things out there that can give me a paycheck. I could work in a lot of different places, but I've chosen to do what I do for a reason. There's something that fulfills me from doing that, or I prefer it in some way to what my other options might be. I know I've heard people say this in classes before, the idea of how do you have a vision for somebody who builds clothes hangers? We have this talk about vision, this grand design. Big purpose. Well, how do you do that for someone who has clothes hangers? You know, like I get that, you know, there's not everything, every product in the world has, you know, a save the world kind of vision, right? But I think you can, in your example of kind of the mining thing, I think is a good example of this because you can connect it to that ultimate value. And when you connect to that ultimate value, it doesn't that motivate people more to think, hey, I'm helping someone who's had a hard day. I know what that's like. Have a hard day, sit down on your couch and you just want to relax a little bit. Yeah, I want to help that person. Like that, is something that that'll gets me out of bed, you know? Jim York (21:06) Mm-hmm. Yeah, and I think that does require you to think beyond what we often think of as being the team. Because to make it all come together and result in that ultimate product vision, that, you know, the person having the convenient refreshing beverage, in my example, you know, all of those different parts have to come together. And any one of them, if it doesn't happen, you know, that we don't have that value that's realized at the end of the value stream. And so having that connection to what it's really ultimately about is critically important. And understanding where you fit into that and what your value add work is, I think is critically important. And so we talked about like at high level product vision, we talked about this unique contribution of your team like the can maker, and so our team mission, we make the cans. And then we get to the practicalities of the task that's in flight, the work that we're doing right now. And I think that's a critical piece of this puzzle. What is it that's the thing that's being acted upon right now? The work in process or the work in flight. And depending on what the nature of that is, I think that drives a lot of... decisions and one of them is around, you know, who do we need? So who are the actual people, you know, that have the right skills, knowledge, experience in order to do that work? And also it informs our process and so, know, again, that process could be something where it's a known process and we're just, you know, turning the crank or it might be something where we're having to figure it out on the fly. Regardless of the nature of the work, there's going to be a workflow. When we're trying to get something done, the work is going to be flowing through some sort of process. And it's that flow that really intrigues me. we want to look at the flow, especially if speed matters. And why would speed matter? Sometimes speed matters because customers want what we are building yesterday. So they want it as soon as possible. So time to value is often what's considered there. If we're something new that hasn't existed before, sometimes we're also building quickly so we can get it in front of someone to get their reaction to see whether it's fit for purpose. So we might think of that as being time to feedback. But the flow itself is there's the workflow. And so work, the nature of it is a piece of work is something that maybe an individual can go work on. Other times there's a piece of work that requires more than one person to work on. So there's an element of collaboration with that. Even when it's an individual that can work on a piece of work, usually they've received something from somebody that allows them to start that piece of work. And when they're done with that piece of work, they're passing what they've done along to somebody else and that other person is picking up. So even if... there's an ability to work on a discrete task by yourself, there's still an interaction often on the front end of that and the back end of that. So work is still flowing and we have to figure out how to collaborate in such a way that the work that is not being held up in some queue somewhere where we're getting some bottlenecks and that they're constraints. so figuring out how do you enable the work to flow and how do you enable the people to flow? Years ago, I had an opportunity to coach soccer and on my team, I taught them, in addition to like skills, I taught them three concepts. And so the first one was, everybody on the team should know where the ball is. And so it seems pretty obvious, you should know where the ball is. But if you look at this from a team building software perspective, does everybody know where the ball is? You know, what is the work that's in flight and what's the current state of that? I mean, we use information radiators to try to help people understand where the ball is, but often I don't think we use them as effectively as we might. So I'm always challenging teams to figure out, you know, how do you use your communication systems, your information radiators to enable everyone in your ecosystem to understand, you know, what's the work in flight and what is its current state? And why do you need to know that? Brian Milner (24:55) Hmm. Yeah. Jim York (25:24) Well, if you know where the ball is, you can get a sense of what are the things that are in the way of that ball moving forward. So my second rule for the team was know where your obstacles are. And so in a soccer game, you're seeing your opponents. And so you might have a great plan on how you're going to advance the ball from where it is currently down the field towards the goal. But little problem with that. You've got people on the other team trying to keep you from getting there. So you're having to react real time in the moment to those obstacles. And so in addition to everybody on the team knowing where the ball is, everyone on the team needs to know where the obstacles are. And so when you have that information, and again, for a team building software, this is the kind of thing that should be readily available in some sort of information radiator, real time ability to see where the ball is and to see what's in the way. Why is that important? Well, if you know where the ball is and you know where the obstacles are, you can position yourself as a team member to be what I called the help. And so by the help, that's the one or two people on your soccer team that if you're the one with the ball, you know you can pass to them easily. You know, that they are constantly moving around and positioning themselves to be in the place where it's possible for you to get the ball to them. So who are those two people? Well, it changes depending on where the ball is. And so what the team has to do is kind of get a mental mob. Brian Milner (26:41) Ha ha. Jim York (26:47) in their heads of the actual position of people on the field and get a sense of if the ball's here and the obstacles are here, then I should put myself here. Now, it isn't for all the team members to position themselves to be the help because that would be crazy. Just as we see on Agile teams, when somebody picks up a task, the whole team typically doesn't swarm on that task. It would be too many people on the task. Brian Milner (27:06) haha Jim York (27:16) So who shows up to work the task? The right number of people with the right skills and knowledge. So how do they know to come? It's because the work is made visible. And so they come because they see that they're needed. How fast do they come? Ideally, they're there instantly. Now, why might they not be there instantly? Because they might be working on some other tasks. And so if this were to happen in soccer game, you would see the other opponent, you know, they would be... basically scoring goals against you right and left because when you try to pass the ball, you wouldn't have somebody there to receive the ball. So knowing where your help is, if you've got the ball and passing it to that person helps you continue the flow down towards the goal. So if you're not the person who has the ball and you're not one of those two people that are the help currently, What you're doing as another team member is you are. orienting yourself on the field so that you will be the help when it's needed. And so there's this constant movement of people down the field. And where this really brings it home, I'll use this example, and I'm coaching agile teams, is they'll talk about how all their work and stuff, and I'll use the example of the soccer game and the one ball, and they say, now let's imagine you put two balls in flight. Brian Milner (28:16) Hmm, that makes sense, yeah. Jim York (28:36) Can you optimally move those balls down the field towards your opponent's goal? And typically, there is a limit, right? How many balls can you put on the field? Two, three, 15? It's like, yeah, it really drives home the point of limiting the work in process. the teamwork is made more effective and efficient if we have some sense of where the work is, what is the nature of it so that people can come and go, I call this people flow. so we're looking at things like the, well, out of... Brian Milner (29:05) Yeah. Jim York (29:09) out of the concept of open space, the law of mobility. It's like within our organizations, within our teams, can we have people flow to where the work is needed and also have people flow away from the work when they're not needed? And so enabling that autonomy of the individual to be able to go where they need to go in order to optimize the flow is a... Brian Milner (29:13) Yeah, yeah. Jim York (29:34) is a key organizational design problem. Brian Milner (29:37) Yeah, yeah, this is fascinating stuff. mean, I love the analogy with the soccer teams and that I mean, I, that makes sense to me. I love kind of where you're going with this. If people are hearing this and thinking, well, I like to hear more about this stuff. We're going to put links in our show notes back to Jim's site on this because he's got a lot of blog posts. They're kind of around the same theme on this. And we'll link to those specific blog posts for you so that you can find them. But Jim, I want to be respectful of your time and our listeners' time. So thank you so much for taking your time out to share this with us. Jim York (30:08) Well, I've been very pleased to join you, Brian. Thank you for the opportunity. Brian Milner (30:13) Absolutely.

If your team keeps revisiting the same issues over and over again, Groundhog Day-style, this episode is for you. Leadership coach Marsha Acker shares why it happens, how to recognize hidden conversational patterns, and what to do when you feel stuck. Overview In this episode, Brian Milner sits down with executive team coach and author Marsha Acker to unpack one of the most frustrating challenges teams face: circular conversations that never seem to resolve. You know the ones; same issue, different day. Marsha introduces a practical framework, structural dynamics, to help leaders and Scrum Masters decode what’s actually happening beneath the surface of their team’s conversations. From identifying communication patterns to creating space for dissent and inquiry, they explore how to break out of those conversational loops, build psychological safety, and foster real change. Whether you're leading meetings or just stuck in too many of them, this episode will help you shift the dynamic for good. References and resources mentioned in the show: Marsha Acker The Art and Science of Facilitation by Marsha Acker Build Your Model for Leading Change: A guided workbook to catalyze clarity and confidence in leading yourself and others by Marsha Acker #137: Stop Wasting Time with Guests Kate Megaw #94: Connecting Teams and Leadership with Anthony Coppedge Retrospectives Repair Guide Better Retrospectives Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Marsha Acker is an executive coach, author, and the founder of TeamCatapult, where she helps leadership teams break out of communication ruts and lead real, lasting change. With two decades of experience guiding everyone from startups to Fortune 500s, Marsha specializes in transforming how teams talk, decide, and grow—one conversation at a time. Auto-generated Transcript: Brian Milner (00:00) Welcome back, Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have the honor of having Ms. Marcia Acker with us. So welcome in, Marcia. Marsha Acker (00:12) Hi Brian, it's good to be here. Brian Milner (00:14) Very very happy to have Marcia with us. Marcia is the CEO of a group called Team Catapult and she is a team coach. She does a lot of work with teams and leaders. She's an author. She's a speaker and we wanted to have her come on because of a book that she has out recently called Build Your Model for Leading Change. She also has another book called The Art and Science of Facilitation, which I'm sure is really appealing to a lot of people here as well. You know, as Scrum Masters, if you're a Scrum Master out there, we do a lot of facilitating. So that's probably a really interesting pickup for you also. But we wanted to have Marsha on because we wanted to talk about an issue that I hear a lot about in classes. This is something that I hear a lot of questions around, and it can be a really big source of issues when you think about working together in close, tight units as a team. And that's how teams communicate. kind of the issues and problems that we have with communication amongst teams. So, you know, when we're talking about this, we're talking about teams not listening to each other, not understanding each other, misunderstanding someone's motives, something like that. And one of the things I know that I've seen a lot, I've encountered this a lot, and this is one of the things that I know you talk about quite a bit in your book, is this kind of loop that we get in a little bit, right? We have these conversations where... It just feels like we're stuck in a loop. We're saying the same things over and over again. it's like, I in Groundhog Day? Am I reliving the same thing we just went through? So let's start there and just say, why do you think that that happens? Why do you think that teams have this kind of Groundhog Day effect where you might have these conversations that just kind of keep popping up over and over again? Marsha Acker (01:35) Mm-hmm. It's a great question, Brian. think a number of years ago, I had a background in facilitation, but I got really interested in this particular question because I found not only in my own experience, I had multiple examples that I could give you of conversations that I felt like I'd have with somebody. then we would be, a week or two later, we'd be back talking about the same thing. And I'd think, I, you know, from my perspective, I thought we resolved that. So, so why are we talking about it again? And then I noticed in my work with teams that they would do the same thing. So, you know, I'd be in a session with a team, I'd help them facilitate a decision. They'd make the decision and then I'd be back with them a month later and the same topic would be up. And I'm I just found myself confused. So I think, I think there are many reasons why that happens. But if I were to, If I were to create a theme for that, think there's a couple of big themes that I see play out. I think there are many places on our teams today where we stay at the surface level of the conversation. Like we get super focused on what we're talking about. So whether it's the tool that we're using, the features that are gonna be in the next release, like we get so super focused on it. And then we're hyper. aware of time boxes. So we want to make sure we talk about the thing, get the decision, and we want to do it in 30 minutes or less. I saw a post on LinkedIn the other day where someone was advocating that there shouldn't be any meeting that would need to go past 25 minutes. And I thought, see it really differently because I think while there are places where we absolutely do need to maybe just quickly exchange information or keep things moving along, or we just want to hear briefly from people. I think if we're advocating that every meeting should only take 25 minutes, we are likely going to have those Groundhog Day conversations because it doesn't give us the space to get to the real topic. So I think that's where we spend a lot of time talking about the thing, the topic, and we really don't create enough time to drop down into focus on are we really, there space here for me to share what I really think or do you just want me to show up here in this meeting that you're running? You clearly have maybe your own agenda. You feel like you've already got the decision made. And so you'd really like my role to be to just receive your information and go off and do it. So I think there's a complexity here of Brian Milner (04:27) Yeah. Marsha Acker (04:32) What's the topic we're talking about? Is it the real topic that we need to talk about? Or is there, is it sort of the mask for what we might be able to drop into a deeper conversation to have? Are we being super focused on a time box? And are we creating enough range in our meetings that we've got spaces where we are efficient and fast and very deliberate about the conversation and then other spaces where, you know, those topics that keep returning. They're great places to go, there's data here for us. I think of them as yellow flags. there's something here for us to explore further. So let's take this topic and let's carve out a little bit more time for it. I'm curious what you see. Brian Milner (05:15) Yeah. No, that's a great observation. And I think you're right. It is a frustration. Looking back over my career and looking back through corporate meetings and things I've been a part of, there is frustration with someone who's coming in and not really having a meeting planned and not really having an agenda. But I think there is another kind of side issue there that can cause a lot of misunderstanding about Marsha Acker (05:33) Yeah. Brian Milner (05:44) what we're trying to achieve and that's the purpose. If we're here for a certain topic, I can understand that, but then what is it that's expected of me in this meeting? Am I here to just receive information? Is this a knowledge dump or a status update from someone else? is this, we have an issue and we need to talk through it and fully understand it. Marsha Acker (05:47) Yeah. Mm-hmm. Yeah. Brian Milner (06:13) And I think sometimes that's what I've kind of seen is that there's this mismatch of, well, I thought I was here for this. And now it's clear that you don't really want my opinion. You just want to tell me what it is. And so now I'm refocused or the opposite. I thought I was here just to receive information, but now I'm realizing that you really need me to dig in and give you my educated advice on this. Well, I wasn't prepared to do that. Marsha Acker (06:20) Yeah. Yeah. Yeah. I think this notion, and I see it happen a lot with Agile teams, like somewhere in our professional careers, and I think there's very good reason for, like we get rewarded for, know, from the time we're in very early school all the way through the end of school, we get rewarded for having answers. And then we end up in the workplace and we find ourselves in collaborative spaces. And so I think there's this belief that, you know, someone who's calling the meeting, they will have a little bit of this internal story that if I come with only questions and no solutions, then what value am I adding? Like that's, how am I useful to this organization? I've actually had people say to me, why would this organization hire me to come in and ask other people questions? Brian Milner (07:28) Wow. Marsha Acker (07:29) And so I think that's really, I love giving voice to that because I do think that there's a narrative that sits in our organizations that I, and a little bit of a fear. Like if I come to a meeting and I'm asking people to collaborate or I'm truly asking them open ended questions and I want to hear what they have to say and we're going to listen to, you know, I talk a lot about wanting to create this collective intelligence. And I think it takes a while to access that in a group of people. that it requires us to be able to suspend this idea that we're not adding value if we're asking questions and to reframe our value as helping to tap into a collective. And you can certainly have a point of view or a perspective, but if you're really wanting to tap into that intelligence, then I think it requires something different of us if we're the meeting host or the meeting leader. I think the other thing that will happen too is depending on who's in charge, like senior architects or somebody senior in the team can also get caught in that trap. Like, well, I'm supposed to come with answers. And I think we can come with ideas. But if we're really wanting to collaborate, and then this gets to your point about why are we gathering? Because sometimes I think there will be places where somebody has already made the decision and they're not asking for input on the decision. Brian Milner (08:42) Yeah. Marsha Acker (08:50) but they're wanting to share the decision that's been made and enroll people in the decision that's been made and invite them into collaborating on actually how that's gonna get implemented. But we're not opening this conversation up for what's been decided about architecture, what's been decided about what's going into a release. So I think this clarity and intentionality like you talk about around purpose, why am I here? What do you want from me? It's huge. And I think it's really tied to also some of our thinking about how are we adding value. Brian Milner (09:23) Yeah. The comment about, know, people not feeling like they're adding value if they're just asking questions that, kind of, maybe it's just for my recent experience with coaching and everything, but to me that, that just, it's so contrary, you know, to, to my way of thinking now, I guess I would say in that, you know, when I've been a part of discussion, when I've been part of a meeting, that I've looking back, that I feel like has gone really well. Marsha Acker (09:26) . Mm-hmm. Brian Milner (09:48) Uh, or, or a person that I feel like has really contributed to the meeting. Oftentimes it, it is that person who is asking questions that get us to think in a different way to get us to consider from a different perspective. So, you know, that that's why it feels a little strange to think about it. I agree with you. I agree that that's, you know, the attitude of some people or that's the way they see, you know, how I contribute to a meeting, but it just feels like it's such the opposite of that. That might be the most valuable thing we could do is to get people to see things from a different perspective or consider maybe things they haven't considered about this issue. Marsha Acker (10:25) Yeah, I think it's one of the first mindset shifts in a transition from being a contributor to maybe managing or leading, whether it's you're just leading a team or whether you're leading a whole organization. I think this idea of where does value come from and what's my role in the value creation, it's a shift, I think, for us. I love when people can get to a place of thinking about creating containers in organizations where people get to be their best. And then it does, your thinking does shift from, what's the piece of content that I can contribute to? What's the question that would really unlock different perspectives? And I think the other piece about that is what's the question that would elicit a... I talk about it being opposed, but you know, a contrarian perspective or point of view, because I think that's the other thing that can keep us in these circular conversations is when what we're really thinking doesn't get said. So if I don't feel like I can tell you in the room what I'm really thinking, I'll tell everybody else offline. Brian Milner (11:34) Right. The meeting after the meeting, right? Yeah. Yeah. And that, course, gets to the heart of psychological safety and kind of those dynamics within a team. We started this off talking about kind of this feeling of getting stuck. And so I want to kind of come back to that a little bit and say, I want to ask you, what are some of the causes of that? Why do we find ourselves trapped in these loops? Marsha Acker (11:36) Yes. You Mm. Brian Milner (11:59) that just, know, whatever we decide doesn't actually do anything or we find ourselves right back in the same place. Why do these, what's causing this? Marsha Acker (12:08) Yeah, well, let's play around with a bit of a framework to help us think about what's happening in the conversation. Yeah. So there is a theory of structural dynamics. It comes from work of David Cantor. And what it allows us to do is sort of think about being able to code the conversation that we're happening. And by code, I mean it helps us focus not on the topic. So whatever the topic might be. It doesn't matter. It helps us focus on how we're engaging in that conversation more of the how. And so there are four actions. Everything that we say could actually be coded into one of four actions, which I think is really kind of fascinating. So you just made a move by taking us back and pointing to the topic about stuck conversations, right? So what keeps us stuck? And that's a move because you're pointing in a direction. So moves kind of set direction in the conversation. I could make a new move and say, you know, let's talk about, yeah, where we might meet at a conference sometime, Brian. But that's a totally different topic. So moves set direction in a conversation. The second action is a follow, which gets behind and supports. So I followed your move by saying, yes, that's great. Let's do that. Here's, and then. Brian Milner (13:12) Right. Yeah. Marsha Acker (13:26) And then a bit of a new move from me, let me introduce a language for thinking about that. So you made a move, I followed, and then brought in another move. So now we're starting to, by being able to name actions, we're starting to get a sense of patterns. So there's two more actions, the action of a pose. So a pose offers like really clear pushback. It says, no, hang on, stop. Let's not go off the bridge or. I really disagree with this piece about what you're saying. So it offers a clear pushback or constraint to what's been said. And then the fourth action is a bystand. And a bystand is a morally neutral comment that names what's happening in the conversation. So I could bystand on myself in a conversation and say, you know, I'm really feeling engaged by the dialogue, or I might say I'm really confused. or if we're noticing a pattern, somebody might say, I notice we're getting stuck. So a bystand is a way for people to name what's happening or bridge competing ideas. But the other thing, the benefit of the bystand is that sometimes it also slows down the conversation. So to your question about what gets us stuck, it's really helpful if we can separate. what we're talking about and start to briefly look at how we're talking because what gets us stuck in conversations is when one or more of those actions is missing over the course of time. So we need all four of them to be voiced. One of the biggest problems in our stuck conversations is that a pose goes offline. Not in every team. There will be teams for whom a pose is stronger. But in my experience in American business, for sure, a pose is often the thing that is missing or it goes offline. So the way it will play out, there's a couple of different patterns. One will be what we call serial moving. And those are teams. Like a meeting with serial moving will have lots of fast pace. So somebody says this. then we're talking about this topic, now we're talking about this. And it will, like, you'll have a feeling like we accomplished a lot, but then you walk out at the end of the session and you go. So we talked about, exactly, we talked about this, this and this, and I don't know what we decided. Brian Milner (15:52) What just happened, right? Marsha Acker (15:58) So people that leave those kinds of meetings, they'll have this sort of false sense of, yeah, we got somewhere when we really didn't, we didn't close things out. So serial moving can be a pattern that can keep us stuck because we don't close things. There can be another pattern where there's a lot of move and follow. We call it courteous compliance. Another word for it would just, I forget the other label that we can give to it, but there's the sense that somebody makes a move and everybody else just says, sure, fine. So it's lacking the energy of the dynamics that you would get if the other actions were active and being voiced. And then there's a pattern where we might have too much bystand. So in a team that starts to complain about why did we use this tool or, know, I'm noticing nobody's using Slack or I'm noticing, you know, when we, when something gets posted in Slack, nobody acknowledges it. So if you find yourself in a meeting where, people are sharing a lot of context or perspective, maybe we can, I call it a hall of mirrors. Like we've got lots of perspective, but what's needed is for somebody to really make a move and say, all right, so given that now, what do we want to do about it? So what's really fascinating about those, we can also get locked in a move and a pose, a really strong advocacy or argument. And what's needed in that kind of argument is we need more follow and bystand. But what I find fascinating, so a pattern that I see play out over and over again will be one of two, the serial moving or the courteous compliance. So we've got a lot of moves or we've got move and follow. Brian Milner (17:25) Yeah. Marsha Acker (17:45) And if I'm someone in the meeting that either doesn't feel like my voice is welcomed or that it would be a career limiting move to oppose you, what I'll do is start to use one of the other actions in place of my oppose. So if it's not okay for me to push back and say, Brian, I don't want to talk about that, or I disagree, I think we're going off track, then what I might start doing is just making new moves. Brian Milner (18:02) Hmm. Marsha Acker (18:15) So rather than say to you, hey, Brian, I don't want to do that, you'll be talking about something, and now I'm introducing another topic. Hey, can we talk about where we're going for lunch next week? Or can we talk about the meaning behind that word over there that we were using last week? we don't do it intentionally. It comes for really good reason. Brian Milner (18:36) Right. Marsha Acker (18:39) We will all have our own reasons about why we do or don't do that. But I think some of the greatest work to do in teams is to talk about those four actions, to normalize them, and to invite them. Brian Milner (18:52) I love this. what kind of fascinated me, caught my attention the most about what you were saying is when I saw these, and kind of reading up here and reading through your work prior to our discussion, those four modes, when I read it, the first time it seemed to make sense, move, follow, oppose, bystand. But when I saw bystand, it really did seem, my first initial gut response was, yeah. That makes sense. There are bystanders that are happening in meetings that just do nothing. They just kind of sit back and they're not going to be, you know, they're not going to get in the way of the flow of something. But the way you described it is really fascinating because it's not a passive thing. It is an active participation. Marsha Acker (19:35) Yeah. Yeah. Yeah. Actually, if somebody is, well, I love that you're naming that because I get asked that question all the time. So again, American business trends. So if you step into the mind of someone who believes that I'm really only adding value if I'm bringing ideas and the way we would code that would be often you're making moves. So people will tend to value. making moves and opposes because a lot of times that's what the culture values. If you're in an organization that says, bring me problems, bring me solutions, you will find a cultural pattern in there of people showing up and making moves and opposes throughout their whole meeting. It'll be a stuck pattern. It'll be overused actions. But if we think about, so bystand could be questions, asking powerful questions. what's that mean to us falls along the line of bringing inquiry into the conversation. And so it gives us a way to balance advocacy and inquiry. But bystand is, bystand and follow are active. If somebody was not saying anything in the conversation, we wouldn't know, we wouldn't be able to code them because they're not speaking. And those four relate to speech acts. So, We have to speak in order for it to be coded as something. But those people who are sitting back often have some of the best bystands. Like if you were to tap that person on the shoulder and say, hey, I would love to know what you see right now in the conversation, they'd probably be able to tell you. Brian Milner (20:57) Yeah. Yeah. Yeah. I love this. And, you know, one of the things we teach in our advanced Scrum Masterclass is having people kind of understand how to deal with conflict in their teams and stuff. And we talk about the Thomas Killman kind of five responses to conflict. And I'm seeing a lot of overlap here in these modes too of, some of these things sound like a certain response to conflict in certain ways as well. But before we run out of time, I want to... Marsha Acker (21:30) Mm. Yeah. Brian Milner (21:43) I want to make sure that we get to, if we're in this situation, what are some steps, what are some things we can do to break that chain and not just have the same conversation again next week. Marsha Acker (21:48) Yeah. Yeah. So I would love for people to just think about using those four actions, especially if you work with a team on a fairly frequent basis, right? You will likely, even as I describe those, you will likely start to be able to identify what's the pattern that might be showing up. So I think the first step is can you identify or create a hypothesis for yourself about what might our structural pattern be? So do I hear like really clear poses? You know, do we make a lot of moves? So if you can find the actions that are predominant in your conversation, that's really the first step. And then the second step, there are a couple of different things to counteract each of them. So if move is really strong and it's coming from certain people, designing your facilitated session or even inviting participants to other participants to be the ones to make the move. So inviting others to speak first is one way to do it. limiting the number of moves that people can make. So sometimes if I'm working with a team that has that pattern, I'll give them some kind of, I'll give them a poker chip or I'll give them a card that says move on it. And I will limit everybody to one move per meeting. So structurally, I'm asking people to start to constrain their own moves. And then asking them to then step into, know, if somebody makes a move, staying with it long enough. as, so as a facilitator, you might say, if you noticed that you've got multiple moves on the table, you might just say, Hey, we've got four topics. This, this, this, and this, which is the one that we want to dive into first. So that's another way of just prompting a group to follow a move that they've made. And I think if you're noticing, you don't have a pose. You. chances are that is not going to come naturally. So I think you've really got to design questions that surface it. asking for what are the risks or who sees this differently. A lot of times if I'm leading a session, I will ask people, where did I get it wrong or what do I have wrong? Brian Milner (23:47) Yeah. Marsha Acker (24:12) What am I missing? What might I not be seen? So those are all ways for me to prompt. And I think if you've got some hierarchy in the room or differentials about that, that's really got to come from the person who's sort of holding some of that positional power maybe. Brian Milner (24:29) Yeah, I love that because there's there's sort of a maybe it's an American culture thing. I don't know. But but I know in the business world I've experienced if you call a meeting if it's your meeting there there's sort of an expectation that you're in control, you know, you know, it feels like there's there's sort of a you're not invited to say something like, what am I missing? Marsha Acker (24:52) Yeah. Yep. Brian Milner (24:53) because that's sort of admitting that you weren't prepared for this meeting. But I agree completely with you, that's not really the case. It's just saying, I can't know everything, so what don't I know about this, I should. Marsha Acker (25:09) Yeah. And it's hard. That can be a hard question. And I often say to people, don't ask the question. Don't elicit a pose if you're not really ready to hear it. It can be hard when somebody says, I think it's a two-ee. I totally disagree with the direction that we're going. Because if I, as the person who's asked the question and now receiving that feedback, If it starts to show on my face or I disconnect from it, what's gonna happen is that gets registered across everybody in that room. And that'll be the last time anybody steps up to answer that kind of question. Brian Milner (25:36) Right. Yeah, I love as well when you were talking about, you know, the actions and maybe having tokens or stuff for people to have actions. think I don't, I'm sure this is maybe part of the intention of this as well, but I love the side effect of that, that yes, I'm limiting people who would be controlling to not, not take control of the entire meeting, but once they've spent theirs, now I'm in a situation where the people who maybe wouldn't be those people that would normally step up. They're the only ones who have that ability left. So you have that side benefit of I'm kind of making space for the quieter voices in this group to have a chance to speak up. And I think that's a really important thing in these kind of meetings too. Marsha Acker (26:35) Yeah, when we find ourselves in stuck patterns, there will be very good reason for, or the Groundhog Day conversation. There will be a pattern to the structure of that conversation that keeps repeating itself. And a lot of times what will be happening is somebody will make a move and very often the person that follows them will be the same person every time. So if Marsha speaks and then Brian follows and that's a pattern that gets set up. every single time. All it does is reinforce me to make more moves because I know you're going to be right behind me. And then over time, we're really unconscious, I think about it, as a structural pattern. But the rest of the team will start to fall back and be like, well, they seem to have it. There's no need. No need. So yes, what we're trying to do is change the behavior by looking at structure and finding ways to invite it. Brian Milner (27:34) That's awesome. This is fascinating. I want to be respectful of your time and everyone's time listening, I could go on for another hour in this conversation. This is just really fascinating stuff for me. And I want to point out to everyone again, if this is fascinating to you, we're going to put all the links to this stuff in our show notes so that you can easily just click on that and find it. But just to call it out again. Marsha Acker (27:41) You Brian Milner (27:55) Marcia has a couple of books out there that are in this topic area that could be really useful to you. One is the art and science of facilitation. And the one that I kind of took a deep dive into is called Build Your Model for Leading Change, which by the way, there's a subtitle of this, a guided workbook to catalyze clarity and confidence and leading yourself and others. And I just, would underline the workbook. Right? Because I think it's true. It is something to kind of work your way through. And it's not just a beach read. Yeah. Yeah. Marsha Acker (28:27) No, it's not. I like to think of it as a Sunday morning, maybe with a cup of coffee and a little bit of quiet space. Brian Milner (28:36) Yeah, love that. I love that picture. Well, Marsha, I can't thank you enough. You know, we've been kind of trading schedules and trying to align this to get Marsha on for a while. And, you know, when that kind of thing happens, for whatever reason, it always seems to be like, when the person comes on, it's like, wow, that was worth it. I'm really, really glad we went through that because this was a great conversation. So thanks so much. Thanks so much for sharing your research and wisdom here on this. Marsha Acker (28:56) I appreciate it. Brian Milner (29:02) and for coming on the show. Marsha Acker (29:04) Thank you for having me. It was great.

Tired of “What went well?” and “What didn’t”? Brian Milner is here to help you cook up retrospectives that actually get your team thinking, collaborating, and improving. From creative themes to actionable frameworks, this is your behind-the-scenes guide to better retros. Overview Do your retrospectives feel more “check-the-box” than game-changing? Brian Milner shares his full recipe for planning and facilitating retrospectives that actually matter. Whether your team is stuck in repetition, tuning out, or phoning it in, Brian’s step-by-step approach will show you how to bring structure, creativity, and energy back into the room. Brian walks you through the five essential components of a retrospective, including how to match formats to your team’s personality, align activities with Agile's three pillars (transparency, inspection, and adaptation), and spark meaningful change with every session. References and resources mentioned in the show: Stranger Things Retrospective Download Agile Retrospectives by Esther Derby & Diana Larsen Retromat Blog: Overcoming Four Common Problems with Retrospectives by Mike Cohn Blog: Does a Scrum Team Need a Retrospective Every Sprint? By Mike Cohn #139 The Retrospective Reset with Cort Sharp Retrospectives Repair Guide Better Retrospectives Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast, like we always do. And I'm with you as always, Brian Milner. Today we have with us, me, just me. Now, before you get frustrated with that or think we're copping out in some way, this is intentional. I wanted to have an episode to myself because and working through all this stuff around retrospectives, I thought that it might be good to take an episode here. And I kind of thought of it sort of like a cooking episode, right? Like if you watch a cooking show, you know, Gordon Ramsay show or something, they'll walk you through how they make something. And it's from start to finish. They show you the ingredients. They show you how everything's put together. And then you see this beautiful dish at the end. Well, I've often compared the way that you can format a retrospective to a little bit like a meal, because a meal has different courses in it. And a retrospective should have these themed areas or repeatable sections of it. And so I thought of it a little bit like making a meal. So I thought I'd just walk you through a little bit step by step. what I'm thinking here and how I would go about doing it. this is, you know, we're cooking up something special here. It's a kind of a recipe here that's, you know, equal parts creative and effective. It's a way to try to keep your retrospectives interesting, but also keep them to be solid and where you can have an actual outcome that comes from this. And you actually make definitive changes here with your team as a result. So there's a couple of retrospective courses that I have coming out where I go into detail about all these things, but I wanted to take an episode where I could walk you through and just have you kind of peer over my shoulder a little bit about how I might do this if I was going to create a retrospective for a team. So first starters, I think we have to understand that there is a menu to follow, right? And I kind of use this menu metaphor because one of the great things about when you go out and you have a meal at a nice restaurant is there's a repeatable pattern to it. You kind of expect that they're gonna bring you a drink first and then maybe you have, if it's a really fancy restaurant, maybe you have appetizers first or hors d'oeuvres even before appetizers, then you maybe have appetizers or not. Then you have a main course and maybe you have a salad even before the main course and then you have a a meal, and then you have some kind of a dessert afterwards, maybe even some kind of a cocktail at the end of the meal or coffee at the end of the meal. But there's sort of a pattern to it. And regardless of what restaurant you go to, you kind of repeat that same pattern. Now, I know that there's times you'll be, this is where the metaphor kind of breaks down a little bit, I get it. You may not have the same pieces every time. And what we're going to be talking about here as a retrospective pattern is that, yes, you should sort of follow the same pattern. You can't really get to, let's say, dessert. You can't just skip and go to dessert, right? You've got to go through this journey of the other sections so that you can end up at dessert and really fully appreciate it, right, and get the most out of it. So that's where this metaphor is a little bit of a, starts to break down a little tiny bit. But. I want to talk about here first why retrospectives matter and why they often go stale. I think they often go stale for a lot of reasons, but one of the chief reasons I've encountered when I work with teams is that the Scrum Master on the team really only has a small amount of formats and styles that they have to work with. They have a small little set in their toolbox. And they may even rotate through a few of them. But at the end of the day, it's kind of a small toolbox. There's only a few tools in there. And if I'm a team, if I'm a member of that team, you can imagine how I might get bored. And I might think this is not really worthwhile if I'm showing up every single time and I'm hearing the same exact questions. What did I do? What do we do well? What do we not do so well? Do I have any roadblocks? If I'm just asked that same thing every time, then I might not feel like this is a very worthwhile thing. Or I might get to the point where I feel like, gosh, I've answered the same question, you know, three sprints in a row. I just, got nothing more for you Scrum Master. I just, I can't dig any deeper. I've given you everything and it just feels like this is the, you know, groundhog day. We're doing the same thing over and over again, but nothing's really changing. So. I think it's important that we be able to switch things up, but it's not change just for change sake. That's why I think that having a structure of some kind can give you that pattern to fall back on that can make it effective, but then also can provide variety, can make it something that changes over time as you do this with your team. Doesn't mean that you can't ever repeat a format that you've used. I don't think that's a bad thing. I just wouldn't want to repeat the same, just handful, small little number of them over and over again. That's going to get repetitive and it's going to make people a little frustrated. The other thing is I think you have to match these to the personality of your team. Your team might be more outgoing or they might be more introverted. You might have people who prefer activities or little more, you know, kind of quiet activities or some that are more verbal, you know, require more discussion. That's really an individual thing for your team. So I think you have to think as you go through this, what's going to work for these people, right? For this set of individuals that I am working with. You know, I always say there's kind of a first commandment for Scrum Masters, know thy team. And I think that's really something that's important for us to grasp onto is we have to know our team. can't coach to the average. Right? We have to coach to the individual, to what we have on our team, because your team is unique. That set of individuals has never come together anywhere else in the world. Right? Those personalities. And what you want is to find out how to make that set of people work well together. Right? How do they work best together? Not how does every other team in the world work best or how does the average team work best? How does your team work best? Right? So with all of this is sort of setting this and saying that there should be a pattern. I do want to give the hat tip here and say that the Esther Derby Dinah Larson book on retrospectives is one I strongly recommend. In fact, pretty much my whole career as a trainer, I have said, when people say if there's one book, if I'm to be a Scrum Master, if there's one book that you would say would be really impactful to me from pretty much day one, I have pointed to that book. It's called Agile Retrospectives, Esther Derby, Dinah Larson. And in that book, they lay out a pattern of kind of five phases that go through it. I'm going to distill it down because to me, it's sort of the three middle ones that are the most important. I will talk about the two on the ends here as well and kind of put that on top of these three. But sometimes I find people find it easier if they just remember what I'm gonna teach you here about the three that are in the middle. So in Scrum Master classes, we will talk often about how there's these three pillars of the Agile process or three pillars of empiricism. Empiricism says that we learn through experience. Well, I always say in class, it's not enough to just do the wrong thing over and over again. I gain a lot of experience by doing the wrong thing over and over, but I don't learn from it. And the three pillars are what's needed to make sure you learn from them. And I'm sure you've heard these before, but if you haven't, transparency, inspection, adaptation. Those are the three. Transparency meaning we're not going to be clouded about how we do the work. We're going to be very transparent, open about it. We're going to try to reveal how we work best as much as possible. Inspection, that we're going to actually take time and pause and try to figure out not just what happened, that would be transparency, right? What's the reality of what just happened? But inspecting says, why did this happen? Right? What's the root cause of it? I don't want to just deal with the symptoms, right? If we just try to cure the symptoms over and over again, we still have the same disease, we still have the same illness, and we're not really getting to the root cause. So inspection says, we're going to take time out to actually get to the root cause. And then adaptation, the last one, is probably the most important step here, because if you figure out what's wrong, but you don't ever do anything about it, well, we're doomed to have the same exact discussion again. So adaptation says, now that you know what the problem is, what are you going to try different? We may not even know exactly what the right thing to do is, but we got to try something. What we know for certain is what we did didn't work. That's the one thing we absolutely can't do again, is exactly what we did. We've got to try something new so that we move on, right? So that we find out more information and get closer to whatever our final solution is. So transparency, inspection, adaptation, those three actually serve as a good guideline or three phases you can think about for your retrospectives. There needs to be a transparency phase where you try to figure out what happened this last sprint. there needs to be an inspection phase where now that we know what happened, we got to ask the question, why did it happen? And we need to get to the root cause of why it happened. Now that we know what that is, then we have to move on to adaptation to say, what are we going to do about it? How are we going to take this knowledge we just gained and actually make a change? So we need activities around all three. And what I'm saying here to you is that can serve as your menu. I can do lots of different activities that would match these three areas. Now, I do, again, want to go back to the Esther Derby, Dinah Larson book, because their five phases adds one on the beginning, one on the end, which I actually do think are very helpful. The first one is kind of opening the retrospective. It's a way of trying to just start to get voices in the room. And this is something I will often do as well. Just a quick, quick exercise to just get people to start talking. And that's one of the ways you can start to get a quieter group to get involved is throw them something really easy to respond to right out of the gate. And then the last one is to close the retrospective. Closing the retrospective is a great way to then try to sum it all up and say, well, here's the takeaways, here's the things we're going to do about it, and we're going to move forward from here. Opening the retrospective to that introduction can also then review what you talked about at the end of the last. retrospective. You can say, here are the things that we decided, and let's talk about what's been done about them before you start to inspect the current retrospective. So given that, right, I know I'm going fast here, but you can rewind and listen back to this if you need to. But if you think about that, that you have these kind of phased approaches, and think of it like a menu, right? There's different courses to my menu. Well, I'm not going to serve the same meal every time. That would be boring. So I got to find out different things I can serve for each course of my retrospective. Now, here's where it gets interesting, right? Because there are lots of tools out there. And there's a website that I often recommend called RetroMAT. RetroMAT is a great site where you can go to, and it has those five phases. You can kind of scroll through different exercises for each of the five phases. they sort of have, you you can kind of mix and match and create your own menu based off of that. And doing that is absolutely free. Now they have paid things there as well. They're not a sponsor. I don't get any kickbacks or anything from them. But they have some paid activities as well as far as having things like Mural and Miro templates that you can use if you want to do that as well. So there's lots of things you can do there to thank them for what they put together. But there are times when Maybe you're trying to fit this to your team specifically, or you've grown tired of the exercises that you're used to, and you want to find some new dynamic to add into your retrospective. So what I'm going to do is kind of walk you through what I would do if I wanted to take some kind of a theme and create a new retrospective that's themed around a certain topic. Now I will say that this theme is gonna go just in one of our sections. So it's not going to go throughout it. I'm not gonna be that creative here with you on it, because I don't think you need to be. I don't think you need to have this, it's not like a theme to party, right? You can just take the theme and use it in one of the sections. So what would I do for something like this? Well, I'd start with, as I said, some way to kind of open the retrospective. And I like to have little quick activities as I said, that just get voices in the room. an example of things I've done in the past. Ask the team a quick question like, if this last sprint were a song title, what song title would you use to describe this last sprint? And people can use whatever kind of music they like, right? It doesn't matter. They can just call it any songs that they're familiar with. Or do movie titles. I've had a lot of fun in the past doing that with teams where I'll say, hey, shout out a movie title that might represent this last sprint. You just want to find something quick that people can shout out like one or two word answers, right? Or a small sentence in the case of a song title or movie title or something like that. But something that they can tie it into, right? And it doesn't have to be anything that makes perfect sense, right? It can be kind of crazy. It can be... You know, if this last sprint were a flavor of Starburst or, you know, an color, what color would it be and why? And just have people, you know, shout out whatever they think the answer would be. They might have to be a little creative with their answers when they do that. But that's okay. You're just giving them an opportunity to have a few voices start to enter the conversation. Don't force anyone, right? Don't force anyone to shout out, but give them an opportunity to. So I'm going to open the retrospective with some kind of fun, quick exercise like that. Probably won't take more than five minutes, okay? Then I want to move into that transparency section. And the way I frame transparency is what actually happened this last sprint? What was the reality of what happened this last sprint? So here's where I'm going to inject a themed kind of approach. And I just, I go through a couple of examples in our courses where I talk about doing this, but I picked a different one here for this podcast episode that I've put together right before this recording to try to walk you through a little bit of how I did this. So I tried to pick something that was a little more relevant to today. I know that this is popular and people are looking forward to the next season, which is about to come out. sometime soon, I know they've been shooting it, but I picked the theme, Stranger Things. And I just thought, what if my team, you know, had, I knew there were some people on my team really into Stranger Things, or what if I just knew they were aware of it, they knew what it was, and I wanted to have a theme built around this. So here's how easy it is to do this. I went to chat GPT, and I asked it to give me some, you know, putting together a retrospective that I want to theme it around stranger things. And give me some major themes from Stranger Things that might align to Some different ways of collecting information around what actually happened this last sprint. And. They gave me a long list of different things. And I read through these and kind of tweaked them, talked back and forth with it a little bit, kind of refined. And I distilled it down to five sort of themes or categories I thought would be fun and would kind of challenge the group to think along different lines of thought. So here's what I came up with with Chat GPT's help. My first category. I called running up that hill. And what I put for the prompt for this one is what felt like an uphill battle this sprint? Now just think about that, right? In traditional sprints, there's lots of things that are just, I'm essentially asking what was the obstacles? What were the hurdles in this sprint? But I'm getting them to think about it in little different way by saying, what was an uphill battle in this sprint? And even that subtle rewording, of that prompt can trigger people's brains to work in a different way and get them to think along different lines. If I just ask over and over again, you know, what was a blocker of this sprint or what blockers do we encounter this sprint? If I use those same words over and over, I get sort of immunized against them and I can't really think about anything new. But just phrasing it that little slightly different way, what felt like an uphill battle this sprint I think can really trigger some new ways of thinking. So that was my first category. The second one that I came up with, big theme here in Stranger Things, was the upside down. And I related it this way to say, what is completely upside down right now? What is the opposite of what it should be right now? Now here, I'm trying to get them to think about things that are not really going well, right? Things that are going the opposite direction that they should, and it's upside down from what should be the normal. Right? And again, we're just thinking along this theme of stranger things and I'm tricking their brains a little bit into thinking along a different line, right? To examine it from a different point of view. My third category that I thought would be fun was I titled Vecna's Curse. And what I prompted here for this one was what haunted the team this sprint or kept coming back up to bite us. And The idea here is to get them to think about things that were maybe decisions we wish we had made differently. These could have been decisions in the past. It didn't have to be a decision from this sprint. But what are those things that we felt kind of like was like Vecna's curse? It was just something that kept rearing its ugly head. And it was just a struggle for us to get around. My fourth one, just to have a little fun. I call the fourth one Surfer Boy Pizza. And what I put as a prompt on this one was, where did we bring the chill? Where did we bring the creative spin to a tough solution during the sprint? So here I'm wanting to celebrate good things, right? And I'm asking that in a funny way. So it brings some humor to it, puts them in a better mood, and also gets them to think along a maybe a little bit of a different line in this area to think, all right, well, what do we get really creative about? What do we have to be really creative about in this sprint? What kind of tough solutions did we really conquer? Did we really nail in this sprint? And I'm just theming around that loose theme of that surfer boy pizza from the last season. And then the last one, I couldn't have categories here without mentioning Hellfire Club. So the last one was Hellfire Club. And the prompt I put for it was, where could we bring more of kind of that Hellfire Club vibe, planning, teamwork, shared adventure, right? Just the fun. Where could we put more of that vibe into our team and to how we operate? Now, this is getting them to think about something that might otherwise be a little bit of a uncomfortable thing to think about, right? Because Now we're getting into interpersonal dynamics. We're getting into how the team actually works and fits together. And that's why I chose this theme, because I wanted it to be just kind of a, even maybe a sneaky back doorway of getting their brains to start to examine, yeah, what would have made this more fun? Or what would have made this, how could we have, I've asked often in retrospectives, what would it take for us to be the team that everyone else wishes they were on? Well, That's what I'm asking here, essentially. So I've got my five themes. And I even then went forward and created and kind of get some images for each one of those, like icons for each one of those things. Just created a board and mural for this and put each of those things up. Had a big block space next to each one where people could put Post-it notes. So what I would do here in the retrospective is I'd introduce this. I'd give them the prompts for each of the section and say, all right, let's take a few minutes. Everyone can add Post-its to any of these sections, but try to think through several of them and put several of them up here on the screen or physical board if we're in the same space. But take a few moments here to think through each category and see if there's anything that you can think of that you would add to each area. So we take, I don't know, five, 10 minutes to do that. normally time that, I just see when it starts to slow down. And there's generally a point there where you can kind of intuitively feel it and feel like, you know, the group's ready to move on. So whenever that time comes, I'll call a halt to it and I'll say, all right, now that we've done this, I want us to try to narrow down what's on the board. So let's give you each three votes. And I do this usually with dot voting or something along that line. where they have three dots they can place on three different sticky notes across all five categories. And what I tell them is find the three that are the most important of all the things here, what are the three that are most important and put your vote on those top three. And by doing this, having the team vote on it, then we surface the most important three out of the entire group, right? It's not to say we ignore the others, but we're going to try, we can't focus on everything in our time that we have. So, whether our top three, and then I start with the first one, right? So right now, all we've done is kind of the introduction of the sprint. We've done a transparency section. Now we move into the inspection. Now there's lots of different things you can do here, but what I put together for this retrospective was taking them through sort of a five whys activity. So I would take that first one, I'd have them examine it and look at it and say, all right, let's ask the question why five times for this one. Why did this happen? whatever they answer, then we say, all right, well, why did that happen then? And we ask why, it doesn't have to technically be five times, but you need to ask it enough to where you get down to something that you can say, yeah, that's definitely the root cause, right? That's what's underneath all this. All that followed it, all that came afterwards was all stuff that came as a result of us making that decision. So once we have our root cause, we can repeat that again for the other two. if we have time, but if we're starting to run out of time, I kind of watch my time box there. And once I realize we need to move into solutioning, then we'll move on into the adaptation portion. In adaptation, we just take each single one, and we kind of repeat this process of getting possible answers across the team. So for the number one issue that you guys identified, here's our root cause. Let's take some post-its here. or let's take some suggestions of what we might possibly do to counteract this in the next sprint. So we get those things that come up. Then we'll talk through each one, and we'll try to build consensus as a team as to the most important step to take. So for each item, I want what's the one most important thing to do. So we'll identify that, again, as time allows, I want to at least do the most important thing. If we have time for more than that, great, we'll get to the second and third. But I think it's so important to just, whatever the biggest, most important thing is, make sure you have an action item for that thing. And here's where I just caution you. It doesn't have to be, hey, we've knocked it out. We've cleared it. We've solved it in the next sprint. It just has to be that we've taken a step towards solving it, right? What's the old phrase, a journey of a thousand miles starts with a single step. Well, the same thing goes for our teams. And this is oftentimes why teams get stuck, is they just feel paralyzed. Hey, there's nothing we can do about this. It's such a huge issue. Well, that's not true. What's the next step you can take? So take the next step. Make sure that the team understands what it is. And make sure we understand who is going to be responsible for that. And do that for as many as you can get through. Then get to the closing the retrospective part of it. Kind of wrap up. Remind them, here's the journey we've taken, here's what we've uncovered, and here's what we're gonna do differently for next time. And now those items, they should go straight into your next sprint backlog, not product backlog, sprint backlog, right? They don't need to be prioritized because the product owner has been with you, they should have been with you in this meeting, it's the entire Scrum team. So the product owner has weighed in as well. This has been a team collective decision. So now those items should go into your sprint backlog, and you should do something about them in this next sprint. That's the whole concept of the Kaizen comes first, right? The good change should happen before we do anything else so we can get the benefit of it over a longer period of time. So that's kind of the idea here. And I wanted to give you that kind of really quick flyby to help you kind of see how to go about doing something like this, right? And I just picked one theme. I just picked Stranger Things because I thought it would be fun to work on. I thought it would be a fun kind of theme. And it might be fun for a team I was working with. But maybe that's not something that aligns to your team. Maybe your team has a bunch of people who are really into cricket. Well, do a cricket-themed one. Maybe you have a team that's around the Academy Awards time. And everyone's talking about, and now people don't do this as much anymore, but. Maybe they're all talking about who's going to Oscars this year or something. Well, do an Oscar-themed one. Or it can be around anything. Do it around award shows in general. It doesn't have to be just Oscars, but do it around any kind of award show. And you can pick up different themes. Again, if you're stuck, ask your favorite large language model and see what it comes up with. It's not all going to be gems that comes from that, but you can pick and choose and refine it, which is exactly what I did with my five themes for this. So I hope you see how easy it is to do that. It doesn't have to be complicated. You don't have to be extremely creative to do this. You can make use of the tools that you have available to you. And as a Scrum Master, you can keep this fresh. You can tailor this to the team that you have. What is your team really into? What's the theme that they would really resonate with? Choose that. Go with that. Create a theme around that and see what they think about it. Afterwards, ask them, hey, did this work all right? Did you like this? I hope that's been useful to you. If you like this and you want to hear more like this, come to our website to mountngoatsoftware.com and check out our courses that we're launching actually this week, Better Retrospectives and the Retrospective Repair Guide. Those are the two that we really want to have you kind of think about. Come to our site, find out more about them. Better Retrospectives is all about just the expert level retrospectives course really gets into the heart of a lot of these issues at a very, very deep level. The retrospectives repair guide is taking the 10 most asked questions that we have about retrospectives at Mountain Goat Software and giving you really deep dives on how to solution those, how to problem solve those top 10 issues. And the great news for you is if you're listening to this in real time, right, when we've launched this, We're launching this as a two-for-one special. We'll not have that special again. So it's $99 that you get both of those courses. You don't have to pick and choose from them. You can give $99. They're prerecorded. You can watch them at your own pace. This is for people who want this knowledge, who want these answers. And I know when I was a Scrum Master starting out, there was a lot of, I followed a kind of the pattern that Mike established with his sprint repair guide. I bought that when I was coming up as a scrum master because I needed answers to some of the questions that he had in that scrum repair guide. Well, take a look at the 10 that we have for our retrospective repair guide. Maybe you'll find one of those things that's really tripping you up and maybe just getting the answer to one of those is going to be worth the money for you. I encourage you to go to our site, check it out. Don't miss this. It's a limited time cart that's opened. It's only going to be open for a week. So if you're listening to this when we launch it, don't delay, don't wait until next week. If you hear this next week, then you're running out of time. So make sure that you take advantage of the time that you have here so that you can get these two courses, two for the price of one here at our launch. Again, we won't do that again. So I hope you found this to be useful. It's just a little taste of the kind of thing that's in those courses for you. And if retrospectives are something that you're struggling with, or if retrospectives are something that you just feel like, man, it really could be more. It really could deliver more for my team. Check out these two courses. I really think they're gonna help a lot of teams out there. That's why we put them together. So that'll wrap it up. I hope you've enjoyed this and we'll talk to you next time. on another episode of the Agile Mentors Podcast.

What do Spotify, Google Meet, and your expense report tool have in common? They could all delight your users—if you design for more than just function. In this episode, Dr. Nesrine Changuel breaks down the emotional motivators that transform average products into unforgettable ones. Overview What separates a good product from a great one? According to Dr. Nesrine Changuel, it's not just meeting functional needs—it's creating emotional delight. In this episode of the Agile Mentors Podcast, Brian Milner sits down with Nesrine, a former product leader at Google, Spotify, and Microsoft, to explore how emotional connection is the secret sauce behind the world’s most beloved products. They dive into Nesrine’s “Delight Framework,” reveal how seemingly mundane tools (like time-tracking software or toothbrush apps!) can create joy, and explain why delight isn’t a nice-to-have—it’s a competitive edge. Whether you're a product owner, product manager, or just want to build better user experiences, this episode will change how you think about your backlog forever. References and resources mentioned in the show: Dr. Nesrine Changuel Product Delight by Dr. Nesrine Changuel Blog: What is a Product? by Mike Cohn #116: Turning Weird User Actions into Big Wins with Gojko Adzic #124: How to Avoid Common Product Team Pitfalls with David Pereira Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Dr. Nesrine Changuel is a product coach, advisor, and speaker with over a decade of senior product management experience at Google, Spotify, and Microsoft, where she led major consumer products like Chrome, Meet, Spotify, and Skype. She holds a Master’s in Electrical Engineering and a PhD in Media Processing and Telecommunications and is based in Paris. Auto-generated Transcript: Brian Milner (00:00) Welcome back Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always Brian Milner and today I have a very special guest with me. I have Dr. Nesrine Changuel with me. Welcome in Nesrine. Nesrine (00:14) Hi, Brian. Thanks for having me. Brian Milner (00:16) I'm very excited to have Nesreen with us. I think this is going to be a really, really great episode for all of you product owners out there or product specialists, anybody who works in the product area. I think you're going to find this really interesting and you're going to want to bookmark this one. Maybe even come back to this a little bit. Nesreen is a coach, a speaker, particularly in the product area. She has previously worked at Google. She's worked at Spotify, at Microsoft, so no stranger to large enterprise, very high profile products that she's worked on in the past. She has a book coming out in May, so look for this book. It's called Product Delight. And that's really what we're going to be focusing on here is the concept of eliciting or generating kind of an emotional response to our product. I guess I'll start by, did you stumble upon this? What drew your interest to people's emotional response to products? Nesrine (01:19) Yes, so maybe I can share the story how I came to this topic and how I became so vocal about it. So in addition to being a product manager and leader over the last decade, I was always and I always enjoyed being a speaker. So I always wanted to go on stage and share insight. This is probably coming from my research background, because when I used to be a researcher, I traveled the world to go and present my research work and When I became a product manager, I kept this habit with me. So I always been on stage and I spoke about different topics like product discovery, product operation, different topics. Until one day I got reached out by a conference organizer and he said, Hey, Nisri, we want you on stage, but we have an idea for a topic for you. I'm not that used. Usually I come up with idea myself, but I said, okay, what do want me to talk about? And he said, Hey, Nusreen, you have been working for Spotify, for Microsoft, for Google Chrome and Google Meet, and we all admire those products and we consider them very successful products. What if you come and tell us what's the common thing that probably is there any common thing that made those products successful? Being an insider, being within those company, could you share with us something that you consider in common between those products? To be honest with you, I found it challenging at the same time interesting as an exercise. I was not, by the way, able at that time to answer the question, what's in common? So I sat down and I did the exercise myself and I started to think what was really in common? What made Skype Skype? What made Spotify Spotify and those Google products so successful? And I came to the following conclusion. I found that what made those products so successful is that they don't only solve for functional needs, but they also solve for emotional needs. So when we use a particular product, we use it for a certain functional need, but we also use it for an emotional need. And without even knowing that I have been doing it for more than 12 years, I came to the conclusion that, my God, during all those years, I have been focusing so much into users need from both angle, functional and emotional. So I came on stage and I spoke about that topic and from that day, I started to give it a name. I'm calling it emotional connection. I'm calling it product delight. And I'm here to share more about it as well. Brian Milner (03:50) That's awesome, yeah. I mean, I think we do hear a lot and we focus a lot on that functional kind of need, the way you differentiate there. think that's a good differentiation, functional and emotional kind of needs or motivators there. yeah, I mean, I've always heard, know, kind of that kind of general product advice is, you know, find the things that... people really, really have as huge needs, the things they would pay someone to do for them. And that's the key to success is finding those huge needs. But we're actually going beyond that to say, yeah, those are important. It's not to say that we should skip that, but it's when there's the emotional connection to a feature or to something that we do that really the light bulb kind of comes on for our customers. Is that kind of what your research is leading to? Nesrine (04:40) you're getting it right. Don't get me wrong. Of course you have to honor the functional needs and serve the functional feature, but the delight or the emotional connection happens when you go beyond exactly how you said it. Let me explain. If you serve only functional needs, you know what you get? You get satisfied users because they are asking for something and they are satisfied about what they are receiving. Now, Brian Milner (04:41) Okay, okay. Haha. Nesrine (05:05) If you surprise them by going beyond, by anticipating their need, by exceeding their expectation, you're not only satisfying them, you're surprising them in a positive way and delight is the combination of surprise and joy. Actually, the theoretical definition of delight is a combination of two emotions, surprise and joy. So going beyond, anticipate need and exceed expectation. is what we should aim for in addition to the functional needs. Brian Milner (05:35) That's awesome. Yeah, I use this example sometimes in, we use this example in the agile world to talk about, you know, the part of the agile manifesto that says customer collaboration over contract negotiation. And, you know, there's an example I use from my past where I used to work at a company that was very contract driven. And, you know, the thing that I always used to kind of take away from that was the very best we could ever do or hope to do. was to meet our customers' expectations. We could never, ever exceed it because we were only doing exactly what they told us to do. So I think this is a really important distinction here to make that just meeting the customer's needs, just meeting the minimal customer satisfaction bar, that's not going to keep you with loyal customers. That's not going to have repeat customers, or they're not going to tell their friends about, you know. That product did exactly what I hoped it would do. But it didn't really surprise me. It didn't really go beyond that. I know you talked about, because I've read your blog and a little bit of the discussion about this. So I know you talk about in the blog kind of the connection to Kano analysis. And I've always thought that's a really great way to try to determine things to target and go after. So talk to us a little bit about that, about Kano analysis and kind of what that uncovers and how that connects to what your research has shown. Nesrine (06:51) Yes. I love Kano by the way. I, I mean, that's one of the framework I have been considering throughout most of my product career. But this framework comes with a limitation and let me explain. So first of all, for those who are not very familiar with Kano, Kano is a visualization or categorization, let's call it. It's a categorization framework that allows to categorize features among different categories. One of them is must have. So these are the things that absolutely have to be in the product. Other that are performances, which are the more you have, the more satisfied users are, the less they less satisfied they are. And of course there are the delighters and delighters are those feature that when they are in the product, users are surprisingly happy. And when they are not, are not even the satisfaction is not even impacted. So the limitation of Kano is that it doesn't tell you how to achieve delight. Let me explain. I think we live in a world that everyone agree that we should delight our users. I mean, this, this concept is now globalized and everyone is talking about delighting users. The issue is that we don't know how to delight them. So we know category, there's a category that called delight, but we don't know how to. So the, the framework that I'm introducing and I'm calling it the delight framework is the framework that allows to first identify. So it's usually, represented into three steps. The first step is to start by identifying the emotional and functional motivators. So let me give you an example. I've been working at Spotify for about four years and as a Spotify user, imagine yourself, you are a Spotify user. You do have, of course, functional motivators. What could be the functional motivators? Listening to music, listening to podcasts, maybe listening to an audiobook. So all those are functional motivators. Now, what could be the emotional motivators as a Spotify user? It could be feeling less lonely. It could be feeling more productive because when you're working you need to listen to something. It could be about changing your mood. It could be about feeling connected. So all those are emotional motivators that drive users to use a product like Spotify. So what I encourage every product manager or every product team to do at first is to dig into identifying, of course, the functional need. And everyone is good, by the way, in identifying the functional needs. But also, while doing that exercise, pay attention to what could be the emotional motivators. So that's step number one is about listing the functional and the emotional motivators. Once you have those, Now we get to the second part of the framework, which is look at your backlog. And I guess you have a very busy backlog and take those features one by one and see for this particular feature, which motivator am I solving for among the functional ones and among the emotional ones as well. So the delight grid, for example, is a visualization tool that I came and created in order to allow product teams to visualize their backlog and see how many of my features are only solving for functional motivators. In that case, we call that category low delight. How many of my features are only solving for emotional motivators? These are very rare, but the best example I would call is, for example, I'm having an Apple watch and one month ago it was New Year Eve and at midnight I get fireworks popping out of my Brian Milner (10:35) Ha Nesrine (10:36) Apple watch and it was a happy new year there's nothing functional in there but it's all about creating some smile I call this surface delight and then how many of your features are solving for both functional and emotional motivators and I call this deep delight so maybe I deviated a bit from your question compared to canoe but it's actually about adding this dimension of connecting features to the real motivators of the users. Brian Milner (11:07) No, maybe a little bit, but you connected it to where we end up going anyway. So I think that's a great connection there. And by the way, for anyone listening, we'll link to all of this so that you can find this and follow up. But I like that differentiation between surface delight and deep delight. I know some of the examples that I've heard used kind of frequently in looking at Kano analysis and kind of trying to find those delighters. And that is kind of the area that it specifies there in Canoe, right? You're trying to find those things that are not expected, but when people find that they're there, they like that it's there, but they don't expect it's there. So if it's not there, there's no negative response that it's not there, but there's a positive response if it's there because they like seeing it. And my boss, Mike Cohn, tells this story about this Nesrine (11:59) Yes. Brian Milner (12:03) There's a hotel in California that became famous because at the pool, they have a phone that's by the pool that's the Popsicle Hotline. And you can pick up the phone and you can order a Popsicle to be brought to the pool. And it's the kind of thing where you're not going to go search for a hotel. Does this hotel have a Popsicle Hotline? I'm only going to stay at hotels with Popsicle Hotlines. It's not that kind of a normal feature. It's a delight feature because when you see it and you find out it's there, it's like, that's really cool. And it can be the kind of thing that says, yeah, I want to search that hotel out again next time I'm in this area because I really thought that was a nice little attention to detail and it was fun. But I think what I'm hearing from you is that might be more of what we would classify as a surface delight. It's not really meeting a deep need. Nesrine (12:35) Yes. Brian Milner (12:56) But it's fun, it's exciting, it's not expected, but it doesn't really cross that threshold into, but it also meets kind of functional delights. Is that kind of what you're saying there? Okay. Okay. Nesrine (13:08) Yes, actually I heard about that hotel story just to tell you how much viral it went. It came to me. So actually you get it correct that I consider that as surface delight and I have nothing against by the way, surface delight. You can add surface delight. The issue is you can end up doing only surface delight and that's not enough. So the idea is to do a combination and I do have two stories to share with you just to compliment on this hotel story. One is personal and one is professional. Brian Milner (13:21) Yeah. Okay. Nesrine (13:37) The personal one just happened to me a month ago. I went to Sweden and I went to Stockholm. That's where I worked for eight years. And I went there for business and I decided to meet some friends and some ex-colleagues. So we all gathered and went to a restaurant, a very nice restaurant in Sweden. And came the time where we had to say goodbye and to pay. And I guess you can feel it immediately when it's about paying and we are a large group and you start to get that anxiety about who's paying what and what did I order? What did I drink? What? I mean, I honestly hate that moment, especially in a large group where you don't necessarily have a lot of affinity with us. Like, should we split in 10? Should we pay each one paying its piece anyway? So that was a moment of frustration, of anxiety. Brian Milner (14:09) right. Yeah. Nesrine (14:28) And I loved how the restaurant solved it for it. You know how they solve for it? I mean, maybe it exists in the U.S., but for me, that's something I never seen before. The waiter came with a QR code on a piece of paper and you scan the QR code. And when you scan your QR code, you get the list of items that got purchased by the table. And all you have is to pick, and that happens automatically real time. Everyone is picking at the same time. You pick the things from the list and you pay. for the things that you order. You can even tip on the bottom. You can give feedback. Everything happened on that QR code. And you can guess how much that anxiety could be removed. So that's the personal story I wanted to share. The second story, which is more professional, I want to share how we try to improve experience at Google Chrome. So I've been the product manager at Google Chrome. Brian Milner (15:13) Yeah. Nesrine (15:25) And we started from the observation that people do have plenty of open tabs. I guess you are one of them, especially on mobile. Like on mobile, you go and check how many open tabs you do have on Chrome and you realize that they are have, we realized at least out of numbers, out of data that people do have plenty of open tabs. So it started as Brian Milner (15:32) You Nesrine (15:47) technical issue. Of course, the more tab you have, the heavier the app is, the slower the app could be, et cetera. So we wanted to reduce the number of unnecessary open tabs in Chrome. So we interviewed users and we started to check with them, why do they even leave their tabs open? So some of them leave tabs because they consider them as a reminder. I mean, if tab is open, it means that you need to finish a task there. Some people really leave tabs just for ignorance. mean, they moved from a tab to another and they completely forget about them. Actually, we realized that the fact of leaving tab open, the reason for leaving tab could be completely different from a person to another. And the other interesting observation, and when I say identify emotional motivators, you will realize that people feel a bit ashamed when they show to us that they do have plenty of open tabs. Some of them would say, sorry, I usually don't even have so many open tabs. It's only now. And I'm like, it's okay. But the point is, if you have this mindset of trying to track the emotional insight from your users, you will take note. And the note was anxiety, feeling ashamed, blah, blah, blah, blah, blah. And that was in introduction for in... Brian Milner (16:42) You Yeah, right. Nesrine (17:04) improving the tab management experience later on in Chrome. Brian Milner (17:07) That's actually a really good parallel, though. I think that's a good example because it reminds me, too, even going back, I remember one of the things, and I'm going way back here, but I remember one of the things about Gmail that was kind of a selling point initially was the concept there of you don't have to worry about maintaining an inbox. keep all your mails and search. And you can search through your mails and find whatever it is. And I remember prior to that, most people would use something like Outlook or something like that to have their mail, there was always this constant struggle of, I've got to keep it down. I've got to delete things. I've got to categorize things. And Google had this different approach of, don't worry about it. Just leave it. And that's a good, I think, example as well of kind of that emotional response of, Nesrine (17:48) Yes. Brian Milner (17:56) Gosh, I'm kind of anxious. I feel bad that my inbox is so big. And I know that's bad, but Google comes along and says, don't worry about it. You're not bad. It's OK. Yeah. Nesrine (18:05) Yeah, yeah. And by the way, I think Gmail is filled with plenty of deep delight features. One of them I can quickly highlight is, you know, when you send an email, we're saying attached file and the file is not there. And when you try to hit send, you get that pop up like a be careful or like a mind, there is no attached file inside. These are for me like very attached to the fact that You don't want to feel ashamed. You don't want to look stupid later on saying, Hey, sorry, I forgot the file. Here's the file. That's, that's a great example. And the other example that come to mind again in Gmail, you know, that smart compose when you're trying to answer an email and you can just hit tab, tab, tab to complete the sentence. I mean, the functional need is to write an email. The emotional need is to get it in a relaxed way. And the combination would allow for something like. Brian Milner (18:49) Yeah. Nesrine (19:00) Smart Compose. Brian Milner (19:01) That's awesome. Yeah, so I guess that leads to the question though, when we're talking about something like Spotify, mean, music intrinsically is emotional anyway, right? It's something that you have an emotional connection to and you feel a certain way when you hear music. But if my product is a, I don't know, expense reporting software, right? Nesrine (19:23) Mm-hmm. Brian Milner (19:25) I can just hear people out there kind of asking, know, and kind of thinking to themselves, yeah, but my product, right, my product is not that kind of, it doesn't elicit that kind of emotional response in people the same way music would. So does this apply to me as well? So how would you answer those people who feel like my products might be a little bit more bland or boring and don't really intrinsically have an emotional connection to them? Nesrine (19:47) Mm-hmm. So my answer is that if your product is boring, then it's even more priority now to focus on emotional connection. But let me elaborate. So that's one of the reflections that came to my mind while writing the book. So while writing the book, I wanted the book to be a storytelling book. So I was writing a lot of my stories, stories from Skype at the time, Spotify and all the Google product. But at some point I said, hey, hey, Nisreen, you need to get more insight from other people and other experiences. So I get to interview product leaders from completely different industries and completely different domain. I interviewed leaders from B2B like Atlassian or Intuit and so many other companies that I don't have so much insight from. I even interviewed people from hardware, like I interviewed someone from Dyson and I was, hey, what makes Dyson so emotionally attractive for me? Cause I love my Dyson vacuum cleaner. But let me get to your point because when I interviewed someone from Intuit, that person told me something super interesting. She told me that at some point she was working at a tool called Tsheet. And Tsheet is a tool that allows you to enter your time report. There is nothing more boring than that. I think I'm picking the one that you're looking for here because it's, it's as a user. The only reason I would use this tool is to report my time so I can get paid. Brian Milner (21:06) Hmm. Right. Yeah. Nesrine (21:19) There is nothing exciting, nothing emotional. And what I got out of that product leader who used to be the head of product at the time, she told me that they were completely aware about the fact that the product is not that attractive. And instead of living with that observation, they did all what they could do to make it even more attractive. So they added some fun. They made the messaging less aggressive and less about enter your time. report but rather into more playful and even the images are more playful. When you press the enter time report you get the congratulation and some confetti if needed. So they explicitly turned and that's a strategy. They turned that boring moment into something even more attractive and they had to do that otherwise the experience will keep on becoming more more boring and the perception of users toward the product will be even less, more and more gray, I would say. Brian Milner (22:22) Yeah, yeah, just that little dopamine kind of kick, right? Just that little bit of chemical reaction in your brain can make a huge difference. That's awesome. That's a great story and a great answer to that question. So I'm curious, we're talking about trying to find these things and trying to see, your matrix here, it thinks about the emotional motivators, the functional motivators, and trying to find those things that kind of cross both planes. Nesrine (22:24) Yep. Brian Milner (22:52) How do you verify at the end? Because if you're lining your features up and think, I think this solves this emotional thing. I think this solves this functional thing. Is there a way to follow up to ensure that it actually is doing that? How do you follow up to make sure it's really doing what you thought it would do? Nesrine (23:09) Yes, so let's imagine you did the exercise well, you filled in the delight grade and you observed that you do have plenty of low delights, which is most of the cases by the way. The very first thing I recommend is to see opportunities for moving or transforming these features into deep delight. And in the book, for example, I talk about the nine delighters. Nine delighters are ways that could be sometimes cheap even to introduce. in order to make those low delight features into more deep delight. This could be, for example, through personalization. We love when the features are personalized, and that's one of the reasons, for example, why Spotify is so successful, is through features like Discover Weekly or RAPT or these kinds of super personalization related features. It could be through seasonality. That's, for me, the cheapest and the most delightful feature you can or aspect of feature you can add to your product. So for example, when I worked at Google Meet, I've been working at the background replace features. So we have been, of course, introducing static image. We have been introducing video backgrounds as well. But from time to time, we always use seasonality to introduce what we call seasonal background. So when it's Easter, we introduce Easter background. When it's Christmas, we introduce Christmas background. Guess what? Even like for Olympic game, we introduce Olympic game background. When it's the Earth Day, we introduced Earth Day background. So there is always an opportunity to introduce some seasonality to the product. And guess what? We relate to those, especially if the product is global. We relate like last, when was it? Like last Wednesday. It was the new year, the Chinese new year. And I was checking when is exactly the exact date for the new year, the Chinese new day. And I put that and you know what happened in Chrome? It got these dragons and those like the celebration within the product, like within Chrome. These of course are surface delight, but you know what? Why not? You see? So there are some tools. Some of them are not that... Brian Milner (25:17) Right. Nesrine (25:22) expensive to introduce to the product. Some would require a bit more thoughtful and thought into it, but there are ways that I detail in the book in order to introduce more delight. And then if you want to validate through metrics, and I guess that's your question where it's heading to, then the good news, and that's something that I discovered recently because there's been a study that was conducted by McKinsey. And you know what they studied? They studied the impact of emotional connection on product adoption. So they actually studied over, I don't know how many industries die, like tourism, IT, energy, whatever. And they interviewed more than 100,000 users or whatever. So the conclusion that they found out of that very interesting study is that emotionally connected users will get you more twice as more revenue, twice as more referral, and twice as more retention compared to satisfied users. I'm not talking about the non-satisfied. So if you take two groups of users, those that you satisfy their needs and those that you go beyond and they are emotionally connected, those that are emotionally connected get you twice revenue, referral and retention. Brian Milner (26:19) Hmm. Nesrine (26:43) So this is just to highlight that for people who say, no, but this is the cherry on the top. This is just like the extra. It's not the extra, it's the way to stand out. I don't know any company that is standing out nowadays without investing into emotional connection, none. Brian Milner (26:54) Yeah. That's a really good point. Yeah, I mean, the example that comes to my mind when you talked about seasonality and other things like that, know, I love my, you know, they're not a sponsor, Oral-B toothbrush, you know, the electronic toothbrush, and you know, there's an app with it and it keeps track of, you know, did you get all the areas of your teeth and did you hold it there long enough and... One of the things I always love about it is when it gets to December, the opening screen when you open up the app starts having snowfall. It's kind of a funny little emotional response, but you look at that and you think, that's cool. Yeah, it is kind of that season where now it's time to get ready for Christmas and it's that special. It's only this month that it's going to be like that. It's going to go away at the end of the month. Nesrine (27:45) Yes. Brian Milner (27:49) feel little sad when it's gone, it's back to normal. But it's such a silly little thing. Does that make any difference in really brushing my teeth at all? Does it change how well I brush my Not really. It's just a fun little thing that when it pops up there. And think how little that took from someone to do that. It's a little animation that they just pop up on a loading screen. But that little tiny bit, think, again, maybe a little bit surface. Nesrine (28:10) Yes. Brian Milner (28:16) but it takes something that would have been routine. It takes something that would have been kind of boring otherwise, and it just added a little bit of fun to it, you know? And I think you're right, that emotional connection is really, really important in situations like that, yeah. Nesrine (28:21) Yes. Yes. Yes, yeah. And the thing that I'm very vocal about nowadays is the fact that this emotional connection is actually not a new topic. It's something that has been extremely popular among marketers. For example, if you think about the best marketing campaign, they are all very emotional. The most successful marketing campaign are. If you think about designers, there are plenty of resources about emotional design. There is a great book by Don Norman. It was called emotional design. Aaron Walter as well wrote something called Designing for Emotion. But you know, the problem is that among engineers and among product manager, we don't talk that much about that. And you know what happened when we are not informed about this topic? There is a gap between the language of marketers, designers, and the engineers and product manager. And that gap doesn't allow things to succeed. I'm trying to educate the engineers and the product world towards this well-known domain outside of the product in order to have this consistency and start making real impactful products. Brian Milner (29:40) Yeah, yeah, this is such a really deep topic and it just encourages me, think, even more to recommend the book there. It's not out yet, time of this recording it's not out, but it's going to be in May of 2025. That's when this book is coming out. And I know it's gonna have a lot of really good information in it. Again, the book is gonna be called Product Delight. by Nesrine Changuel, Dr. Nesrine Changuel. I should make sure I say that. But I really appreciate you coming on because this is fascinating stuff. And I think the product managers, the product owners that are listening here are going to find this really fascinating. So I appreciate you sharing your time and your insights with us, Nesrine. Nesrine (30:26) Thank you, it's my pleasure. I love talking about this topic. Brian Milner (30:29) Ha

Retrospectives shouldn’t suck the energy out of your team—or get skipped entirely. In this episode, Brian and Cort share how to fix the most common retro fails and announce two brand-new tools to help you run retros that actually work. Overview In this episode of the Agile Mentors Podcast, Brian Milner and Cort Sharp break down why retrospectives are more than just a “Scrum box to check.” They’re the powerhouse behind continuous team improvement. From battling retro fatigue and quiet-room energy to creating psychologically safe environments and tying retrospectives to real results, they cover it all. Plus, Brian reveals the launch of two new on-demand courses—Better Retrospectives and The Retrospectives Repair Guide—designed to help teams stop skipping and start optimizing their retros. Whether you're a Scrum Master, coach, or facilitator, this episode is your practical guide to making retrospectives worth everyone’s time again. References and resources mentioned in the show: Cort Sharp Blog: Retrospectives With a Quiet Team Blog: Does a Scrum Team Need a Retrospective Every Sprint Mike Cohn’s Better User Stories Course Scrum Repair Guide Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at [email protected] This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years. Auto-generated Transcript: Brian Milner (00:00) Welcome in Agile Mentors. Welcome back for another episode of Agile Mentors podcast. I'm with you as always, Brian Milner, but today we're gonna have a continuation of something we tried, a little experiment we tried a few weeks back here. I've got Mr. Court Sharp back with us. Welcome back in court. Cort Sharp (00:18) Hey, Brian, thanks for having me on again. I had lot of fun last time I was on here and it was a great discussion. So thanks for bringing me back. Brian Milner (00:21) Yeah. Yeah, it's, oh, absolutely. Yeah, know, got a lot of people said, hey, we kind of like that court guy. Kind of like hearing from court. So we wanted to have court back, you know, because you guys told us that you liked him. And we also wanted to have him back because we just thought this format kind of worked for various reasons. And last time we kind of hit on some things that were kind of more hot button issues of the day. things that have been flowing through social media or other things around Agile. But we wanted to have a little bit more of a focus for today's episode. And we're going to focus really on the topic of retrospectives. And maybe make a little announcement here along the way as we go along. But we're actually going to switch roles here a little bit. I'm going to kind of pass the ball over to Court. And I'm going let Court drive this, just like he did in the last episode. Ball's in your court. Ha ha, get it? Cort Sharp (01:18) Ha ha, court, there you go. Well thanks, Brian. Once again, I love coming on here, I love chatting with you. And like you said, yeah, we're gonna be talking about retrospectives today, mostly because I have been struggling with answering questions about retrospectives. I think this is one of the more common meetings within Scrum that just gets skipped over, just people don't find value in it. Brian Milner (01:42) Yeah. Cort Sharp (01:43) or people just struggle with understanding why we have retrospectives. And sometimes I get a little slipped up and I struggle with answering the questions about why do we do this? So can you give me some clarification? Why do we have retrospectives? Why do they matter? Brian Milner (01:58) Yeah. Yeah. I mean, it's a great question. And I think everyone should, should, you know, want to know that answer. If you're doing this, you one of things I say in class all the time is, you know, it's important to know the purpose behind the meetings that we have in scrum. If you don't know the purpose, then, you know, that, how are we gonna, how are we gonna have a successful meeting? How are we gonna get the most out of it? so yeah, it's, it's a funny kind of meeting, because all the other meetings and scrum are, are really, around one ultimate purpose and that's building the increment. This is not, right? This is sort of a timeout. It's an intentional kind of timeout to step away and say, all right, now that we've done that, how did it go? What kind of happened along the way? I think it's a vitally important meeting. And when I hear people sometimes say, is it okay to skip it or should we do it once ever so often? you know, again, I try to be pragmatic and say, you know, I don't, I don't know any possible situation out there, but, you know, I would tell you, I would advise you not to, I don't think that's the right path to go. I know scrum doesn't teach to do that. I think it's really, really important because it is that, that moment of let's pause for a little bit. Let's figure out what we need to do differently and then let's actually take a step to do it. There's actually an interesting little background for this. So I'm going to take a little side trip here. Retrospectives actually come from an idea that has been around for a while that actually started kind of in lean manufacturing, some of the things that came out of Japan. There was actually a phrase that they would use on the assembly line at the auto assembly plants there in Japan. They referred to this concept of Kaizen. Kaizen was kind of a, I don't speak Japanese, but what I understand is the word loosely kind of translates to good change. And they had this concept there on the assembly line floor that anyone who was on the floor had access to the big red button that could stop the entire thing. They could stop the entire assembly line, which you know, on an auto assembly plant, that's a huge deal to stop the entire production. And they were very deliberate about it and said, no, we want everyone to have access to that because the phrase they use was the Kaizen comes first. And what they instructed the employees was if you along the way, as you're doing your job, if you see something that we could change that would make it more efficient, that would be a better way of doing this, then we want you to hit the red button because we want to implement whatever that change is as soon as possible. The sooner we implement the change, the longer we have as a benefit, like an investment. The earlier I invest, the more I get as a return. So the same thing here, the earlier I invest in this good change, the longer I have to have a return from it. So that phrase, the Kaizen comes first, is sort of a central thing that we think about here with retrospectives. It's identifying those good changes. there's actually even an intention behind it that it doesn't go on the product backlog. It goes in the next sprint backlog. Because we don't want to have any even inkling of deprioritizing something that comes out of a retrospective. It's that Kaizen portion. So we want to make sure that comes first. So yeah, it absolutely is going to go into the next sprint. Whatever we decide is the most important thing, we're going to make an impact on it in the next sprint. So that's why I think that it's the most important thing for us is it's the engine that really drives continual improvement. And without it, I think teams stagnate. I think they just get kind of stuck in a rut. problems that we have, we just continually repeat. if we don't have the time to stop an exam. Cort Sharp (06:00) Yeah. All right. So I kind of got one bigger idea from there. And for whatever reason, when you were like, we gave everyone the red button to stop the assembly line. And that's kind of, we're stopping, we're pausing, we're inspecting, and then we're going to come up with a plan to adapt. Whatever reason, this phrase stuck in my head, it just popped out to me. But it sounds like we're giving power to the people. Brian Milner (06:06) Okay. Cort Sharp (06:26) where we're, you know, the team has the power, the people have the power to say, whoa, let's stop here. Let's hang on a second. Let's take some time and let's figure out a better way to move forward. And from that, I just think of sports. I think of sports teams. We're in the middle of March Madness as we're recording this right now. And I can pretty much guarantee you that every single one of those teams who's advancing on past, I think round one is going on right now, so passing on through round one, they're probably watching some film on their opponents. They're trying to see, what are they gonna do? What are some plays? How can we kind of counteract it? But more often than not, I would wager, I'm not a gambling man, but I'd wager, that they're looking at their own film and they're trying to see what did we do well in this game that got us the win? What can we improve? so that we could maybe have a little bit more of a bigger margin of victory. And what is it that we should probably stop doing? What is there that wasn't working out? Maybe our pick and rolls were not good, maybe we weren't executing well on those, or not to get too into basketball terms there, but maybe we should stop shooting so many threes or something like that. I don't know, right? But yeah, that's, yeah. Brian Milner (07:42) I think you're right. I think you're absolutely right that, you know, sometimes we think this retrospective thing is maybe, is this just a weird thing that we do in software development? No, this happens in a lot of professions. There's a lot of different professions out there that take time to analyze. And by the way, I'll throw this out there as well, because you mentioned kind of sports. Sometimes people will, I've encountered teams at times that think, You know what, we're good enough. We don't need to do this anymore. This is really only for teams when they're starting. We don't need to have retrospectives once we've become mature. Well, to them, I'd say, well, then why do championship teams continue to watch their film? Right? If a team won the Super Bowl last year, don't you think that they still go through training camp and get ready for the season? Yeah, they absolutely do. But they're on top of their game. So if they think it's necessary when they're on top of their game, is there really a moment that we would be so on top of our game that we have nothing left to learn and get better at? I'd say no. I think that there's always something that we can get better at. And I think that's a great analogy to kind of drive that home. Cort Sharp (08:54) Yeah, awesome. I totally agree with you there. Even just outside of the team sports world, I come from a more individual sport background. And it's so important to take some time and just reflect on, how did I perform? How was my performance, even on an individual level, so that I can take some action steps throughout this next period of training or work or whatever it is that I'm doing so that I can make the next next performance or the next time I race or the next time I get out there on the court or on the field or whatever. That's how I can make that next time better than this last time. So awesome. Thanks for clarifying. Thanks for. Brian Milner (09:28) Yeah. Well, yeah, yeah, no, no, it's a great question. I think this is, probably time for us to kind of let the cat out of the bag here a little bit and just say, one of the reasons we wanted to focus on it for the episode is, drum roll, we kind of have a couple of courses coming out. here that we're going to offer at Mountain Goat Software that you can take around retrospectives. They're on demand videos that I worked on. They're two different separate courses. And we just thought this was an area that really needed some focus and attention and we were getting lots of questions around it. So we always try to listen to what you guys are telling us. And what we were hearing was, this is where you wanted us to focus. yeah, not a lot of details that I'm going to say right out of the gate. But yeah, we do want to kind of announce that those are coming here very, very soon. Cort Sharp (10:22) Yeah, so if I heard you right, I think you said this, but there's two courses coming out, right? Okay, cool. We're letting that out of the bag. Brian Milner (10:28) That's correct, yeah, two. right, right. I mean, you might think, one course I can understand, but two? Yeah, there's so much material that there was too much for one. And people could not consume all that in one go. And so we created two and kind of found different aims, different goals for both of them. to target what people were really asking for. So yeah, there are two separate courses. One that's going to be called Better Retrospectives, and another one that's called Retrospectives Repair Guide. So yeah, you can sell just from the names, kind of taking two different approaches here on focusing on retros. Cort Sharp (11:07) That's so awesome to hear that we have two separate types of courses that solve kind of two problems. So what were the reasons why you decided or Mountain Goat decided, hey, we probably need to make these to help solve some pain points. What were those pain points and what are these common struggles that you're seeing? Brian Milner (11:19) Yeah. Yeah, completely fair question, right? I mean, why didn't we do one on sprint planning? Or why didn't we do one on daily scrums or whatever, right? Well, maybe we will in the future. I think the kind of genesis of this idea or why we decided to focus on it was we periodically survey users. We watch what people do when they come to the site, what they search for. And one of our top search terms and one of the top search areas that we've seen over the years, really, it's been consistent, is around retrospectives. So we know that's an area people want to know more about and want to get help with. So that gave us the first little inkling that this might be something to focus on. That led us to doing just a free open webinar that we did. I hosted that, I put together a presentation to give some tips around it and help people, just a short little presentation, but wanted to just give some really quick tips people could apply. And we had over a thousand people sign up for that. not, I shouldn't say that. We had over a thousand people attend that. just, lots of people sign up and don't come, but. We had over thousand people who showed up and attended to hear that. And that kind of blew us away. think, wow, this is really, know, people made time in their day to come and listen to this, you know, short little webinar on it. There's interest here. And with a thousand people, we didn't have nearly enough time there on that webinar to answer everyone's questions and get through everything that was coming at us. But, you know, we love data. So. We pulled all that data from all the questions that had been submitted and people had presented to us and grouped them, categorized them, tried to sort them through and try to find what's the biggest kind of pressure, pain points that people are having that they wanna know answers to. And that's what led us to really create these courses is there were reoccurring themes, right? There was a kind of set of things that are common amongst people. common issues, common problems that people are having, common root causes of those problems. And we just thought, this is doable. It's not an impossible thing to fix. There are actually practical, real ways of solving these things. And we wanted to give people solutions to the things they wanted to hear about. So that's why we decided to focus on retrospectives. Cort Sharp (13:50) Awesome, sweet. That's still crazy to hear. I knew that you had a thousand people or a little over a thousand people attend that live stream, I think is what you did, right? Because it was like a YouTube live stream or something like that. That's still mind blowing to me that there was that much turnout and... Brian Milner (14:09) Actually, I just wanna say, I don't know that it actually even was on YouTube. That's what makes it even more kind of impressive to me is people had to like get a link and go into it. So it wasn't just, hey, I'm flipping through YouTube on my lunch break and it turned up. It was people who deliberately said, no, I'm making an appointment to go to that. Yeah. Cort Sharp (14:29) Man, that's even, yeah, that's crazier to me too. That's awesome. That tells me, yeah, there's a ton of demand for this, right? So can you give me just a brief overview without oversharing or sharing a little too much about what each course kind of offers and what problems they're working to solve or we're solving within each course? Brian Milner (14:31) Yeah. Sure. Yeah, I guess it's probably important to know the strategy of both of them and why there's two. As I said, there's just a lot of material, so it was too much to fit into one. But I tried to follow the pattern in creating these that we've established at Mountain Goat with previous classes. So the first one that I put together, we titled Better Retrospectives. And that's following the pattern that we've done with other things like better user stories. So better retrospectives, the focus is sort of the expert deep dive on retrospectives. We go deep on the meaning behind things and kind of facilitation techniques that are useful to do, patterns you can use in creating a retrospective, ways you can create brand new. themes for your retrospective that no one's ever done before in the past because it's yours. It's something you created on your own. And just kind of all the ins and outs of how to really make a retrospective work and be productive, produce things that actually make differences on your team. So that was better retrospectives. But we wanted to then address head on those most common questions that people have. Again, try to follow the pattern that we've established with some previous things here at Mountain Goat. Mike has a course that I took years ago called Scrum Repair Guide. And it was about the most common problems that Scrum teams have. so I follow that pattern here. And the second course is called Retrospective's Repair Guide. And what we did was we took those highest volume asked questions, the most common questions we got from that webinar. got just the top 10 and said, these are the biggies. These are the big ones that people are asking about that really want to know the answer to. And we put together a repair guide course for it so that people can maybe consume that in a little bit different way. If I'm having one big problem right now and I need an answer to that, or maybe I have two or three problems, I'm not having all the problems, but I need an answer. I need help with this big thing that's going on with my team. We wanted to get that to them as soon as possible. So the retrospective repair guide is that ability for someone to look at our list of top 10 questions. And you'll probably find three or four of them on there that you'd say, oh, yeah, that's one I've experienced. Yeah, that's one we're having right now. And then you can just kind of to the chase and get right to where it is that you need to get help. And then practically go and make those changes immediately. So better retrospectives. The expert course, Deep Dive on Retrospectives, makes you an expert at delivering them and working with them. Retrospectives Repair Guide, more for those finding the solutions to the problems you're having right now. Cort Sharp (17:37) Awesome. I want to kind of double click a little bit into the retrospective repair guide. Man, tongue twister, right? The retro repair guide. Can you share just like one or two, maybe three of those questions that are answered or some of those bigger questions that were asked that are answered and that you give a solution to and a very clear solution to within that course? Brian Milner (17:43) Yeah, it is a little. Yeah. Yeah. Yeah, absolutely. just know for each one of these, it's not a, the answer is, here's a sentence. Each one of these, we go really deep on how to answer that and strategies. And I give you multiple things that you can do. Because a lot of these maybe even have multiple root causes to them that could be causing them. And there could be something different you might need to do to solve that for your team. But you know, Like one of the biggest questions that we heard, probably the most popular question that we got was, how do you handle retrospectives when you have a quiet team? When you have a team of people that are a little more introverted or shy, not uncommon with a group of software developers. So how do you get them a little bit out of their shell or how do you get them to just feel safe enough there to actually contribute? That was a big one. Um, you know, a big one for our, our day and age is how do you handle retrospectives when you have people that are remote? Uh, you know, do you have an entirely remote team? Do you have people that are, uh, you know, parked your team? Part of your team is, is in-house part of your team is remote. Uh, how do you, how do you handle that split? Um, that was another big one. Um, you know, how do you handle it when you're, you have a team that just hates retrospectives? Um, you know, how do you, how do you, uh, How do you get your team to start really making progress, real progress, from the things that you talk about in your retrospectives? So these are just a couple of them. we really thought that these, for each one of them, as I went through each one of them, I thought, yeah, this is a big one. This is one I get questions about all the time in class. So there was none of them that I looked at and thought, this is a filler. Am I going to make it to 10? No, mean, it was hard to limit it to 10, you know? But yeah, we limited it to 10 and all of them are really, really important ones. Cort Sharp (19:47) You Yeah, nothing but heavy hitters here. Nothing but bangers. Here you go. Yeah, that's it. Awesome. OK, well, thanks for the overview. Thanks for introducing these courses. That last question there, what do I do? How do I manage a team within my retrospectives when they hate going to retrospectives or despise that? That'd be super useful for me. Man, I might buy this course right now. Brian Milner (19:55) Yeah, yeah. Yeah. Ha Yeah. Cort Sharp (20:23) But I would like to, we strive to have some pragmatic approaches. We strive to provide practical, immediately useful tips on this podcast. I know that's a big point for this podcast that you really work on and you really focus on. Do you have any just practical, immediately useful tips? Let's start out, I guess. This might be a little teaser, a little preview. You might repeat something that you gave out into the Retro's course there, the Retro Repair Guide. With quiet teams, can you just share something that I can immediately take away and go off if I have a really quiet team and it's like pulling teeth to get them to talk and participate in Retro's? Can you give me just some useful tips or something that I can go away with? Brian Milner (21:08) Yeah. Cort Sharp (21:13) after listening to this episode and go off and use with my team to help my quiet team be a little more active and a little more beneficial. Show them that, this retro is for you. What can I do to work with my quiet team here? Brian Milner (21:29) Yeah, yeah, no, mean, how can I tease the number one thing without giving any kind of advice on it, right? And no, I mean, we're doing this because we want to get this information out route. We want to help teams to be successful with this. So no, I don't mind at all going into some things that might help there on it. There'll be much more in the course because I just have more time to do that. I think that the number one thing when you have a quiet team is trying to understand the why behind it. So for starters, I think it's important for us to understand that there are different personality types. I mentioned things like introvertedness. There are people who are more introverted than others. And if that's a of a spectrum in itself. There are people who are extremely introverted, and there's people who are only mildly introverted. Not to mention, one of my favorite topics, thinking about kind of different neurodivergent traits and how they interact and participate and things of that nature. So all that's to say, that I think the number one thing that we have to do is know our team. We have to understand who is in the room. Because I think we make the mistake a lot of the times of, I'm gonna just put together a retrospective. Let me go find out what that guy on YouTube said about doing a retrospective. yeah, that was a fun little theme that he came up with. Let me go put that in place. But that may not match at all. the personality of your team. It may not match the way that they prefer to interact. If I have a team full of introverts, I'm not gonna do a big role play kind of exercise in my retrospectives, because everyone's gonna be uncomfortable and everyone's gonna shut down. They're gonna go into defensive kind of stance, right? So I think that's the number one thing I'd say is, first of all, just understand and respect. respect the differences there in personalities to understand that they're not broken or in need of repair in any way. If they are quieter, that's just who they are. That's just how they're made. So I think that's part of it, right? I think part is that you have to understand your team. But there are other possible root causes here as well. One of the biggest is they could be quiet because they don't feel safe to actually speak in that room. That's a huge one, right? And it's so important. If they come into that room and they are fearful that what they say in that room is going to be reported outside the room to someone else, or they're going to be made fun of in that room for voicing their opinion or belittled in some way for it, well, That's a killer to a retrospective. If there's not that sense of safety in the room, doesn't matter how brilliant your pattern is for the retrospective or what great idea you came up with for it. If I don't feel like this is a safe space where I can speak up and not be made fun of or not fear retribution for something I've said, I'm not gonna speak up. whether I'm an extrovert or an introvert. It doesn't really matter my personality type at that point because the fear is what's driving everyone in that room. So I think you have to maybe even gauge the team. Maybe even ask them in an anonymous poll. I've done this before by just giving slips of paper and everyone puts in a hat. And you can do something like a safety check where you say, give me a number from one to five. five being the highest and one being the lowest, how safe do you feel today in this room to speak honestly without fear of retribution or being made fun of, that sort of thing? And it could very much surprise you what the answer is. That's actually an activity that I repeat periodically when I have a team because I want to chart it. I want to see where they are now. I want to see if it goes up or down. If there's some kind of a change, how does that affect it? We had, we lost a team member or two team members and we had new people come on. Safety is going to drop because we have new people. God forbid if we have somebody who's an outsider who insists on coming into it. I try my best to keep them out, but hey, if my boss says, well, I'm overruling you, I'm coming in. Well, are you gonna quit immediately because that happens? Probably not. What can you do? Make it transparent, the effect. You can say, hey, we periodically take these safety checks. So here today, I took another safety check. Our normal average is 4.2. Today, it dropped to 2.1. Why do you think that happened? It's data. So I think safety is another big reason. Cort Sharp (26:13) Right. Right. Brian Milner (26:18) So let's, personality type, gotta understand personality type, gotta make sure the environment's safe. And by the way, kind of corollary to that is not only that it's safe, but that their opinion matters. So if they speak up and say things and no one pays attention to them, no one listens to them, well again, you're telling them your idea doesn't matter, learn this lesson, next time don't speak up, right? Cort Sharp (26:30) Mm-hmm. Brian Milner (26:44) So they've got to have a safe space. And then I think you've got to match your activities to your team. You've got to find ways of connecting to them that will feel comfortable for them, that make them feel. I say this all the time in classes, facilitation, the root word in facilitation is facilis. It's a Latin word. means to make easy. So we're facilitating a retrospective. Make it easy. If your team doesn't want to role play, and you've got an activity that's a role play thing, then that's not easy. That's difficult for who they are. But if your team, another kind of difference, are they verbal processors? Do they need to talk things out to find a solution? Or do they need quiet space? that they need introspective time to find solutions. If that's the case, well, maybe I start with something like quiet writing. I don't even have an activity where they're talking to each other at the beginning. So I think that's third thing I'd throw out there is to say, Once you know your team, make sure you are matching the format, matching what you come up with for that retrospective to the personality of your team. It's hard, right? Someone can't walk in off the street and deliver a great retrospective to a team they don't know. But the good news is you know your team, right? You work with them all the time. You're the expert on this. Cort Sharp (28:08) you Yeah, yeah, as a more introverted person, nothing sounds worse to me than trying to, to do any kind of role playing, putting myself in some position that I just don't normally put myself into and I'm not comfortable with right that that is not my jam. That is not my thing. Brian Milner (28:27) Yeah. Yeah, and can you blame it when, if that happens, can you blame the team for saying they hate the retrospectives and that they don't want to do them anymore? Yeah. Cort Sharp (28:39) No, not at all. Not at all. If my scrum master came to me and said, right, we're going to, Brian, you're acting as this person, Court, you're acting as this, and we're going to reenact little Romeo and Juliet, bring that into there in this. And it's like, what? No, this isn't valuable. Brian Milner (28:47) You Right. Yeah, it's one thing to say, we're going to pretend to be each other and talk through. But it's another thing to say, pretend you are a peanut. you're like, that kind of thing. When you're an employee, you're like, god, really? I have to be a peanut now? Great, great. Yeah, no, this is fun. It's that kind of thing that if you don't, maybe your team would enjoy that kind of thing. If so, then match it to them. Cort Sharp (29:10) Yeah. Yeah. Brian Milner (29:19) They're not in that mode. No, no, no, no, no, no. Cort Sharp (29:23) Yep. Well, awesome. think I have a couple more questions for you here. Should be relatively quickly, right? Thanks for giving a little preview and giving some practical advice for what we can do to help our more quiet teams. But I want to take a step back. I know we double clicked into that one course, but I just want to take a step back a little bit. how do I decide which courses is right for me? Brian Milner (29:28) Yeah, yeah. Yeah. Cort Sharp (29:48) Do you have any guidelines for that? Any advice for if I'm interested in both courses, but I don't know which one would be a little more beneficial for me? How do I make that choice? Brian Milner (29:58) Yeah, that would be an extremely difficult decision to make because you have to really know these courses intimately, think, to make that, or maybe not intimately, but you probably have to dive a little bit deeper into what the agenda is for each one to kind of know the answer. But here's the good thing. When we're launching these, I can tell you this as well. We're going to be launching it as sort of a two for one. So. The good news is when we, know, for the initial launch of this, that's going to be the bonus for being in the first group is you don't have to decide. You'll get them both and you can then, you know, choose on your own. can dip in and see, you know, if one's better for you than the other, great. But you can consume it any way you want. And, you know, I'm just really excited for people to get to see the stuff and to hear it. I think there's some. there's some stuff that's really gonna help people in it. Cort Sharp (30:47) Awesome, great. Helping my decision fatigue there, Brian. That's great. Wonderful. One less choice that I have to make. Well, great. Awesome. That's kind all the questions that I have for you. Are there any kind of key takeaways or anything that you want to single out about retrospectives as a whole or anything about these courses that are going to be offered here anytime soon or anything like that? Brian Milner (30:50) Yeah, exactly. Exactly. Yeah, I wanted to do this kind of an episode about this because, you know, I feel like the listeners here to our podcast, you guys know me, you know, the kind of stuff that I talk about. And, you know, I wanted you to be the ones who kind of heard this and knew about it first. I think it's going to be really beneficial and it's going to really kind of turbo charge a lot of teams. We talked about why retrospectives are important. Well, as I said, it's the engine for that continual improvement. If you don't have it, then the team stagnates. If you do have it and they buy in and this is, they're really all in on that Kaizen continual. improvement, know, Kaizen comes first mindset that kind of comes along with it. Then they look forward to this meeting. It's not just, know, something to check the box at the very end of our sprint, but it's actually, you know, when are we going to have that retrospective? I've got some stuff I want to talk about and that's our time now. You know, we can shut out the rest of the world. We can shut out, you know, everyone who's not here in our team. And now we can focus on us. You know, the question I often ask the teams when I do this is, do retrospectives is, what would it take for us to be the team everyone else wishes they were on? And, you know, that's really what you can accomplish through a retrospective is you can be that team, everyone else in the group and the organization looks at and goes, man, I wish I was on that team. That team's the, that team looks like a great team to be on. You know, I know there's, we're not given a lot of details here because this isn't We're not opening sales to this at the time that you hear this, when this podcast comes out. This is just a preview. I wanted to announce it here in the podcast first and let you guys know about it. Stay tuned. We're gonna have some stuff coming out soon. You can come to our website, mountaingoatsoftware.com and you'll find more information about this. But stay tuned here to the podcast as well. We're going to talk about some other things around podcasts in the next few weeks. we'll let you know when it's going to be open. I'll tell you as well, this is going to be a limited time thing. It's not something that we're launching and then kind of keeping open forever. This is something that we're going to launch. And there's a window for you to actually purchase this. receive both these at the same time. We'll talk about pricing and all that other stuff later down the road. But I just wanted you guys to know that these two things were coming. And hopefully, that gets you excited. And you can start now saying, hey, boss, there's something I'm going to be asking you for here for the training budget or something somewhere along the way. So stay tuned. We'll have more information here about it in the coming weeks. Cort Sharp (33:51) Yeah So we're starting the hype train now. Hype train is starting to pull out of the station. And the next station it comes into, it's only going to be there for a limited time. So make sure you get on board and get on with this. Because these sound like really awesome classes. And they sound like a really great way to either elevate where you're at already or where I'm at already for retrospectives and whatever techniques I'm using. I know we didn't talk much or really at all. Brian Milner (34:01) Yeah, exactly. Cort Sharp (34:26) other than the title of the Better Retrospectives course. But having been through the Better User Stories course, that really elevated my ability to write and facilitate user story work or story writing workshops. But it allowed me to be more effective on the user stories front. if it's anything following that trend line, which it sounds like it kind of is, that Better Retrospectives course sounds like a fantastic way to elevate. Brian Milner (34:46) Yeah. Cort Sharp (34:53) my ability to not only facilitate, but also just get more value out of retrospectives. And then the retro repair guide. Awesome starting point. Sounds like it's a great spot if I'm struggling with anything. Really, really common. Well, not really common. The biggest questions, biggest problems that are seen throughout retrospectives. Great starting point in order to. help myself grow and get up there. And the fact that I don't have to choose between the two, that's fantastic to me. makes me really excited. Brian Milner (35:25) Yeah. Bonus, right? Yeah. Well, and I do want to throw out there as well. know, the pattern here, I'm copying Mike, right? This is what Mike Kona has done previously. And I'm with you, Court. When I took the Better User Stories course, you know, I really wanted to go deep on user stories. I wanted to understand them at a level that I just didn't previously. And I wanted to know the ins and outs. I was ready to go deep on it. And I agree with you. did the same thing for me. It helped me to really fully understand kind of what this method is and how to get the most out of it. So that was my idea when I wanted to copy that into the retrospectives. I wanted the same thing. I wanted people who were at that point where they're ready to go deep. Here it is, right? It's ready for you. And retrospectives, the repair guide as well, I was a consumer of Mike's Scrum Repair Guide before I joined Mountain Goats, you know, when I was a Scrum Master on a team. And I remember when I saw that course and I saw the list of things that, you know, he was going to talk about in that course. There were two or three of them on that list that I just said, yeah, star that one, star this one, like that. I need that answer. I just remember that feeling of, I really need the answer to this. So my thought at that time was, whatever this is, It's worth it because I don't know how to do this on my team right now. We're having this problem and I need it fixed. So I need guidance on how to do this. And I know there's people out there that are gonna feel that way about some of these topics they're gonna see that we have in the repair guide. So all that's just to say, it's from the point of view of someone who benefited from that pattern, you know, from Mike and other courses. And I'm hopefully going to be able to do that for people here with retrospectives as well. Cort Sharp (37:15) Well, I'm excited. So a couple action points for anyone else who's interested in this. Stay tuned, right? Stay tuned for future episodes on the podcast. Keep an eye out on stuff. Can they visit mountainghostsoftware.com right now and sign up for a list or anything or get any pre-emails or anything like that or not quite yet? Brian Milner (37:33) I don't think there's anything that you can do at the moment. mean, if you're on our email list, I think that's probably the best thing you can do. You sign up for our email list. You can do that pretty easily at mountandgoatsoftware.com. And that'll keep you informed when we send out our newsletters. We're gonna have information on it there as well. But it's kind of like, you you get those emails sometimes that just say nothing right now, but, so nothing right now, but, you know, kind of just... File this away, know this is, you in the next few weeks, you're gonna hear more about this and then it'll be that limited window that you can actually, you know, take advantage of it. Cort Sharp (38:07) Awesome. Yeah, so keep listening in, keep an eye out, and we'll keep giving you some practical approaches, practical tips that you can use to go into your next retrospective. Maybe your team isn't the quiet team, but maybe they're the ones that just don't really like retros. know, Brian, thanks for helping me out with my quiet teams, or any time that I interact with quiet teams, and even the ones that are a little more just passive and don't. Brian Milner (38:28) Nah. Cort Sharp (38:34) don't really see the value in retros. Thanks for sharing those tips and for helping me out with all the teams that I work with. So I appreciate that. Thank you. Brian Milner (38:42) Yeah, absolutely. If you can't tell, I'm really excited about it. I can't wait for people to start diving into this stuff. more than anything, I can't wait for it to start to make a difference in teams. Cort Sharp (38:53) I'm excited, Brian. I can't wait. I'm stoked. Brian Milner (38:54) you