Podcasts about scrum masters

Shawn Dsouza: The Marathon Mindset—Building Agile Teams That Last Beyond Sprint Deadlines Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Shawn defines himself as a "people-first Scrum Master" who measures success not through metrics but through daily interactions and team growth. He contrasts two teams: one that hit deadlines but lacked collaboration (unsustainable success) versus another that struggled with deadlines but excelled in conversations and continuous improvement (sustainable growth). For Shawn, protecting deep work and fostering genuine team collaboration indicates true success. He emphasizes that product development is a marathon, not a sprint, and warns that lack of meaningful conversations will inevitably lead to team problems. In this segment, we refer to the book Clean Language by Sullivan and Rees.  Featured Retrospective Format for the Week: Sprint Awards Shawn champions the Sprint Awards retrospective format, moving beyond viewing retrospectives as just another Scrum event to recognizing them as critical team development opportunities. In this format, team members give awards to colleagues for various contributions during the sprint, with each award recipient explaining why they were chosen. Shawn prefers face-to-face, offline retrospectives and always starts with ice breakers to gauge how the team feels—whether they feel heard and connected. He believes in experimenting with different retrospective formats since no single approach works for every situation. Self-reflection Question: How do you balance achieving deliverable outcomes with building sustainable team relationships and collaboration patterns? [The Scrum Master Toolbox Podcast Recommends]

Shawn Dsouza: From AI Anxiety to AI Advantage: A Scrum Master's Experimental Approach Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Shawn faces the massive AI transformation currently reshaping the tech industry, acknowledging both its benefits and the fear it creates among professionals questioning their relevance. In his organization, he witnesses AI delivering wonders for some teams while others struggle and lose projects. Rather than viewing AI as an overwhelming wave, Shawn advocates for experimentation. He shares practical examples, like helping a Product Owner streamline story creation from Excel to JIRA using AI tools, and leveraging MIRO AI for team collaboration. His approach focuses on identifying friction points where AI experiments could add value while keeping conversations centered on possibilities rather than fears. Self-reflection Question: Instead of fearing technological changes like AI, how can you create small experiments to explore new possibilities and reduce friction in your current work processes? [The Scrum Master Toolbox Podcast Recommends]

Shawn Dsouza: The Database Migration Disaster— Why Software Development Teams Need Psychological Safety Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Shawn worked with a skilled team migrating a database from local to cloud-based systems, supported by a strong Product Owner. Despite surface-level success in ceremonies, he noticed the team avoided discussing difficult topics. After three months of seemingly smooth progress, they delivered to pre-production only to discover 140 critical issues. The root cause? Unspoken disagreements and tensions that festered beneath polite ceremony facades. The situation deteriorated to the point where a senior engineer quit, teaching Shawn that pausing to address underlying issues doesn't cost time—it builds sustainability. In this segment, we refer to the episodes with Mahesh Jade, a previous guest on the Scrum Master Toolbox podcast. Featured Book of the Week: The Advice Trap by Michael Bungay Stanier Shawn discovered this transformative book when he realized he was talking too much in team meetings despite wanting to add value. The Advice Trap revealed how his instinct to give advice, though well-intentioned, was actually self-defeating. The book taught him to stay curious longer and ask better questions rather than rushing to provide solutions. As Shawn puts it, "The minute you think you have the answer you stop listening"—a lesson that fundamentally changed his coaching approach and helped him become more effective with his teams. Self-reflection Question: When working with teams, do you find yourself jumping to advice-giving mode, or do you stay curious long enough to truly understand the underlying challenges? [The Scrum Master Toolbox Podcast Recommends]

Shawn Dsouza: When Scrum Masters Forget to Listen - A Team Trust Crisis in Agile Implementation Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Shawn shares a powerful lesson about the importance of listening before implementing. Working with a young, talented team drowning in firefighting, he rolled out Scrum in "full" without taking time to understand the team's context. Going through the motions of Scrum ceremonies without genuine team ownership led to dropping energy levels and lost trust. The turning point came when Shawn realized the team had lost faith in his approach, prompting him to rebuild the process collaboratively with team ownership at its core. This story highlights how good intentions can backfire when we prioritize frameworks over people. Self-reflection Question: Before implementing any new process or framework, how do you ensure you truly understand your team's current challenges and context rather than jumping straight to solutions? [The Scrum Master Toolbox Podcast Recommends]

Bernie Maloney: From Permission-Seeking to Forgiveness-Begging—Agile Team Evolution in Self-Management Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Bernie defines success for Scrum Masters as creating teams that can thrive and do their best work independently. His ultimate goal is to make himself unnecessary - developing self-directing teams that step out of waiting for direction and instead seek permission or even beg forgiveness when needed. Using the "Circles and Soup" framework, Bernie helps teams stretch their circles of influence and control. He recognizes that every manager wants teams to succeed but may lack the necessary tools, making it crucial for Scrum Masters to coach managers as well. Bernie recommends building a backlog of organizational impediments and focusing on the top priority that will move the ball forward most effectively. Featured Retrospective Format for the Week: Sailboat Bernie champions the Sailboat retrospective format for its simplicity and adaptability. While the basic format is straightforward, he appreciates that you can add layers of complexity as needed. Bernie tends to keep retrospectives simple and also mentions the "What the Duck?" technique as another valuable retrospective tool. He suggests incorporating creative elements like having people build LEGO representations of what they're discussing, which helps teams visualize and engage with concepts more effectively. To know more about LEGO Serious Play, check out the Serious Play book.  In this segment, we also refer to Dissociation in Psychology, which helps with "third position" coaching/thinking, and Bernie's video on creative retrospective formats.  Self-reflection Question: How are you measuring whether your teams are becoming more self-directing, and what specific behaviors indicate they're ready to operate with less guidance? [The Scrum Master Toolbox Podcast Recommends]

В этом выпуске моя гостья — Лаззат Байтерекова, скрам-мастер в компании Future Secure AI. Она рассказала, как после пяти месяцев безуспешных поисков и более тысячи откликов смогла получить оффер в США благодаря нетворкингу. Мы обсудили путь из QA в профессию скрам-мастера, роль бизнес-психологии в работе с командами, специфику американского рынка и нюансы прохождения интервью, включая общение с AI-рекрутерами. Лаззат поделилась стратегией поиска работы, важностью LinkedIn, силой поддерживающего окружения и тем, как решение не сдаваться стало переломным моментом на пути к новой карьере.Лаззат Байтерекова (Lazzat Bayterek) - Scrum Master at Future Secure AIhttps://www.linkedin.com/in/lazzat-bayterek-904959294/***Записывайтесь на карьерную консультацию (резюме, LinkedIn, карьерная стратегия, поиск работы в США): https://annanaumova.comКоучинг (синдром самозванца, прокрастинация, неуверенность в себе, страхи, лень) https://annanaumova.notion.site/3f6ea5ce89694c93afb1156df3c903abОнлайн курс "Идеальное резюме и поиск работы в США":https://go.mbastrategy.com/resumecoursemainГайд "Идеальное американское резюме":https://go.mbastrategy.com/usresumeГайд "Как оформить профиль в LinkedIn, чтобы рекрутеры не смогли пройти мимо": https://go.mbastrategy.com/linkedinguideМой Telegram-канал: https://t.me/prodcastUSAМой Instagram: https://www.instagram.com/prodcast.us/Prodcast в соцсетях и на всех подкаст платформахhttps://linktr.ee/prodcastUS⏰ Timecodes ⏰00:00 Начало4:02 Кто такой Scrum Master?7:58 Как и когда ты переехала в США?10:46 Статистика офферов. Сколько откликалась?16:10 Какие были твои первые действия?18:53 Как ты использовала LinkedIn для поиска работы?21:18 Трудности нетворкинга. Что сработало, что нет?28:32 Как выстраивала сеть знакомств?32:57 Как получила оффер?37:40 AI рекрутер - плюсы и минусы40:58 Вопросы на собеседовании к Скрам мастеру44:14 Как менялось твое резюме?51:57 Что еще ты делала, чтобы найти работу?58:04 Что было самым сложным в поиске работы?1:09:00 В чем твой секрет успеха?1:14:10 Какие 3 урока ты для себя вынесла за этот процесс поиска работы?1:17:30 Что можешь пожелать тем, кто сейчас ищет работу?1:19:38 Как поставить точку отсчета?

So a Team I coached held a retrospective which I facilitated and I went around post retro and greased the action plan with other managers, so people were not caught of guard.  I greased the future actions so they might go over smoother. Now this scenario does not happen all the time but does every so often especially when the retrospective actions involve people outside of the core team.  There are cases when the effort a team wants to do involve others.  So to aid the team as their agile coach/scrum master I went around individually to any affected people and brought up the plan, gathered their feedback and their buy in before sharing the summary of the retro and the actions to be taken. Scrum Masters need to do this from time to time and not just leave the probability of success up to the four winds.  Sometimes we have to get involved to facilitate a success just as much as a meeting. That is our topic for today 4R Thursday program where we talk roles, requirements, reviews and retros.  Here we are talking the role of a scrum masters/agile coach and the post retro support activities on the #5amMesterScrum Show 1279.   This is the audio podcast version of the program found on LinkedIn, Youtube and Facebook.

Bernie Maloney: Mastering Complexity Through Systems Thinking and NLP Coaching Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Bernie addresses the constant challenge of mid-sprint changes by asking the crucial question: "what do you want to trade in for that new request?" His approach centers on recognizing that everyone is trying to do their best with what they have, using techniques from NLP and the three coaching positions to help people see the whole system. Bernie emphasizes rapport building as a key skill for Scrum Masters and warns against the anti-pattern of becoming judgmental when challenges arise. He advocates for moving from a plan-and-predict mentality to sense-and-respond thinking, highlighting the importance of conducting retrospectives once challenges are solved. Bernie's coaching philosophy revolves around helping people step into the "third position" - a dissociated perspective that enables better problem-solving and systems thinking. In this episode, we refer to Neuro-linguistic Programming (NLP), and to Instant Rapport by Michael Brooks, a primer on NLP. We also refer to the plan-and-predict vs sense-and-respond mentality. Self-reflection Question: How effectively are you helping your teams and stakeholders see the whole system when challenges arise, rather than just focusing on individual pain points? [The Scrum Master Toolbox Podcast Recommends]

Bernie Maloney: The Triangulation Technique—Coaching Agile Teams Through Challenges Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Bernie identifies critical patterns that cause teams to self-destruct, with lack of clarity about intention being the most common culprit. When teams are treated as mere "task workers" without clear vision, strategy, or goals, they become depressed and directionless. Some teams seek forgiveness after failed experiments, while others get stuck seeking permission without taking enough self-leadership. Bernie emphasizes that waiting for direction is fundamentally self-destructive behavior, and Scrum Masters must create safety for teams to reach high performance. He introduces the coaching technique of triangulation, where problems become a third point that coach and coachee examine together, side by side, rather than facing each other in opposition. In this segment, we talk about “What the Duck”, a Lego Serious Play workshop. Featured Book of the Week: Start with Why by Simon Sinek Bernie champions "Start with Why" by Simon Sinek as essential reading for Scrum Masters working to transform team culture. He explains that compelling stories are how leaders truly influence others, following the sequence of Attention-Emotion-Reason. This book helps Scrum Masters understand that their job fundamentally involves changing culture, and leaders must demonstrate the change they want to see. Bernie connects this to the broader leadership challenge of developing coaching and mentoring skills within organizational structures. During this segment, we also refer to the following books:  Drive, By Dan Pink Change the Culture, Change the Game, by Connors et al. The Secret Language of Leadership, by Denning Too Many Bosses, Too Few Leaders, by Peshawaria The Geek Way, by McAfee Right Kind of Wrong, by Edmondson   Self-reflection Question: What patterns of self-destructive behavior might your teams be exhibiting, and how could you help them move from seeking permission to taking ownership? [The Scrum Master Toolbox Podcast Recommends]

Bernie Maloney: The Power of Psychological Safety in Agile Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Bernie shares a powerful story about learning what psychological safety truly means through both success and failure. Working in a high-pressure division with tight timelines and margins, Bernie discovered the transformative power of the mantra "always make a new mistake." When he made a significant error and was met with understanding rather than punishment, he experienced firsthand how psychological safety enables teams to thrive.  Later, facing a different challenge where mistrust existed between management and teams, Bernie had to navigate the delicate balance of maintaining psychological safety while addressing management's desire for transparency. His solution was innovative: conduct retrospectives with the team first, then invite managers in at the end with anonymized contributions. Bernie's approach of framing changes as experiments helped people embrace newness, knowing it would be time-bound and reversible. In this episode we refer to Neuro-linguistic Programming (NLP).  Self-reflection Question: How might your current approach to mistakes and experimentation be either fostering or undermining psychological safety within your team? [The Scrum Master Toolbox Podcast Recommends]

The Daily Scrum is the shortest Scrum event and the most misunderstood. Too many teams turn it into a draggy 30-minute status update instead of the energizing 15-minute sync it's meant to be.In this episode, Kate & Ryan break down how to facilitate Daily Scrums that actually work.  They cover:Why the Daily Scrum is the team's meeting (not a status check for the Scrum Master or Product Owner!)Alternatives to the “three questions” and how to keep things outcome-focusedTricks like the “popcorn” method, music openers, and 15th-minute parking lots to keep energy highHow to handle long-winded updates, lurking managers, and multitasking teammatesWhy this sacred 15 minutes might be your team's most important event of the dayIf you're tired of Daily Scrums that drag on and suck energy out of the room, tune in. Let's reclaim the Daily Scrum as a dynamic, focused, and fun event that drives the sprint forward. 

Mariano Gontchar: The Micromanagement Trap—When PO's Good Intentions Harm Agile Team Performance Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Visionary Leader During an agile transformation project modernizing a build system with multiple stakeholders, Mariano worked with an exceptional Product Owner who demonstrated the power of clear vision and well-defined roadmaps. This visionary Product Owner successfully navigated complex stakeholder relationships by maintaining focus on the product vision while providing clear direction through structured roadmap planning, enabling the team to deliver meaningful results in a challenging environment. The Bad Product Owner: The Task-Manager Micromanager Mariano encountered a well-intentioned Product Owner who fell into the task-manager anti-pattern, becoming overly detail-oriented and controlling. This Product Owner provided extremely detailed story descriptions and even specified who should do what tasks instead of explaining why work was needed. This approach turned the team into mere task-handlers with no space to contribute their expertise, ultimately reducing both engagement and effectiveness despite the Product Owner's good intentions. Self-reflection Question: Are you empowering your team to contribute their expertise, or are you inadvertently turning them into task-handlers through over-specification? [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: Fear-Free Teams—Creating Psychological Safety for High Performance Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Mariano's definition of Scrum Master success has evolved dramatically from his early days of focusing on "deliver on time and budget" to a more sophisticated understanding centered on team independence and psychological safety. Today, he measures success by whether teams can self-manage, communicate effectively with stakeholders, and operate without fear of criticism. This shift represents a fundamental change from output-focused metrics to outcome-focused team health indicators that create sustainable high performance. Self-reflection Question: How has your definition of success evolved in your current role, and what would change if you focused on team independence rather than traditional delivery metrics? Featured Retrospective Format for the Week: Frustration-Based Retrospective Mariano's retrospective approach focuses on asking team members about their biggest frustrations from the last sprint. This format helps team members realize their frustrations aren't unique and creates psychological safety for sharing challenges. The key is always asking the team to propose solutions themselves rather than imposing fixes, making retrospectives about genuine continuous improvement rather than just complaining sessions. [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: From Evangelist to Facilitator—How To Lead A Successful Company Merger Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. During a complex merger between two telecom companies, Mariano faced the challenge of uniting team members with different cultures, practices, and tools. His initial approach of selling Agile theory instead of focusing on benefits failed because he forgot about the "why" of change. The breakthrough came when he shifted from being an Agile evangelist to becoming a facilitator who listened to managers' real challenges. By connecting people and letting the team present their own solutions to leadership, Mariano successfully created unity between the formerly divided groups. Self-reflection Question: Are you trying to sell your methodology or solve real problems, and what would happen if you focused on understanding challenges before proposing solutions? [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: Breaking Down The Clan Mentality In Agile Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Mariano encountered a competent team that was sabotaging itself through internal divisions and lack of trust. The team had formed clans that didn't trust each other, creating blind spots even during retrospectives. Rather than simply telling the team what was wrong, Mariano created an anonymous fear-based retrospective that revealed the root cause: a Product Owner who behaved like a boss and evaluated team members, creating a culture of fear. His approach demonstrates the power of empowering teams to discover and solve their own problems rather than imposing solutions from above. Self-reflection Question: What fears might be hiding beneath the surface of your team's dynamics, and how could you create a safe space for them to emerge? Featured Book of the Week: Turn the Ship Around! by David Marquet Mariano recommends "Turn the Ship Around!" by David Marquet (we have an episode with David Marquet talking about this book, check it here). Mariano highlights the fascinating story and introduction to the leader-leader model, which differs significantly from the traditional leader-follower approach. This book resonates with Mariano's journey from directive leadership to facilitative leadership, showing how empowering others rather than commanding them creates more effective and engaged teams. [The Scrum Master Toolbox Podcast Recommends]

The Birth of the Agile Delivery Manager = No More ScrumMastersIn 2025, we formally changed the title of Scrum Master to Agile Delivery Manager (ADM) in our technology division. This renaming wasn't a rebrand for the sake of optics. It reflected a deeper evolution already happening, rooted in the expanding scope of delivery leadership, the adoption of Flow Metrics and Value Stream Management, and our real-world shift from strict Scrum toward a more customized Kanban-based model.It was this year that the name finally clicked. After assigning Value Stream Architect responsibilities to our Scrum Masters and giving them ownership of delivery metrics, team-level delivery health, and collaboration across roles within their Agile team, I realized the title “Scrum Master” no longer fit their role. I even considered Agile Value Stream Manager, but it felt too narrow and platform-specific.That's when Agile Delivery Manager stood out, not only as a better label but also as a more accurate reflection of the mindset and mission.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

In this episode of the Vets2PM Military Transition Academy Podcast, we're sharing a testimony from Kristin Fogle, a graduate of the Master Project Leader Workshop (MPLW) at Fort Bliss.The MPLW is designed with one mission in mind: to help service members translate their military leadership into civilian career success. Through this program, participants earn three professional project management certifications, receive career preparation training, and connect directly with employers seeking skilled leaders.Kristin's story shows exactly why the MPLW works. From the structure of the program to the support along the way, it breeds success for those ready to take their military experience and turn it into a meaningful, lucrative civilian career.If you've been wondering what makes the MPLW different, this episode will give you insight straight from someone who has lived it.Learn more about the MPLW that is now available at Fort Bliss & Fort Campbell. Master Project Leadership Workshop | Vets2PM, Premier Authorized Training Partner in project management (PMP, CAPM, PMI-ACP, and Scrum Master) certification and credential preparation courses.

Mariano Gontchar: From Boss to Facilitator—The Critical Role of Empathy in Scrum Mastery Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Mariano shares his transformation from viewing himself as a boss in his project manager role to embracing the facilitator mindset essential for Scrum Masters. His journey reveals a crucial insight: you cannot implement Scrum with a "big bang" approach.  Instead, success comes through empathy and understanding your team's needs. Mariano emphasizes that working with Agile requires constant practice and learning, but the key lesson that changed everything for him was learning to empathize with his team members rather than directing them from above. Self-reflection Question: How might your current leadership style be limiting your team's potential, and what would change if you shifted from directing to facilitating? [The Scrum Master Toolbox Podcast Recommends]

Today's guest knows what it means to lead when the stakes are high. Nate Amidon spent 15 years guiding people and programs across the U.S. Air Force, Microsoft, Boeing, and Alaska Airlines. He's an Air Force C-17 evaluator pilot with more than 3,200 flight hours—including 800 in combat—and over 1,500 hours as an instructor teaching young pilots how to fly, make decisions under pressure, and lead crews on global missions. When he transitioned from active duty, Nate brought that same discipline into technology—consulting as a Project Manager, Scrum Master, and Scaled Agile Framework coach on enterprise software programs. He went on to found Form100 Consulting, where he helps clients apply military-tested leadership practices to build strong, high-performing teams that endure. In our conversation, Nate and I talked about how hard that transition actually was. Even with a degree from the Air Force Academy and an MBA, landing his first role at Microsoft wasn't simple—and it showed him how untapped the veteran talent pool really is. That frustration was the spark for Form100, where he now connects veterans with organizations desperate for alignment, communication, and trust. We also dug into why veterans are uniquely equipped for tech: they're trained to see the whole mission, not just their own slice. They know how to drive clarity in chaos, how to align teams across silos, and how to solve problems with urgency but also with care. Nate reminded us that in technology, speed without alignment is just drift. Veterans bring the perspective to check the vector, build relationships, and keep the team moving in the right direction. Nate holds a Management degree from the U.S. Air Force Academy, an MBA from the University of Nebraska, and certifications spanning PMP, CSM, SPC, Lean Six Sigma, and DevOps. He also continues to serve as a reservist C-17 pilot with the 313th Airlift Squadron.

Too many Sprint Plannings feel like marathons with no finish line.  In this episode, Kate & Ryan show you how to flip the script!  They break down practical facilitation moves to keep Sprint Planning crisp, collaborative, and confidence-building.From capacity planning hacks to sprint goals that actually inspire, they share real-world stories, pitfalls to avoid, and energizing techniques you can steal for your own teams.  Whether you're a Scrum Master, Product Owner, or developer, you'll walk away ready to lead Sprint Planning like a pro—no more chaos, just clarity and momentum!

Salum Abdul-Rahman: The SECI Model of Knowledge Management Applied to Team Retrospectives Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum explains how the key role for Scrum Masters is to help teams develop themselves to the point where they can learn and grow without constant guidance. Success means building team resilience and operational capability while knowing when to step back. He emphasizes the importance of recalibration workshops to maintain shared understanding and the balance between supporting teams and challenging them to become self-sufficient. When teams reach this level of maturity, Scrum Masters can focus their efforts elsewhere, knowing the team has developed the capability to continue evolving independently. Featured Retrospective Format for the Week: The 5-Stage Retro Format From the book "Agile Retrospectives," this format captures the complete learning process and aligns beautifully with knowledge management principles. Salum connects the three central phases of this format to the SECI model of knowledge management, particularly referencing Nonaka and Takeuchi's work in "The Knowledge Creating Company." This retrospective structure helps teams create new knowledge and behavioral change by following a systematic approach that transforms individual insights into collective team learning and action. In this segment, we also refer to the seminal article by Takeuchi and Nonaka: “The New New Product Development Game”, which originated the work on Scrum as a framework.  Self-reflection Question: How do you recognize when your team has developed enough self-sufficiency that your role as facilitator can evolve or step back? [The Scrum Master Toolbox Podcast Recommends]

This week on The MisFitNation Show, host Rich LaMonica sits down with Derek Funk—a 13-year U.S. Army Veteran and longtime contractor who served an additional 13 years supporting Identity Intelligence missions with NGIC. With 8 combat deployments to Iraq and Afghanistan under his belt, Derek brings a gritty, honest perspective on service, sacrifice, and what it really means to continue the mission after the uniform comes off. Today, Derek works as a Scrum Master for Booz Allen, supporting the USMC on PEO Digital, and sits on the Board of Directors for Living Free Together, an organization focused on helping military and Veteran families rebuild, reconnect, and thrive. In this episode, we'll dive into:

Mixing pieces from Sprint Reviews and Retros into discussion at the Sprint Planning session.  Something all Scrum Masters or agile coaches should do.. Make them think a little bit more before blasting off from Sprint Planning. Our #5amMesterScrum show 1273 as a part of our 4R Thursday - Roles, Reviews, Retros and Requirements programing 

Salum Abdul-Rahman: From Lunch Conversations to Company-Wide Change—The Power of Creating Communities of Practice Within Organizations Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum shares how he organically built an Agile community within his company by recognizing a shared need for discussion and learning. Starting as a software developer who took on Scrum Master tasks, he felt isolated in his Agile journey. Rather than waiting for formal training or external events, he sent out a simple invite on the company Slack for a lunch discussion during a work day. People showed up, and what began as informal conversations about different approaches to Scrum and Kanban evolved into monthly gatherings. Over time, this grassroots community grew to organize company-wide events and even found new leadership when Salum moved on, demonstrating the power of identifying shared needs and taking initiative to address them. Self-reflection Question: What shared learning needs exist in your organization that you could address by simply reaching out and organizing informal discussions? [The Scrum Master Toolbox Podcast Recommends]

What If Scrum Masters Only Want To Act On A Team Level?I recently had an interesting conversation with a manager at a large organization. We discussed the evolving role of Scrum Masters, the growing questions about their value, and whether organizations are seeing actual returns on these investments.

Salum Abdul-Rahman: From Isolation to Integration—Rebuilding Agile Team Connection For Remote Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum describes working with a grocery ecommerce team during COVID that fell into the trap of prioritizing individual convenience over team collaboration. Remote work led team members to design their work around personal preferences, with the lead developer becoming increasingly isolated and unresponsive to team communication. This anti-pattern of "what works for me" over "what works for the whole team" created significant dysfunction. Despite management intervention, the situation required creative solutions like organizing face-to-face sessions and shared working sessions with digital whiteboards to rebuild team cohesion. Featured Book of the Week: Agile Retrospectives One of the most important roles of Scrum Masters is to help teams develop themselves. Salum emphasizes that you can't tell the team what to do - you have to help them discover it themselves. "Agile Retrospectives" provides the foundation for running meaningful retrospectives that become the key tool for team self-development. The book's emphasis on variation and building retrospectives to match your team's needs and maturity level makes it essential for empowering teams to grow and evolve continuously. Self-reflection Question: How might your team's current work arrangements prioritize individual convenience over collective effectiveness, and what steps could you take to shift this balance? [The Scrum Master Toolbox Podcast Recommends]

Episode 142: Is PMP Certification Worth It? – TestimonialsFor many service members and veterans, one of the biggest questions is: Is earning the PMP® certification really worth it?In this special episode of the Vets2PM Military Transition Academy Podcast, you'll hear directly from three veterans who answered that question for themselves. Each testimonial shares how Vets2PM trained and prepared them to:✔️ Pass their certification exams✔️ Translate their military skills into project management language✔️ Launch meaningful and lucrative project management careersIf you've been wondering whether PMP® is the right move for your career, this episode will give you honest insight from those who've been in your boots.Find out more about the Vets2PM PMP Exam Prep Course and Career Preparation Program: Master Project Leadership Workshop | Vets2PM, Premier Authorized Training Partner in project management (PMP, CAPM, PMI-ACP, and Scrum Master) certification and credential preparation courses.

Salum Abdul-Rahman: The Expert Who Couldn't Connect: An Agile Team Integration Challenge Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Salum shares a challenging situation where a software architect with deep expertise struggled to integrate with the team. Despite the architect's technical knowledge, his expert-based communication style and inability to justify reasoning created friction with other developers. The conflict escalated when the architect disengaged from teamwork and ultimately left the company. This experience highlights the importance of understanding organizational dynamics in large corporations and recognizing when separation might be the best solution for everyone involved. In this episode, we refer to Nonviolent Communication, a topic we've discussed often here on the podcast.  Self-reflection Question: How do you balance respecting expertise while ensuring all team members communicate in ways that foster collaboration rather than create hierarchies? [The Scrum Master Toolbox Podcast Recommends]

Most people think facilitation means running a meeting, keeping time, or taking notes. But true facilitation is so much more - it's about guiding groups toward purpose-driven outcomes, staying neutral, navigating conflict productively, and creating space for every voice in the room!In this episode, Kate and Ryan bust the biggest myths around facilitation - from the false belief that conflict is failure, to the misconception that the facilitator must “own” the decisions. Together, they unpack why neutrality matters, why planning goes far beyond an agenda, and why facilitation is a skill that everyone needs!Whether you're a Scrum Master, Project Manager or simply someone tired of unproductive meetings, this conversation will give you fresh insights, practical tips, and a new appreciation for the power of facilitation!

Irene Castagnotto: The Risk-Aware Scrum Master: Preventing Problems Before They Happen Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Irene defines success for Scrum Masters as helping teams anticipate and manage risks before they become unexpected problems. She focuses on ensuring teams don't face surprise risks during sprints and don't start work with missing requirements. Her approach includes using user story mapping with Product Owners to visualize potential risks and maintaining team happiness as a key success indicator. For Irene, creating a positive team environment is a crucial deliverable that Scrum Masters must actively work on. She emphasizes the importance of listening to team feedback and regularly assessing whether the team feels supported and engaged. In this segment, we refer to W. Edwards Deming, and his famous quote “a bad system will beat a good person, every time!” Featured Retrospective Format for the Week: The Good/Bad/Risk Retrospective This retrospective format works particularly well with younger teams and uses humor to help teams discuss emotionally challenging topics. The format focuses on three key areas: what went well (Good), what didn't work (Bad), and what potential risks the team sees ahead (Risk). Irene recommends this approach because it helps teams surface risks that aren't visible to anyone else, creating opportunities to address potential problems proactively. By incorporating the language of risk into everyday conversations, teams become more aware of potential challenges and can plan accordingly. The humor element helps reduce the emotional intensity that often accompanies difficult discussions about team performance and challenges. In this segment, we refer to the book “How to Make Good Things Happen: Know Your Brain, Enhance Your Life” by Marian Rojas Estape. Self-reflection Question: How comfortable is your team with discussing risks openly, and what techniques could you use to make these conversations more approachable? [The Scrum Master Toolbox Podcast Recommends]

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 podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. 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.

Irene Castagnotto: When Proactive Help Backfires - A Gen Z Scrum Master's Learning Journey Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Irene shares a valuable lesson about the pitfalls of being overly proactive without proper communication. As a new Scrum Master, she observed Product Owners struggling with role changes and took initiative to help them understand and implement changes. However, she discovered that her well-intentioned proposals weren't aligned with what the POs actually wanted. The key insight: when people don't speak up during your proposals, it often means they're not on board but are avoiding conflict. Irene learned that asking questions and letting others express what changes they're ready for is far more effective than assuming what help is needed. Self-reflection Question: How can you better gauge whether your team is genuinely on board with your suggestions, especially when they remain silent during discussions? [The Scrum Master Toolbox Podcast Recommends]

Kate and Ryan are joined by special guest Erin Mullens for a lively, honest conversation about the real world of Scrum Mastery. They explore how each of them found their way into the role, what truly energizes them about the job, and the frustrations they all wrestle with (hello, “gravitational pull of waterfall”!).From building trust with teams to navigating tricky leadership dynamics, they share what it takes to create the “air a team can breathe.” Listeners will hear stories, lessons learned the hard way, and practical tips they can put into play right away, whether they're brand new to the Scrum Master role or seasoned pros.Expect laughs, a few “oh, that's me” moments, and a healthy dose of honesty about the challenges, changes, and the future of the role. This isn't theory, this is Scrum Mastery in action!

Somya Mehra: When Technical Expertise Becomes Product Owner Micro-Management Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Clear Communicator and Dependency Master Somya worked with an exceptional Product Owner on a project with multiple team dependencies. This PO excelled at clear, direct communication with both stakeholders and the team. They were proactive in stakeholder communication and maintained strong focus on what was needed and why. Their backlog management was exemplary, creating proper epics with comprehensive information including dependencies, enabling the team to easily know who to contact. This approach led to a much more motivated team. The Bad Product Owner: The Technical Micro-Manager Somya encountered a technically strong Product Owner whose knowledge became a liability. While technical strength can be beneficial, this PO used their expertise to control the team, telling developers exactly what solutions to implement. Initially, developers accepted this direction, but it escalated to every feature and task. The developers became uncomfortable voicing their perspectives, creating an unhealthy dynamic where the PO's technical knowledge stifled team autonomy and creativity. Self-reflection Question: How do you help Product Owners leverage their technical knowledge without falling into micro-management patterns? [The Scrum Master Toolbox Podcast Recommends]

Somya Mehra: Why Collaboration Should Be Your Team's Primary Goal Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Unlike technical roles where success is tangible, Scrum Master success can be harder to measure, especially for those transitioning from tech roles. Somya defines successful Scrum Master performance through team behaviors: when teams trust and respect each other, and when collaboration becomes their goal. She emphasizes the importance of observing behaviors and discussing them with team members early enough to foster the right behaviors within the team. Featured Retrospective Format for the Week: The 2 Pillars Retrospective Somya recommends the 2 Pillars retrospective format, which she intentionally varies to keep teams engaged and curious. Her core structure focuses on two essential questions: "What went well?" and "How can we improve?" She notices that using the same retrospective format repeatedly leads to team boredom, so she adds variety while maintaining these fundamental pillars. In specific cases, she includes a gratitude section to ensure team members feel appreciated. Self-reflection Question: How do you measure your success as a Scrum Master when the results aren't as tangible as in technical roles? [The Scrum Master Toolbox Podcast Recommends]

In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit their earlier discussion on defining ‘done' in Agile – how to stay on Track and Avoid Scope Creep. They explain why “done” must mean more than “I finished coding,” and they show how a shared Definition of Done (DoD) keeps teams aligned and projects on schedule. What Does “Done” Really Mean? In Agile, “Done” extends beyond writing code. It often includes: Passing unit and integration tests Receiving QA approval Deploying to staging or production Updating documentation Securing acceptance sign-off Without a clear, documented DoD, each team member may interpret “done” differently. As a result, projects risk rework, delays, and frustration. “If we ask, ‘Is it done?' we should get a clear yes or no—no ‘sort of' or ‘almost.'” – Rob Broadhead Why Ambiguity Leads to Trouble Michael points out a common problem: a developer finishes their code, marks the ticket as done, and passes it to QA—only for testers to find gaps in the requirements. A login screen ticket might say “Allow users to log in with username and password.” But does that mean: Username is case-insensitive? Special characters are allowed? Do error messages display on failure? If these details aren't defined, both the developer and tester may interpret “done” differently, leading to frustration on all sides. The Link Between “Done” and Scope Creep Rob and Michael agree: unclear definitions open the door to scope creep. Without a firm DoD, features get stuck in an endless loop of revisions: Developers feel QA keeps moving the goalposts. QA feels developers aren't meeting the requirements. Clients think the delivered feature isn't what they expected. Over time, this erodes trust and pushes delivery dates further into the future. Lessons from the Field Michael contrasts two scenarios from his career that highlight the power of a strong Definition of Done. Before an acquisition, his team worked with a crystal-clear DoD. Every ticket had precise requirements, clear acceptance criteria, and well-defined testing steps. As a result, tasks finished on time, testing followed a predictable pattern, and rework was rare. The team knew exactly when work met the agreed standards, and stakeholders trusted that “done” truly meant done. After the acquisition, the situation changed dramatically. Tickets became vague and massive in scope, often resembling open-ended “make it work” directives. Multiple teams modified the same code simultaneously, resulting in merge conflicts, inconsistent results, and unpredictable delivery schedules. Without a clear DoD, developers, testers, and stakeholders all had different ideas of what completion looked like, and work frequently circled back for revisions. The difference between the two environments came down to one factor: a clear and enforceable Definition of done. In the first scenario, it acted as a shared contract for quality and completion. In the second, the lack of it created confusion, wasted effort, and missed deadlines. Building a Strong Definition of Done The hosts outline key components every DoD should include: Code complete and reviewed – Ensures quality and shared understanding. Automated tests passing – Reduces regressions. Documentation updated – Prevents future confusion. Deployment verified – Proves it works in the target environment. Acceptance criteria signed off – Confirms alignment with the original requirements. Pro Tip: Keep your tests fresh—don't just update them to pass without meeting the real requirement. Who Owns the DoD? One person doesn't own the DoD—it's a team responsibility. Product owners, Scrum Masters, and developers should collaborate to create and update it, reviewing it regularly to adapt to evolving project needs. Making “Done” Part of the Process Once defined, your DoD should be visible and integrated into your workflow: Add it to user stories during sprint planning. Track it in tools like Jira, Trello, or GitHub. Use workflow stages that match your DoD steps—coding, testing, review, deployment, and sign-off. Michael emphasizes that personal accountability matters just as much as team accountability. Great developers hold themselves to the DoD without needing reminders. Your Challenge: Define “Done” This Week If your team doesn't have a documented Definition of Done—or if it's been more than three months since you reviewed it—set aside time this week to: Write down your current DoD. Identify where ambiguity still exists. Get agreement from the entire team. Update your workflow so that every ticket must meet the DoD before it is closed. This single step can prevent months of wasted effort and ensure your work delivers exactly what's intended. The Bigger Picture A well-defined DoD is more than a checklist—it's your guardrail against wasted effort and shifting goals. It ensures the final product matches what the client truly needs, not just what was coded. Your Definition of Done is your “why” for each task—it keeps your work focused, aligned, and valuable. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Getting It Right: How Effective Requirements Gathering Leads to Successful Software Projects The Importance of Properly Defining Requirements Changing Requirements – Welcome Them For Competitive Advantage Creating Use Cases and Gathering Requirements The Developer Journey Videos – With Bonus Content Building Better Developers With AI Podcast Videos – With Bonus Content

Somya Mehra: From Top-Down to Collaborative—Reimagining Organizational Restructuring Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. During a business unit split and reorganization focused on creating smaller teams, Somya and her fellow Scrum Masters were invited to create the new structure process. After hearing feedback that teams felt excluded from previous changes, they decided to include teams in the reorganization process to give them a sense of control. They started by asking top management for constraints, then applied them to see what was possible. They facilitated workshops with Product Owners to divide the product portfolio and determine team assignments, ensuring people felt involved in the change process. Self-reflection Question: When leading organizational change, how do you balance the need for structure with giving teams meaningful input into decisions that affect them? [The Scrum Master Toolbox Podcast Recommends]

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 podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Scott Dunn is a Certified Enterprise Coach and Scrum Trainer with over 20 years of experience coaching and training companies like NASA, EMC/Dell Technologies, Yahoo!, Technicolor, and eBay to transition to an agile approach using Scrum. Auto-generated Transcript: Brian 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.

Somya Mehra: How Upper Management Can Destroy a High-Performing Team in Minutes Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. While working as a business analyst at a startup building an exam evaluation product for universities, Somya witnessed a well-functioning team with good collaboration and timely delivery. However, upper management began challenging the team lead and Scrum Master, accusing the team of padding story points. When leadership confronted the team, the tech lead threw the entire team under the bus, breaking all trust. The CEO's declaration that he could detect padding in estimates shattered the relationship between developers and leadership, leading team members to want to leave. Featured Book of the Week: Agile Retrospectives by Larsen and Derby Somya recommends "Agile Retrospectives" by Larsen and Derby because doing Scrum right means doing retrospectives right. As someone who wanted to excel as a retro facilitator, she found this book invaluable due to its excellent reviews and practical examples. The book provides several examples of how to facilitate retrospectives effectively, making it her go-to recommendation for Scrum Masters wanting to improve their retrospective facilitation skills. Self-reflection Question: How do you maintain trust between your team and leadership when management questions the team's estimates or performance? [The Scrum Master Toolbox Podcast Recommends]

Somya Mehra: Learning to Spot Team Performance Warning Signs Early Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. At the start of Somya's Scrum Master journey, she joined a well-organized and balanced team. However, after two senior developers left the company, the team faced unexpected challenges. Despite hiring new people, velocity didn't improve. Somya discovered that a remaining senior developer had been stepping back and wasn't contributing actively to the team. Through conversations and giving specific tickets to the senior developer, Somya learned valuable lessons about early intervention and communication. Self-reflection Question: How quickly do you address performance concerns with team members, and what signals do you watch for to identify when someone might be disengaging? [The Scrum Master Toolbox Podcast Recommends]

Florian Georgescu: How Decision Journals Can Transform Product Owner Behavior Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Humble Learner Florian describes a Product Owner who started from scratch with business knowledge but no PO experience. This exemplary PO demonstrated transparency and engagement in their communication style, showed humility in recognizing knowledge gaps, and actively built strong relationships with the team. They used practical tools like a Product Canvas shared with the team, implemented "Story Time Tuesdays" for informal refinement sessions, and introduced feature learning cards to assess impact and learn from completed work. This PO's success came from embracing the learning journey openly and creating collaborative environments where both they and the team could grow together. The Bad Product Owner: The Command-and-Control Controller Florian encountered a Product Owner who transitioned from 20 years in project management, bringing a command-and-control style that frustrated the development team. Despite having good business and technical knowledge, this PO made technical decisions for the team without allowing input, particularly challenging since they were in a different location. Florian addressed this through a "decision journal" experiment over three sprints, documenting every product decision and analyzing their impact during retrospectives. This approach served as a powerful mirror, clearly showing that technical decisions made without team input produced poor results, ultimately helping both the PO and team recognize the importance of collaborative decision-making. Self-reflection Question: How does your Product Owner balance their expertise with the team's input, and what tools could help improve this collaboration? [The Scrum Master Toolbox Podcast Recommends]

Florian Georgescu: When Teams Embody Agility Without Having To Thinking About It Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Florian defines success for Scrum Masters as achieving teams that embody agility naturally, without conscious effort. He identifies key behaviors that indicate true team maturity: team members openly discuss their needs and how to fulfill them, they embrace constructive conflict as productive and necessary, and developers can communicate with business stakeholders in accessible language rather than technical jargon. This level of success represents the ultimate goal for Scrum Masters – creating self-organizing teams that have internalized agile principles so deeply that they become second nature, enabling authentic collaboration and effective business communication. Featured Retrospective Format for the Week: Naikan Retrospective The Naikan Retrospective, based on a Japanese self-reflection practice, proved invaluable when Florian's team faced a catastrophic release failure during a Champions League game at a sports betting company. This format addresses three key questions: "What have I done successfully for my team?", "What did I get back from my team?", and "How did I support my team in these hard moments?" Despite initial concerns about team acceptance, this retrospective format provided structured relief during high-tension situations, allowed team members to express missing support needs, and created lasting positive impact. The human-centered approach helped the team process failure constructively and build stronger relationships through structured self-reflection. self-reflection Question: What behaviors in your team indicate they're truly embodying agility, and how might you recognize when they no longer need your guidance? [The Scrum Master Toolbox Podcast Recommends]

Dedicated vs. Rotating Scrum MastersI spent my first five years as a Scrum Master primarily dedicated to one team. As a result, I got to know team members deeply. Even 10+ years after I left, I'm still in close contact with some of them. Due to frequent changes in the team — people come and go — improving team dynamics was a continuous effort. However, after a while, our team understood Scrum, and I could shift my focus towards the broader organization and our customers.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Florian Georgescu: From Resistance to Effective Change Leadership in Agile Adoption Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Florian shares his transformation from resisting organizational standardization to becoming a champion of strategic alignment. Initially fearing that standardization would stifle innovation and turn agile practices into rigid frameworks, he discovered the bigger picture when he became scrum master chapter lead for 12 scrum masters across multiple locations and cultures. The breakthrough came from implementing a three-level standardization approach: level 1 for non-negotiables, level 2 for encouraged patterns, and level 3 for team-specific innovations. Using the 80/20 principle, they focused on the 20% of standards that would create 80% of alignment. The scrum master chapter became a learning hub where teams could share their level 3 innovations, creating a balance between consistency and creativity that enabled effective cross-tribe collaboration. Self-reflection Question: How might you balance the need for organizational alignment with preserving team autonomy and innovation in your current context? [The Scrum Master Toolbox Podcast Recommends]

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 podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. 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.

Florian Georgescu: When Knowledge Hoarding Destroys Team Dynamics Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Florian describes a payment system development team where an experienced tech lead unknowingly created a dangerous dependency. This senior developer, while well-intentioned, became the single point of knowledge and decision-making for the entire team. Other developers began copying his behavior, creating a culture where team members were afraid to ask questions for fear of appearing incompetent. When this key developer left, the team fell apart - planning sessions became confusing, technical discussions stalled, and two junior developers quit citing lack of learning opportunities. The story demonstrates how knowledge hoarding, even when unintentional, can destroy team resilience and create toxic dynamics that stifle growth and collaboration. In this segment, we refer to the Monday episode with Florian as context for the story he shares on this episode. Self-reflection Question: How might knowledge hoarding be happening in your team, and what steps could you take to encourage more distributed learning and decision-making? Featured Book of the Week: The Responsibility Process by Christopher Avery Florian The Responsibility Process by Christopher Avery particularly valuable for understanding the stages people go through when taking responsibility. The book's framework helped him process his own burnout experience and provides crucial insights for helping teams accept responsibility for their outcomes. Florian emphasizes how the responsibility process is essential for understanding what you can influence when you want to take ownership, making it a powerful tool for both personal growth and team development. In this segment, we refer to the Responsibility Process, by Christopher Avery, who was a previous guest on our Audiobook project: Tips From the Trenches, Scrum Master Edition.  [The Scrum Master Toolbox Podcast Recommends]

Florian Georgescu: From Burnout to Balance: A Scrum Master's Reality Check Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Florian shares his experience of trying to single-handedly transform an entire IT service company, leading to what he calls the "superman scrum master syndrome." His story highlights the dangers of trying to be everywhere for everyone and create perfect change from the beginning.  Working with a coach, Florian recognized the warning signs of burnout - exhaustion, frustration, and the unhealthy need to control everything. His journey teaches us that sustainable change takes time, and it's perfectly acceptable for things not to be perfect from the start. The key insight is learning to pace yourself and accept that meaningful transformation is a gradual process, not a solo mission. Self-reflection Question: When have you found yourself trying to be the "superman" in your role, and what signs helped you recognize it was unsustainable? [The Scrum Master Toolbox Podcast Recommends]

Anamaria Ungureanu: Tracking Scrum Team Behavioral Evolution Over Time Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Anamaria defines Scrum Master success by focusing on team behavioral trends and performance evolution over time. She monitors how teams increase trust with stakeholders, demonstrate commitment, and apply agile behaviors consistently. Her approach emphasizes seeking regular feedback from stakeholders and conducting honest self-assessments to ensure the Scrum Master role is truly maximizing team performance. Success isn't measured by a single moment but by sustained positive change in team dynamics and delivery capabilities. Featured Retrospective Format for the Week: Stop/Start/Continue with Enhanced Focus Anamaria recommends the classic Stop/Start/Continue format but emphasizes the importance of varying the questions and bringing both quantitative and qualitative data to drive meaningful conversations. She suggests picking specific themes for each retrospective (like testing) and ensuring that discussions lead to concrete, actionable outcomes rather than just surface-level feedback. Self-reflection Question: How do you currently measure your effectiveness as a Scrum Master, and what trends in your teams indicate genuine progress versus superficial compliance? [The Scrum Master Toolbox Podcast Recommends]

Anamaria Ungureanu: The Tech Lead Who Nearly Destroyed the Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Anamaria describes a seven-member software team that initially seemed engaged but began self-destructing when a senior tech lead refused to embrace transparency and knowledge sharing principles.  The situation escalated when this key team member's four-day absence completely blocked the team's ability to deliver, creating a dangerous single point of failure. Through careful retrospective facilitation and strategic motivation techniques, including offering the specialist new learning opportunities while gradually transferring their legacy knowledge to teammates, Anamaria helped the team overcome knowledge silos and establish sustainable collaboration patterns. Featured Book of the Week: Never Split the Difference by Chris Voss Anamaria recommends “Never Split the Difference” by Chris Voss, a negotiation masterpiece because it taught her essential communication strategies for establishing trust and navigating tense situations. She emphasizes that negotiation is a critical Scrum Master skill, and Voss's techniques help build rapport with stakeholders while managing difficult conversations that arise during team transformations and organizational change initiatives. Self-reflection Question: What knowledge silos exist in your teams, and how might you motivate specialists to share their expertise while providing them with new growth opportunities? [The Scrum Master Toolbox Podcast Recommends]

Anamaria Ungureanu: Goal Clarity—The Missing Piece in Agile Team Performance Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Anamaria shares her experience working with a platform implementation team that appeared engaged but was actually struggling in silence. Despite initial assumptions that everything was fine, the team's quiet demeanor masked their lack of understanding about project goals and deliverables.  Through strategic intervention including goal clarification with the Product Owner, confidence level assessments, and story mapping sessions, Anamaria helped transform a disengaged team into one capable of successful delivery. Her approach emphasized the importance of fostering constructive conflict, asking open questions during sprint planning about demo expectations, and facilitating better PO-team interactions to create transparency and shared understanding. In this episode, we refer to User Story Mapping and the concept of Gemba, or Gemba Walk Self-reflection Question: How might your teams be silently struggling, and what signs should you watch for to identify when apparent engagement actually masks confusion or disengagement? [The Scrum Master Toolbox Podcast Recommends]