Podcasts about scrum masters

Tom Molenaar: When Product Owners “Eat the Grass” for Their 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. The Great Product Owner: The Vision Catalyst "This PO had the ability to communicate the vision and enthusiasm about the product, even I felt inspired." Tom describes an exceptional Product Owner who could communicate vision and enthusiasm so effectively that even he, as the Scrum Master, felt inspired about the product. This PO excelled at engaging teams in product discovery techniques, helping them move from merely delivering features to taking outcome responsibility. The PO introduced validation techniques, brought customers directly to the office for interviews, and consistently showed the team the impact of their work, creating a strong connection between engineers and end users. The Bad Product Owner: The Micromanager "This PO was basically managing the team with micro-managing approach, this blocked the team from self-organizing." Tom encountered a Product Owner who was too controlling, essentially micromanaging the team instead of empowering them. This PO hosted daily stand-ups, assigned individual tasks, and didn't give the team space for self-organization. When Tom investigated the underlying motivation, he discovered the PO believed that without tight control, the team would underperform. Tom helped the PO understand the benefits of trusting the team and worked with both sides to clarify roles and responsibilities, moving from micromanagement to empowerment. In this segment, we refer to the book “Empowered” by Marty Cagan. Self-reflection Question: How do you help Product Owners find the balance between providing clear direction and allowing team autonomy? [The Scrum Master Toolbox Podcast Recommends]

Tom Molenaar: Purpose, Process, and People—The Three Pillars of Scrum Master Success 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. "I always try to ask the team first, what is your problem? Or what is the next step, do you think? Having their input, having my input, bundle it and share it." Tom defines success for Scrum Masters through three essential pillars: purpose (achieving the team's product goals), process (effective Agile practices), and people (team maturity and collaboration). When joining new teams, he uses a structured approach combining observation with surveys to get a 360-degree view of team performance. Rather than immediately implementing his own improvement ideas, Tom prioritizes asking teams what problems they want to solve and finding common ground for a "handshake moment" on what needs to be addressed. Featured Retrospective Format for the Week: Creative Drawing of the Sprint Tom's favorite retrospective format involves having team members draw their subjective experience of the sprint, then asking others to interpret each other's drawings. This creative approach brings people back to their childhood, encourages laughter and fun, and helps team members tap into each other's experiences in ways that traditional verbal retrospectives cannot achieve. The exercise stimulates understanding between team members and often reveals important topics for improvement while building connection through shared interpretation of creative expressions. Example activity you can use to “draw the sprint”.  [The Scrum Master Toolbox Podcast Recommends]

Is Scrum Dying? Or Are We Just Doing It Wrong?Scrum used to be king. Now people don't even want it on their CV.Remember when being a Product Owner was cool? When Scrum Masters were change agents, not glorified note-takers?When saying “we use Scrum” signalled progressive, Agile thinking?Fast forward to now, and you'll find Product Owners ashamed of the title, Scrum Masters sidelined, and developers stuck in factory-mode delivery.Teams are jumping ship to SAFe, Kanban, or “whatever Spotify did,” chasing results Scrum couldn't deliver.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/

Is it ever OK to deviate from the Scrum Guide? - Mike CohnI'm out there on social media and I see all the same posts you do about the sanctity of the Scrum rules. And I get it. There are many rules of Scrum that teams break when they shouldn't. But I don't think it does anyone any good to be so hung up on rules that you throw practicality out the window.Here's the thing: No team should break a Scrum rule before they've tried to do it by the book for a while, and given themselves a chance to understand why each rule exists in the first place.But teams that have been doing Scrum together for a while sometimes need to bend a few Scrum rules to fit their specific circumstances and situation. And in most cases no one needs to start calling foul if they do!Here are a few common rules most teams can safely break or bend:Never extending a sprint is a great rule. Usually. Can it be broken? Yes—not often and always for a good reason (such as a holiday that makes a longer sprint sensible).It's ideal to have a dedicated Scrum Master–it's the best way to build high-performing teams. But having a dedicated Scrum Master is an economic decision and it may not always be justified, especially once the team can take on some responsibilities for itself.Having a retrospective every sprint is a wonderful way to put improvement front and center. But if a team is running one or two-week sprints and things are going well, I think it's OK for them to only do a retrospective every four weeks (or every other sprint).Teams that are new to Scrum should do Scrum by the book. But it's unrealistic to expect teams to never bend or break a rule to better fit their context.Knowing when to follow the rules, and when to break them, helps teams succeed,How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

What separates a solid Scrum Master from a great one? In this episode, Brian Milner sits down with veteran Scrum Master Brian Campbell to talk about the balance between being empathetic, staying grounded, and knowing when it’s time to move on.

Tom Molenaar: When To Stop Helping Agile Teams To Change—A Real Life Story 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. "Instead of slowing down and meeting the team in their resistance, I started to try and drag them because I saw the vision of the possible improvement, but they did not see it." Tom shares a powerful failure story about a team that didn't feel the urgency to improve their way of working. Despite management wanting the team to become more effective, Tom found himself pushing improvements that the team actively resisted. Instead of slowing down to understand their resistance, he tried to drag them forward, leading to exhaustion and ultimately his decision to leave the assignment. This episode explores the critical lesson that it's not our job to save teams that don't want to be saved, and the importance of recognizing when to step back. Self-reflection Question: When you encounter team resistance to change, how do you distinguish between healthy skepticism that needs addressing and fundamental unwillingness to improve? [The Scrum Master Toolbox Podcast Recommends]

Scrum Masters, You're Not Just the Meeting PersonYou set up the standup, run a clean retro, update the board — and yet, nothing really changes. Dependencies still hit late. Stakeholders still ask for fixed timelines. The team's doing its best, but it always feels like someone outside is pulling the rug. Sound familiar?That's because agility doesn't stop at the team boundary. And if you're only coaching inside the circle, you're missing half the job. The real magic? It happens when you start coaching around the team too.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/

Plongez au cœur de l'agilité avec cet épisode essentiel pour réussir votre certification PMP et adopter une posture moderne de chef de projet. Vous découvrirez en quoi le PMBOK V7 transforme la vision du chef de projet, pourquoi l'agilité est incontournable aujourd'hui, et comment faire le bon choix entre prédictif, agile et hybride selon votre contexte.Vous apprendrez :Les fondamentaux de l'agilité appliquée à la gestion de projetLa différence entre Scrum Master, Product Owner et chef de projetComment l'agilité pilote la valeur plutôt que le périmètreDes questions types de l'examen PMP liées à l'agilitéL'importance des soft skills dans un environnement agileQue vous soyez en préparation PMP ou en poste, cet épisode vous offre une fiche de révision audio pour mieux comprendre les approches adaptatives.https://www.canva.com/design/DAGzpmeJNXM/_hTRAthQ7Db8CJM9u4HrMw/edit?utm_content=DAGzpmeJNXM&utm_campaign=designshare&utm_medium=link2&utm_source=sharebuttonRessources mentionnées :Agile Practice Guide : https://www.pmi.org/standards/agileScrum Guide : https://scrumguides.org/index.htmlManifeste Agile : https://manifesteagile.frÉpisode sur Jira: https://smartlink.ausha.co/projetez-vous-abordons-la-gestion-de-projet-sans-complexe/s2e7-un-outil-revolutionnairePartagez votre avis en commentaire ou contactez-moi sur LinkedIn si vous souhaitez un accompagnement personnalisé vers la réussite PMP.Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Ist Scrum-Wissen als Product Owner eigentlich notwendig, um die eigene Rolle gut auszufüllen? Tim und Oliver erleben in ihrer Arbeit, dass hier oft Unsicherheit herrscht. Manche POs fühlen sich unter Druck, jedes Detail auswendig kennen zu müssen, andere verlassen sich stark auf Scrum Master oder Teams und verlieren dabei das Verständnis für die Grundlagen. Und gilt das auch, wenn ich mit meinem Team gar kein Scrum mache? Klar ist, dass Product Owner die Verantwortung für den Produkterfolg tragen. Dafür braucht es nicht nur ein Gespür für Markt, Kunden und Strategie, sondern auch ein solides Fundament im Scrum-Framework. Wer nicht weiß, wie Artefakte, Events und Verantwortlichkeiten ineinandergreifen, kann kaum sicherstellen, dass das Team wirkungsvoll zusammenarbeitet. Gleichzeitig reicht reines Regelwissen nicht aus. Ein Product Owner muss die Prinzipien verstehen, um sie im Alltag an den richtigen Stellen anzuwenden. Scrum-Wissen ist dabei kein Selbstzweck. Es geht nicht darum, im Scrum Guide jede Passage zitieren zu können, sondern um ein Verständnis dafür, wie das Framework Teams unterstützt. Eine Product Ownerin, die versteht, warum das Sprintziel Orientierung gibt, warum ein Backlog nicht nur eine Liste, sondern ein Instrument der Fokussierung ist, und wie das Inkrement Vertrauen bei Stakeholdern schafft, wird wirkungsvoller arbeiten können. Oliver und Tim betonen, dass Product Owner nicht alles alleine schultern müssen. Scrum ist ein Team-Framework, und die Verantwortung verteilt sich bewusst. Doch ohne eigenes Scrum-Wissen droht die Gefahr, die Rolle zu stark auf Stakeholder-Management oder Roadmaps zu verengen. Wer dagegen die Regeln und Prinzipien kennt, kann selbstbewusst auftreten, die Zusammenarbeit mit dem Scrum Master gestalten und dem Team eine klare Richtung geben. Ein weiterer Aspekt ist die Weiterentwicklung. Scrum-Wissen ist nichts Statisches, das man einmal lernt und dann abhakt. Mit jeder Retrospektive, jeder Review und jedem Refinement wächst die Erfahrung, wie die Prinzipien in der eigenen Organisation wirken. Gerade in komplexen Umfeldern braucht es die Bereitschaft, immer wieder Neues auszuprobieren und das eigene Verständnis von Scrum zu hinterfragen. Am Ende geht es nicht darum, als Product Owner ein wandelndes Scrum-Lexikon zu sein. Entscheidend ist, die Grundlagen so zu verinnerlichen, dass sie Orientierung geben, ohne dogmatisch zu wirken. Wer Scrum-Wissen klug einsetzt, schafft Klarheit im Team, fördert Verantwortung und sorgt dafür, dass das Framework seinen eigentlichen Zweck erfüllt: den Raum für wirksame Produktentwicklung. In der Diskussion wird auf den kostenfreien Scrum Foundations Online-Kurs der Agile Academy verwiesen. Ähnliches gibts auch als Agile Fundamentals Online-Kurs. Wir können hier aber auch explizit den ausführlichen Product Owner Online-Kurs mit satten 20 Stunden Videomaterial und Übungen empfehlen. Wir im Podcast erwähnt, bieten wir nun aber auch als Produktwerker selber Zertifizierungstrainings (vor Ort in Köln) an. Oliver Winter ist hierbei unser Trainer. Neben dem Training "Product Owner Level 1" gibt es auch das spannende "Product Owner Level 2" Training als wertvolle Weiterführung für alle, die schon PSPO I (von Scrum.org) oder CSPO (von der Scrum Alliance) und weitere Erfahrung als Product Owner. Beide Trainings bietet Oliver b.a.W. jeweils einmal im Quartal an - und wie erwähnt gibt es im Anschluss die Zertifizierung der Agile Academy. Warum wir nun auch zertifizierte Trainings anbieten, erklärt sich durch diese recht aktuelle Podcast-Folge Anwendungsnahe Weiterbildung - für mehr Erfolg als Product Owner". Diese älteren Episoden werden im Gespräch erwähnt: - Scrum Product Owner vs. SAFe Product Owner - ein Missverständnis - Kennt Kanban Product Owner? - Product Owner ohne Scrum Master - geht das? Wie viel Scrum-Wissen hältst du für notwendig, um als Product Owner erfolgreich zu sein? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns teilst.

Terry Haayema: Why "Working Myself Out of a Job" Is Wrong for Scrum Masters 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. "Success for a Scrum Master is to do myself out of a job... which I don't buy into at all, because a team will always need a coach." Terry challenges the common belief that Scrum Masters succeed by working themselves out of a job, arguing instead that teams always need coaching as they continuously improve. He emphasizes the importance of separating his outcomes from the team's success to avoid becoming part of the system he's trying to help. For Terry, success is measured by the visible joy he can create in people - when leaders approach him with happiness, when team members are excited to see him, when absenteeism drops because people actually want to come to work. He shares a powerful story of how helping teams find joy not only improved their performance but reduced their stress-related sick days from the highest to the lowest in their division. Featured Retrospective Format for the Week: Drawing Retrospectives Terry loves retrospective formats that use drawings and visual metaphors, like Draw Your Feelings, or the Sailboat retrospective. He explains that when teams draw pictures instead of immediately processing thoughts through language, they generate much richer and deeper insights. The approach works by having people first draw their thoughts, then asking "What led you to draw that picture?" This method bypasses the analytical mind and taps into more intuitive understanding. For longer-term retrospectives, Terry recommends Open Space Technology, which allows groups to self-organize around the most important questions they need to answer. Self-reflection Question: How do you measure your own success as a Scrum Master, and does that measurement inspire you to do your best work? [The Scrum Master Toolbox Podcast Recommends]

Agile Coaches Can't Fix What Leadership Keeps BreakingYou can run the cleanest standups, the best retros, and the most motivated team workshops — and still feel like you're sprinting in circles.Because if leadership isn't on board, the system breaks faster than you can coach it. It's the silent pain many Scrum Masters and Agile Coaches carry: you're hired to drive agility, but you're blocked by decisions made way above your influence. And when things stall, guess who gets blamed?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/

Was mit einer Cremeschnitte von Caredda, dem legendären Zuckerbäcker an der Josefstrasse, beginnt, wird schnell zu einem tiefgehenden Gespräch über Erwartungen, Ziele und Motivation. Frank und Duri fragen sich: Welche Erwartungen habe ich an mich selbst – und welche sind unrealistisch? Was ist ein Ziel überhaupt – und wann wird es zum Antrieb? Wie kann man sich (und andere) austricksen, um Ziele wirklich zu erreichen? Macht es glücklicher, auf grosse Lebensziele hinzuarbeiten – oder im Alltag viele kleine Ziele zu verfolgen? Ein Satz bringt das Gespräch auf den Punkt: «Mein Tag ist eigentlich gefüllt mit hundert Zielen.» Es ist eine Episode über das Spiel mit Erwartungen, über Motivationstechniken und die Frage, wie man Ziele so definiert, dass sie tragen – im Alltag, im Beruf und im Leben. Eine Folge für alle, die ihre eigene Haltung zu Zielen, Erwartungen und Motivation hinterfragen wollen. [Frank Renold](https://www.liip.ch/de/team/frank-renold) und [Duri Bonin](https://www.duribonin.ch) diskutieren in ihrem monatlichen Podcast [Mit 40i cha mers mit de Tiger](https://www.duribonin.ch/podcast/) aktuelle Herausforderungen in Beruf, Familie und Gesellschaft. Frank, Scrum Master bei Liip, und Duri, Strafverteidiger, Autor und Podcaster, teilen ihre Einsichten und Erfahrungen aus unterschiedlichen Lebensbereichen. Links zu diesem Podcast: - Das Buch zum Podcast: [In schwierigem Gelände — Gespräche über Strafverfolgung, Strafverteidigung & Urteilsfindung](https://www.duribonin.ch/produkt/in-schwierigem-gelaende/) - [Frank Renold](https://ohnenamen.ch/#header) - Anwaltskanzlei von [Duri Bonin](https://www.duribonin.ch) Die Podcasts "Auf dem Weg als Anwält:in" sind unter https://www.duribonin.ch/podcast/ oder auf allen üblichen Plattformen zu hören

Ifeanyi “Ify” Imachukwu is the founder and CEO of SeenU, a social discovery app designed to spark real-world connections through proximity-based features while protecting user privacy. Ifeanyi combines his background as a content creator with his entrepreneurial vision to build platforms that prioritize authenticity and genuine human interaction. SeenU has already gained traction on university campuses, reflecting his mission to reshape how people connect beyond traditional social media.Connect with Ifeanyi Imachukwu!https://www.instagram.com/itsmeifyyhttps://www.linkedin.com/in/ifeanyiimachukwuhttps://www.tiktok.com/@theifysCHAPTERS:0:00 – Introduction1:11 – Ifeanyi shares his journey building the SeenU social app2:16 – What is SeenU, and what makes it different from other social apps?3:47 – Ifeanyi talks about the challenges of network effects and user growth with SeenU4:48 – How SeenU protects privacy and location data5:40 – Do users need to stay active on the app to connect?6:37 – Ifeanyi shares how SeenU differs from Tinder and Hinge7:50 – Live demo preview of SeenU's radar feature9:08 – Ifeanyi shares how he bootstrapped his app before getting investors10:00 – Ifeanyi talks about finding the right developer for his app11:51 – Ifeanyi's background as a Scrum Master and content creator13:11 – Ifeanyi talks about growing 2M TikTok followers and why he stepped away14:59 – Ifeanyi shares how he received recognition from Rihanna and Ariana Grande for his comedic skits on Instagram16:10 – Ifeanyi shares his deeper “why” behind SeenU17:32 – Word-of-mouth and launch strategy at universities20:44 – Ifeanyi talks about the impact of the “Top 5 Friends” feature in his app22:56 – Ifeanyi talks about transitioning from TikTok to the tech space after setbacks24:52 – Ifeanyi talks about deleting Instagram after hearing God's call27:30 – How Ifeanyi consistently grows across platforms28:28 – Ifeanyi shares editing tricks vs. keeping content authentic29:44 – Ifeanyi's advice to Andy on growing the podcast33:05 – Ifeanyi opens up about pain, tears, and what he learned from it34:53 – Ifeanyi talks about his marketing strategy for SeenU36:19 – Organic marketing vs. outbound outreach37:50 – Ifeanyi shares what gave him the idea to build SeenU39:01 – How Ifeanyi would personally use his app daily41:30 – Ifeanyi shares why they targeted one university when launching SeenU42:17 – Inspiration from MySpace's Tom Anderson: everyone's first friend44:22 – What “face card” means and why it matters46:38 – Ifeanyi shares how to get reposted without paying for clips48:42 – Ifeanyi shares creative ideas to blow up SeenU's social media49:46 – Ifeanyi talks about finding your niche with or without trial and error50:46 – Ifeanyi talks about building the app in just four weeks52:46 – Ifeanyi's recent personal discoveries53:31 – Ifeanyi's personal goals and focus for the next six months54:30 – Connect with Ifeanyi55:03 – Outro

Terry Haayema: When Scrum Practices Aren't Enough - Learning to Sense the System 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. "I didn't know how to 'sense' the system. I was focused on the scrum practices, I thought when practices were there all would be fine." Terry shares a powerful failure story from his second engagement as a Scrum Master, where he discovered that implementing Scrum practices isn't enough if you don't understand the underlying system driving team behaviors. He describes how individual KPIs were causing conflict between developers and testers - developers were measured on fewer defects while testers were measured on finding more defects. This systemic issue created dysfunction that no amount of daily standups or retrospectives could fix. Terry learned the hard lesson that Scrum Masters must be coaches for both the team and the organization, understanding how metrics and structures shape behavior before trying to implement agile practices. Self-reflection Question: What systemic forces in your organization might be working against the collaborative behaviors you're trying to foster in your teams? [The Scrum Master Toolbox Podcast Recommends]

The Sprint Review shouldn't be a sleepy status update, it's a high-leverage inspection-and-adaptation event that shapes what happens next.  In this episode, we break down what a great Sprint Review looks like, why developers should demo working product (not PPT slides), and how Product Owners and Scrum Masters can co-facilitate to keep it tight, focused, and valuable.  Hear practical tips: crafting a clear agenda, inviting the right stakeholders, handling “over-talkers,” using parking lots, avoiding the dog-and-pony prep trap, and closing with decisions that feed straight into the backlog and the next Sprint Plan.

Shawn Dsouza: Beyond Product Knowledge—The Hidden Skills Every Product Owner Needs 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 explores both ends of the Product Owner spectrum through real experiences. On one side, he addresses the "Forced" or "Accidental" Product Owner—a common but problematic pattern where organizations appoint someone based solely on product knowledge. He shares the story of a QA professional thrust into the PO role who knew the product inside out but lacked other essential PO skills, frustrating the team with inadequate responses. Through coaching questions inspired by "The Advice Trap," Shawn helped this reluctant PO reflect on responsibilities and develop confidence beyond technical knowledge. The Great Product Owner: The Story-Crafting Superstar Shawn celebrates a Product Owner who elevated user story writing to an art form—"the Picasso of writing user stories." This exceptional PO co-crafted clear, well-structured stories with the team and used AI to refine stories and acceptance criteria. Her meticulous preparation included intensive refinement sessions before vacations and expert story slicing techniques. By handling requirements clarity superbly, she freed the team to focus entirely on problem-solving rather than deciphering what needed to be built. The Bad Product Owner: The Forced/Accidental Product Owner Organizations frequently make the mistake of appointing the person with the highest product knowledge as Product Owner, assuming technical expertise translates to PO effectiveness. However, the Product Owner role requires diverse skills beyond product knowledge—stakeholder management, prioritization, communication, and strategic thinking. When a QA professional was thrust into this role, their deep product understanding couldn't compensate for underdeveloped PO competencies, leading to team frustration and project complications. In this segment, we refer to the Coach Your PO e-course published by your Scrum Master Toolbox Podcast! Self-reflection Question: What skills beyond domain expertise should you develop or look for when transitioning into or selecting someone for the Product Owner role? [The Scrum Master Toolbox Podcast Recommends]

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]

In this recorded episode of a live Ask a PST session held on September 16, 2025, PST Ryan Brook answered a wide variety of challenging questions from Agile practitioners! He explores the importance of vision-setting, accountability, and building a strong agile culture. Ryan shares practical strategies for leading distributed teams, breaking down silos, and addressing challenges such as complacency, unplanned work, and knowledge gaps. Drawing on his unique background as a chemistry teacher, he highlights how planning and decision-making skills translate into effective leadership.

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]

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]

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]

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]

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]