Podcasts about scrum masters

Agile in Construction: Over-Commitment and Silence—The Deadly Duo Destroying Your Teams With Felipe Engineer-Manriquez 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 don't think people are bad. They don't self-destruct because they're bad. What I do see is people getting crushed in terribly bad systems." - Felipe Engineer-Manriquez   Felipe shares a powerful insight about team dysfunction: teams don't self-destruct because of bad people—they get crushed by broken systems. On a hospital construction project, he witnessed a dangerous pattern: over-commitment coupled with silence. People would commit to pouring concrete on Thursday when there wasn't even rebar in place—a physical impossibility. But psychological safety was so low that no one could say the emperor had no clothes. Felipe's approach? Ask obvious questions that break the pattern. "Don't you need this so you can do that?" This simple question, framed with verb-noun phrases, surfaces what cannot be spoken. He positions himself as "just a simple, dumb general contractor" who doesn't understand—creating safety for others to speak truth. The turning point comes when you slow down, make work visible, and allow people to say no. As Felipe puts it: "For real accountability, if people are not allowed to say no, then they actually can't make a real promise." Silence is not alignment, and saying yes in low-trust environments is actually hiding from accountability.   In this segment, we talk about psychological safety and systems thinking in team dynamics.   Self-reflection Question: When you see a team over-committing to impossible deadlines, what question could you ask that surfaces the truth without putting individuals at risk? Featured Book of the Week: The Goal by Eliyahu Goldratt Felipe chose The Goal by Eliyahu Goldratt as the most transformative book of his early lean career. He describes it as "the number one game changer"—a fictional story that teaches the Theory of Constraints in a way you can internalize. The famous "Herbie story" within the book illustrates how helping the slowest part of a process speeds up the entire system. Felipe emphasizes that Theory of Constraints is often skipped in Scrum training when classes run out of time, leaving many credentialed Scrum Masters without this essential knowledge. He uses these principles daily with the Last Planner System in construction—creating visual boards that look like Gantt charts (because construction loves schedules) but function like Scrum boards with days of the week instead of "to do, doing, done."   [The Scrum Master Toolbox Podcast Recommends]

What Makes a Great Scrum Master?When people ask me, “What does it take to be a great Scrum Master?” my first response is always — In what kind of organization?It's not a dodge. It's the most honest answer I can give.We talk about Scrum Masters as if the role is universal — a fixed job description that applies equally everywhere. But the reality?The Scrum Master navigating a twenty — person startup looks completely different from one guiding a 200-person enterprise team.And both are doing the job right.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/

Cristina Cranga: Coaching Product Owners From Output Obsession to Value Conversations 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.   In this episode, we refer to the work of Esko Kilpi on conversations and episodes on Nonviolent Communication (NVC) on the podcast. The Great Product Owner: A People Person Who Clarifies Before Deciding   "He was comfortable saying 'I don't know yet. What do you think?' It was a bi-directional conversation, not just one-way." - Cristina Cranga   The best Product Owner Cristina worked with was fundamentally a people person and a leader—human skills, not just hard skills. What made him exceptional was his approach to conversation: he started by clarifying the problem first, then decided. By doing this, he separated requests from decisions and made trade-offs explicit.  He was comfortable admitting uncertainty, asking "What do you think?" and engaging the team in co-creation rather than issuing directives. Cristina emphasizes that between the PO and Scrum Master, there's a special bond—a strong leadership partnership that teams look to as a reference. She highlights the concept of "ask more, say less": when you ask questions, you collect information that leads to better, more validated decisions.  The communication process, as outlined in Nonviolent Communication by Marshall Rosenberg, has four components: observation, feelings, needs, and requests. Great POs embody this by treating uncertainty as part of their job, engaging teams more deeply, and connecting work to value rather than just output.   Self-reflection Question: How often does your Product Owner ask "What do you think?" and what would change if they separated requests from decisions more explicitly? The Bad Product Owner: Output Obsession and the Velocity Trap "Success is measured by how much is delivered, not what changes. Teams get faster, but not smarter." - Cristina Cranga   The worst Product Owner anti-pattern Cristina has witnessed is output obsession—measuring success by how much is delivered rather than what actually changes for users or the business. When velocity replaces outcomes as the primary metric, teams get faster but not smarter. Faster doesn't equal smarter. This anti-pattern is particularly dangerous in an AI-accelerated environment where delivery speed is no longer a constraint. The challenge for practitioners is shifting this mindset. The strongest POs make different choices: they own their decisions at the team level, make decisions explicit, treat uncertainty as part of the job, and connect work to value. When POs break free from output obsession, the results are powerful: faster alignment, no decision hallucinations, more engaged teams willing to experiment, and genuine connection between work and value.   In this segment, we refer to Nonviolent Communication by Marshall Rosenberg.   Self-reflection Question: If you removed velocity from your team's dashboard tomorrow, what conversations would emerge about actual value delivered?   [The Scrum Master Toolbox Podcast Recommends]

Cristina Cranga: Decision Quality as the True Measure of Scrum Master Effectiveness 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.   "A Scrum Master is successful when teams make better decisions, faster, with clear trade-offs—everything else is a side effect, not the job." - Cristina Cranga   Cristina offers a refreshingly clear definition of Scrum Master success for 2026: increasing the team's decision quality under accelerating change. She emphasizes that success as a term changes over time, and what mattered in previous years may not be what matters now. It's not about ceremony fluency or even making yourself unnecessary—those are side effects. The core of success is helping teams navigate complexity and AI-driven acceleration by making better decisions faster with explicit trade-offs.  Cristina describes this as an evolution from a "mechanic" role—focused on ceremonies, flow, and structure—to a strategic role. The Scrum Master elevates into a leader of team systems and human behaviors, possibly even becoming an AI integration enabler. This requires reskilling and upskilling as the environment changes. Her prompt for self-reflection: How can you orient your execution of the Scrum Master role more towards strategic aspects, focusing on decision quality as the opposite of decision hallucination?   Self-reflection Question: What would change in your daily work if you measured your success by the quality of decisions your team makes rather than the smoothness of your ceremonies? Featured Retrospective Format for the Week: Start/Stop/Continue Cristina advocates for simplicity in retrospectives, choosing the classic Start/Stop/Continue format. But she emphasizes that the format itself is secondary—what matters is the environment you create and the outcomes you achieve. Her two key conditions for any retrospective: an actionable plan and a simple conversational approach.  She challenges Scrum Masters to focus on the "how" rather than the "what"—how do you hold the space? How do you hold the silence? How do you approach disagreements? The power of Start/Stop/Continue lies in its simplicity, which frees facilitators to focus on creating psychological safety. Cristina also warns against the instinct to take ownership of action items yourself—instead, delegate to team members so they own their problems and become more committed to finding solutions.   [The Scrum Master Toolbox Podcast Recommends]

Cristina Cranga: Why Speed Without Value Creates Chaos in AI-Accelerated 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.   "When output becomes cheap, value becomes harder to see. AI is amplifying this risk." - Cristina Cranga   Cristina brings a timely challenge to the table: how do Scrum Masters stay focused on value when AI tools are accelerating delivery to unprecedented speeds? Teams are delivering faster than ever—AI provides code, tests, documentation, even backlog items—but speed is no longer the constraint. The real challenge is meaning. Teams struggle to explain why their work matters to users or the business.  Cristina frames this as a shift from "delivery" as the primary keyword to "value." She suggests that Scrum Masters are evolving from facilitators of flow to protectors of intent—what she playfully calls "strategic guardians of the value chain" or even "value masters." Together with Vasco, they explore experiment ideas around building clarity of value cycles with product owners, bringing signals of value into earlier backlog work, and helping teams validate faster, not just deliver more.  The key insight: in an AI-accelerated world, the Scrum Master's role becomes more strategic, focused on ensuring teams make better decisions with clear trade-offs rather than just executing ceremonies.   Self-reflection Question: How might you help your product owner build a "clarity of value" cycle that tests ideas before they reach the development team?   [The Scrum Master Toolbox Podcast Recommends]

Cristina Cranga: Why Nice Teams Still Fail and the Power of Honest Conversations 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.   "Sometimes you can change people by only listening to them. Not giving advice—don't become an advice monster." - Cristina Cranga   Cristina shares her experience of sensing that something was off with a team but being unable to pinpoint exactly what it was. Instead of jumping to conclusions, she paused, reflected, and created an intervention plan centered on one thing: starting honest conversations. Through one-on-one discussions with team members, she discovered that the problem wasn't performance or process—it was something deeper.  Expectations weren't aligned with reality, and frustration stemmed from a company culture that didn't offer psychological safety. Cristina introduces the concept of the "advice monster"—someone who constantly tells others what they should do rather than simply listening. She emphasizes that as Scrum Masters, we need to recognize the three layers of our influence: control, influence, and no control.  Even when we can't solve problems, being present and listening can create profound change. The key is self-awareness of our own vulnerability as humans and compassion for others who might be at 80% or 10% of their mental health and energy on any given day.   In this segment, we talk about the importance of psychological safety and active listening in team dynamics.   Self-reflection Question: How often do you enter conversations with the intention of truly understanding rather than solving, and what might you discover if you listened more and advised less? Featured Book of the Week: The Fearless Organization by Amy Edmondson Cristina chose The Fearless Organization by Amy Edmondson as her most influential book because it explains what Scrum Masters see every day but struggle to name. The book provides a mental model for why teams don't speak up and how to influence behavior without forcing it. As Cristina puts it: "She explains why nice teams still fail. Silence is not always alignment and politeness—most of the time, it's distrust." The book repositions the Scrum Master role from someone focused on ceremonies to someone who creates the conditions for psychological safety. It also explains why process alone doesn't fix everything and helps Scrum Masters measure what really matters in a team.   [The Scrum Master Toolbox Podcast Recommends]

Mohini Kissoon: The One Question That Transforms Messengers Into Product Owners The Great Product Owner: The Calm Navigator Who Shields the Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "He said "no" often, but he did it with such clarity that people respected it. It's not just no—it's giving the reason why." - Mohini Kissoon   Mohini has had the privilege of working with many great Product Owners, but one stood out for his calm demeanor and ability to navigate complex situations. Whatever stakeholders threw at him, he remained professional and calm—and critically, he never transferred that pressure onto the team. He had built strong relationships with stakeholders and was the go-to person who commanded respect across the organization.  When stakeholders demanded features that didn't align with team goals, he would acknowledge the request, explain the trade-offs, and offer to revisit it once the current direction was validated. He said no often, but with such clarity and reasoning that people respected his decisions.  This Product Owner also shielded the team from ad hoc requests, handling stakeholder bypass attempts so developers could maintain focus. He would only bring truly urgent items—like compliance issues—directly to the team.  With his helicopter view, he understood how incoming work would impact different stakeholders and parts of the business. Most importantly, he was a good listener who gave the team space to grow and experiment while challenging them constructively.   Self-reflection Question: When you work with your Product Owner, do they shield the team from chaos or pass it through unfiltered—and how might you help them develop that protective capability? The Bad Product Owner: The Messenger Who Couldn't Say No 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.   "When the team would ask 'why are we building this?' the answer would be 'because sales asked for it.' There was no triaging, no challenging stakeholders—just saying yes." - Mohini Kissoon   Mohini shares a story about a Product Owner who appeared to be doing everything right on paper: attending ceremonies, responding to questions, being present for the team, and working closely with stakeholders. But the team was constantly frustrated with scope creep, and the root cause was that this Product Owner was operating as a messenger, not a decision maker. She would bring requests from stakeholders directly into the backlog with no prioritization based on value and no pushback.  Major new work would appear at sprint planning that hadn't been discussed during backlog refinement. The team was committing to 100 story points but only completing 40, with items constantly carrying over.  When Mohini was brought in to help, she asked one simple question that changed everything: "What is the vision for your product?" The Product Owner couldn't answer—because nobody had ever asked her before.  Mohini ran a product vision workshop with her and key stakeholders, created a one-page strategy identifying target users, core problems, and success metrics, and established a working agreement that backlog items must align with identified goals. She also introduced prioritization sessions involving stakeholders. The transformation came when the Product Owner finally felt equipped to say no with informed reasoning.   Self-reflection Question: Does your Product Owner have a clear product vision they can articulate, and if not, what workshop or conversation could you facilitate to help them discover it?   [The Scrum Master Toolbox Podcast Recommends]

Mohini Kissoon: The Language Test That Reveals True Team Ownership 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.   "When I see my team taking ownership of their work, taking ownership of the Scrum events, asking questions, challenging each other constructively without waiting for me—that's when I know I've done my job." - Mohini Kissoon   Mohini defines success for Scrum Masters through three distinct lenses. First, she looks for teams that take ownership—of their work, of the Scrum events, of asking questions and challenging each other constructively without waiting for her to intervene. When she can observe from the sidelines while the team self-manages, she knows she has shaped the right conditions for them to thrive.  Second, success means having metrics that demonstrate improvement over time: team happiness, flow, and how individuals have grown in their roles. These metrics aren't just for the team—they're for sharing with leadership to show the positive impact created.  Third, and perhaps most importantly, success is about creating psychological safety where team members feel comfortable disagreeing, engaging in healthy conflict, and being creative without taking things personally.  One powerful indicator Mohini uses is the language of the team: do they say "their sprint goal" or "our sprint goal"? This subtle shift from passive to possessive language reveals the true level of ownership the team has developed. It's an easy thing to observe but often missed by Scrum Masters.   Self-reflection Question: Listen carefully in your next sprint planning or daily scrum—does your team use "we" and "our" language, or do they speak about the work as something external to them? Featured Retrospective Format for the Week: Timeline Retrospective Mohini finds herself returning to the Timeline retrospective more than any other format, especially when a team has been going through something complex—a difficult sprint, a major release, or a quarterly review with a working group. The format helps people pause and reflect on what has happened before jumping into "what do we change next?" In a physical room, she draws a line on the whiteboard and invites people to add sticky notes for key moments that stood out during the period. In virtual settings, she uses a digital whiteboard. The moments can be good, bad, confusing, or stressful—anything significant. The exercise starts silently, giving everyone space to think without being influenced. Then the team walks through the timeline chronologically, sharing stories behind their notes.  What makes this format powerful is that it creates shared understanding before asking for solutions. Team members often realize that others experienced the same event differently. However, Mohini warns that the timeline can feel overwhelming when you see all the stickies on the board. The key is to build a bridge before jumping to actions: have the team identify patterns, vote on items to discuss further, and only then derive concrete actions from the prioritized items.   [The Scrum Master Toolbox Podcast Recommends]

Mohini Kissoon: Beyond the AI Fear—Discovering What Makes Scrum Masters Truly Irreplaceable 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 real challenge isn't whether AI will replace Scrum Masters. It's whether we understand what parts of our work are actually irreplaceable—and whether we're spending our time on those things." - Mohini Kissoon   Mohini is wrestling with a challenge that's coming up repeatedly in conversations with Agile coaches and Scrum Masters: the anxiety around AI and what it means for their role. She hears questions like "Will AI replace Scrum Masters?" but believes we're asking the wrong question. The real challenge is understanding which parts of our work are truly irreplaceable and demonstrating value in those areas.  People might think that AI can generate sprint reports and analyze team metrics—so why do we need Scrum Masters? But what's missing is the human touch: reading the room, sensing unspoken tension, building trust through presence, and asking questions that shift perspectives. Mohini and Vasco explore how the Scrum Master role may have accidentally become defined by process and structure rather than impact on teams.  The solution lies in showing value through concrete metrics—demonstrating improvement in team happiness, flow, cycle time, and lead time. Scrum Masters need to use storytelling and create history that shows the before and after. They should leverage champions from teams they've worked with to share testimonials. We are like diplomats: we work through influence and need allies both inside and outside the team to support our work.   Self-reflection Question: If AI could handle all the administrative and mechanical aspects of your Scrum Master role tomorrow, what would you spend your time doing—and are you already investing enough time in those irreplaceable human elements?   [The Scrum Master Toolbox Podcast Recommends]

Mohini Kissoon: When Politeness Becomes the Enemy of Team Growth—Escaping the Conflict Avoidance Trap 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.   "Conflict isn't the enemy. It's when we're avoiding conflict that it becomes an issue for teams." - Mohini Kissoon   Mohini shares a story about the worst self-destructive pattern she has witnessed: teams that are overly polite to avoid addressing conflicts. She worked with a team that prided themselves on being collaborative and drama-free, but beneath that politeness was a hesitancy to have difficult conversations. It started small—in sprint planning, the Product Owner would propose unrealistic scope, and people would just nod and accept. Someone might say "that's quite ambitious," but no one would actually push back. In retrospectives, feedback was always wrapped in layers of positive framing. When a developer consistently delivered work that didn't meet the Definition of Done, no one called it out directly—they just quietly fixed it or worked around it. After three months, side conversations started emerging where people would pull Mohini aside to share concerns they would never voice in the room. The team was skipping the storming phase of the Tuckman model, and this avoidance eventually led to missed deadlines and frustrated stakeholders. The key learning: healthy conflict brings the energy teams need to innovate and grow.   In this segment, we talk about the Tuckman model and why the storming phase is essential for team development.   Self-reflection Question: Is your team's harmony genuine collaboration, or is it a facade hiding unspoken frustrations that will eventually surface at the worst possible moment? Featured Book of the Week: Turn the Ship Around by David Marquet Mohini discovered Turn the Ship Around by David Marquet at a time when she was working with multiple teams and feeling exhausted from being the person everyone looked to for answers. She thought that's what servant leadership meant, but she was actually creating dependency rather than capability. The book tells the story of how Marquet took command of the worst-performing submarine in the US Navy and transformed it into the best by fundamentally changing how leadership worked. "Instead of the traditional leader-follower model, he built a leader-to-leader structure where everyone was expected to think, decide, and own their work," Mohini explains.  The key insight was that we don't just empower teams—we need to build an environment where they can grow and don't need permission to excel. This shifted Mohini's approach: instead of saying "here's what I think we should do," she started asking "what have you tried so far? What do you intend to do next?" The book also emphasizes that pushing decision-making down requires providing the knowledge and context teams need to make good decisions.   [The Scrum Master Toolbox Podcast Recommends]

Mohini Kissoon: How to Break the Cycle of Dominant Personalities 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.   "I confused silence with agreement. My silence as a facilitator had been giving the wrong impression to the team: that this kind of dynamic is acceptable." - Mohini Kissoon   In her first year as a Scrum Master, Mohini was full of energy and deeply committed to doing Scrum by the book. She had just earned her certification and joined a mid-sized product team where a senior developer—let's call him Tom—was brilliant but quite dominant. In every session, Tom would speak first, speak longest, and often override the ideas of junior developers. Mohini noticed this pattern but didn't intervene, assuming that Tom's experience and the others' silence meant agreement. Over several sprints, stand-ups became reporting sessions to Tom rather than collaborative planning. Junior developers gradually stopped offering ideas in fear of being shut down. When Mohini finally reached out to the team members individually, one of them was even considering leaving the organization—they felt like "just a cog in the machine." This was the wake-up call Mohini needed. She realized she had been focusing intensely on the mechanics while missing the human dynamics entirely. The solution came through coaching Tom on active listening and introducing facilitation techniques like silent brainstorming and round-robin sharing, giving everyone the opportunity to contribute without being influenced.   Self-reflection Question: When you observe dominant voices silencing others on your team, do you intervene immediately, or do you wait to see if the situation resolves itself—and what does that choice cost your team?   [The Scrum Master Toolbox Podcast Recommends]

I made a VERY controversial Podcast Episode on January 1st and I think people may have completely missed it! There will be 3 CRAZY-BIG changes happening on the Agile Landscape in 2026:

Carmela Then: Why Teams Hate Agile (And How to Change That) 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.   "They just hate it. They absolutely hate it. They had Agile fatigue." - Carmela Then   Carmela describes what success looks like for a Scrum Master, and her answer might surprise you. Years ago, she might have pointed to metrics like cycle time. Today, she measures success by whether teams embrace Agile and Scrum rather than resent it.  She joined a team that was exhausted and bitter—their previous Scrum Master had been a micromanaging project manager in disguise. Stories were broken into disconnected tasks: one for development, one for testing, with no relationship between them. At the end of a sprint, nobody could answer whether something actually worked in production. The team hated Agile with a passion.  Carmela approached them differently—not as a threatening authority figure, but as a humble business analyst there to help. She let the Product Owner vent his frustrations about Agile in a retrospective.  Then, without preaching, she simply showed them another way: how to break down features properly, how to create end-to-end visibility, how to write stories that delivered actual value. Slowly, the team began to experience what Agile was meant to feel like. They stopped being "task deliverers" and started becoming value creators. The transformation wasn't overnight, but the result was a team that finally understood—and even appreciated—why Agile works.   Self-reflection Question: If you asked your team whether they love or hate Agile, what would they say—and are you brave enough to ask? Featured Retrospective Format for the Week: Emotional Seismograph Carmela recommends the Emotional Seismograph as her go-to retrospective format. The setup is simple but powerful: create a graph with the sprint days on the horizontal axis and emotion levels on the vertical (happy at the top, sad at the bottom). Each team member draws a line showing how they felt throughout the sprint. The visual result is striking—and the conversations it triggers are invaluable. Carmela focuses on the extremes: moments of great happiness and moments of stress. She has team members add sticky notes to explain those peaks and valleys, allowing common themes to emerge. Her philosophy is that positive emotions drive productivity: "When the team is having a positive experience throughout their workday, they're actually more productive. Stress is the silent killer—it makes people sick, takes them out physically and mentally, and people will just quit." By putting a finger on the emotional pulse of the team, Scrum Masters can identify what to continue doing and what needs to change to lift the team into a better experience.   [The Scrum Master Toolbox Podcast Recommends]

Carmela Then: When Remote Teams Stop Listening—The Silent Killer of Agile Collaboration 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.   "Two minutes into it, my mind's starting to wander and I started to do my own thing." - Carmela Then   Carmela paints a vivid picture of a distributed team stretched across Sydney, New Zealand, India, and beyond—a team where communication had quietly become the enemy of progress. The warning signs were subtle at first: in meetings with 20 people on the call, only two or three would speak for the entire hour or two, with no visual aids, no PowerPoints, no drawings. The result? Within minutes, attention drifted, and everyone assumed someone else understood the message.  The speakers believed their ideas had landed; the listeners had already tuned out. This miscommunication compounded sprint after sprint until, just two months before go-live, the team was still discussing proof of concept. Trust eroded completely, and the Product Owner resorted to micromanagement—tracking developers by the hour, turning what was supposed to be an Agile team into a waterfall nightmare. Carmela points to a critical missing element: the Scrum Master had been assigned delivery management duties, leaving no one to address the communication dysfunction.  The lesson is clear—in remote, cross-cultural teams, you cannot simply talk your way through complex ideas; you need visual anchors, shared artifacts, and constant verification that understanding has truly been achieved.   In this segment, we talk about the importance of visual communication in remote teams and psychological safety.   Self-reflection Question: How do you verify that your message has truly landed with every team member, especially when working across time zones and cultures? Featured Book of the Week: How to Win Friends and Influence People by Dale Carnegie Carmela recommends How to Win Friends and Influence People by Dale Carnegie, a timeless classic that remains essential reading for every Scrum Master. As Carmela explains, "We work with people—customers are people, and our team, they are human beings as well. Whether we want it or not, we are leaders, we are coaches, and sometimes we could even be mentors." Written during the Great Depression and predating software entirely, this book emphasizes that relationships and understanding people are the foundation of personal and professional success. Carmela was first introduced to the book by a successful person outside of work who advised her not just to read it once, but to revisit it every year. For Scrum Masters navigating team dynamics, stakeholder relationships, and the human side of Agile, Carnegie's principles remain as relevant today as they were nearly a century ago.   [The Scrum Master Toolbox Podcast Recommends]

The Future of the Scrum Master Role In 2026The Death of the Ceremony ManagerAI Won't Replace You — But It Will Replace the Version of You That Stops LearningThe Role Shifts from “Team-Level Support” to “Delivery System Architect”The Rise of the “Hybrid Delivery Leader”The End of Framework FundamentalismA New Career Ladder EmergesThe Future Scrum Master Is a Culture EngineerWhat Gets Left BehindHow 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/

Carmela Then: The Scrum Master Who Learned That Perfect Boards Don't Build Perfect 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 failure part is, instead of leading the team to work toward a common vision, I was probably one of the persons that helped the divide." - Carmela Then   Carmela shares a vulnerable story from her first Scrum Master role at a bank. Armed with training, certifications, and the ability to build a beautiful physical Scrum board with perfectly straight lines, she believed she was ready to lead. But Carmela quickly discovered a crucial truth: mastering the mechanics of Scrum is vastly different from serving a team's real needs. Instead of showing up as a humble learner willing to grow alongside her team, she put on a facade of competence and confidence.  When two Product Owners began fighting for dominance, rather than stepping back and focusing the teams on their shared purpose, Carmela found herself drawn into the political battle, supporting one PO over the other. The result was devastating—a toxic environment where one PO was demoted, and talented team members left the organization entirely. Looking back, Carmela recognizes that her failure wasn't about the Scrum board or ceremonies; it was about not putting the customer and common goals at the center. She learned that Scrum Masters must lead with humility, focus on outcomes rather than egos, and help teams unite rather than divide.   In this episode, we refer to John C. Maxwell and Failing Forward by John C. Maxwell.   Self-reflection Question: When was the last time you prioritized looking competent over truly serving your team's needs, and what did that cost you?   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: Coaching Product Owners to Be the Voice of the Customer In this episode, we refer to Henrik Kniberg's "Product Owner in a Nutshell" video and Product Ownership by Geoff Watts. The Great Product Owner: Rob Gard's Customer Obsession 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 role of the PO really is to help the team empathize with the user, the customer of the product, because that's how they can develop great solutions." - Steve Martin   Rob Gard worked at a fintech firm and is now CPO of a major fintech company. Steve describes him as having a brilliant mind and being a real agileist—someone Steve learned a huge amount about Agile from. Rob's defining characteristic was his absolute obsession with the user. Everything focused on customer pain points. Working with engineering teams serving military customers, Rob held regular workshops with those customers to understand their pain firsthand. He was literally the voice of the customer, not theoretically but practically. Rob pushed and challenged teams to be more innovative, always looking for better ways of providing better software. His gift was communication—specifically, briefing the team on the problem rather than just reading out stories in refinement sessions. This is the anti-pattern many Product Owners fall into: going through the motions, reading requirements without context. Real product ownership, as Rob demonstrated, is telling a story that helps the team empathize and understand the pain. When teams can internalize customer problems, they develop better solutions. Rob's ability to communicate the problem into the minds of teams enabled them to serve customers more effectively. This is the essence of great Product Ownership: not being a proxy for management, not juggling multiple teams, but being deeply connected to customer pain and translating that pain into context the team can work with.   Self-reflection Question: Do your refinement sessions tell stories that help the team empathize with customer pain, or do you just read out requirements? The Bad Product Owner: Proxies for Management Instead of Customer Advocates 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.   "They weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte   Steve emphasizes that Product Owners often have great intentions but struggle due to lack of training and coaching. The anti-patterns are systemic: commercial managers "dressed up" as Product Owners without understanding the role. Project managers transitioning to PO roles—though Steve notes PMs can make really good POs with proper support. The most damaging pattern is Product Owners spread across multiple teams, having very little time to focus on any single team or their customers. These POs become proxies—representing the voice of senior management rather than the voice of the customer. They cascade requirements downward instead of bringing customer insights upward. The solution isn't to criticize these struggling Product Owners but to help them understand their role and see what good looks like. Steve recommends Henrik Kniberg's "Product Owner in a Nutshell" video—15 minutes, 15 years old, still profoundly relevant. He also points to Product Ownership by Geoff Watts and formal training like CSPO or IC Agile Product Ownership courses. The fundamental issue is meeting Product Owners where they are, providing coaching and support to transform them from management proxies into customer advocates. When POs understand their role as empathy builders between customers and teams, everything changes.   Self-reflection Question: Is your Product Owner the voice of senior management or the voice of the customer?   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: Making Scrum Master Success Visible with OKRs That Actually Work 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.   "It is not the retrospective that is the success of the retrospective. It is the ownership and accountability where you take improvements after the session." - Steve Martin   The biggest problem for Scrum Masters isn't just defining success—it's being able to shout it from the rooftops with tangible evidence. Steve champions OKRs as an amazing way to define and measure success, but with a critical caveat: they've historically been poorly written and implemented in dark rooms by executives, then cascaded down to teams who never bought in. Steve's approach is radically different. Create OKRs collectively with the team, stakeholders, and end users. Start by focusing on the pain—what problems or pain points do customers, users, and stakeholders actually experience? Make the objective the goal to solve that problem, then define how to measure progress with key results. When everyone is bought in—Scrum Master, engineers, Product Owner, stakeholders, leaders—all pulling in the same direction, magic happens. Make progress visible on the wall like a speedometer, showing exactly where you are at any moment. For an e-commerce checkout, the problem might be too many steps. The objective: reduce pain for users checking out quickly. The baseline: 15 steps today. The target: 5 clicks in three months. Everyone can see the dial moving. Everything should focus on the customer as the endpoint. The challenge is distinguishing between targets imposed from above ("increase sales by 10%") and objectives created collaboratively based on factors the team can actually control. Find what you can control first, work with customers to understand their pain, and start from there.   Self-reflection Question: Can you articulate your team's success with specific, measurable outcomes that everyone—from developers to executives—understands and owns? Featured Retrospective Format for the Week: Post-Retro Actions and Ownership The success of a retrospective isn't the retrospective itself—it's what happens after. Steve emphasizes that ownership and accountability matter more than the format of the session. Take improvements from the retrospective and bring them into the sprint as user stories with clear structure: this is the problem, how we'll solve it, and how we'll measure impact. Assign collective ownership—not just a single person, but the whole team owns the improvement. Then bring improvements into the demo so the team showcases what changed. This creates cultural transformation: the team themselves want to bring improvements, not just because the Scrum Master pushed them. For ongoing impediments, conduct root cause analysis. Create a system to escalate issues beyond the team's control—make these visible on another board or with the leadership team. Find peers in pain: teams with the same problems can work together collectively. The retrospective format matters less than this system of ownership, action, measurement, and visibility. Stop retrospective theatre—going through the motions without taking action. Make improvements real by treating them like any other work: visible, measured, owned, and demonstrated.   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: Why Agile Fatigue Means We Need to Change Our 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.   "We teach transformation, we support transformation, we help change, but we don't really understand what they're changing from." - Steve Martin   Steve believes Agile as a whole is on the back foot, possibly regressing. There's palpable fatigue in the industry, and transformation in its current form hasn't been the success we hoped. Organizations still need to work in a state of agility—making rapid decisions, aligning teams, delivering value at pace—but they're exhausted by how we've implemented Agile. As Agile professionals, Steve argues, we have a responsibility to take stock and reflect on what's not working. The problem isn't that organizations don't need agility; it's that we've been force-feeding them frameworks without understanding their context. Steve invokes an ancient principle: "When the student is ready, the teacher will appear." But we haven't waited for readiness—we've barged in with Big Bang transformations, bringing 10, 15, or 20 Agile coaches to "save the world." The solution requires meeting people where they are, understanding what they're changing from, not just what they're changing to. Steve's coaching conversation centers on a radical idea: stop trying to help teams that don't want to be helped. Focus on teams already interested in incremental, adaptable delivery. Run small pilots, learn what works, then scale when ready. The age of prescriptive transformation is over. We need to adapt to the reality of the moment, experiment with what works, and have the courage to change the plan when our approach isn't working.   Self-reflection Question: Are you forcing Agile on teams that aren't ready, or are you working with those who genuinely want to improve their delivery approach?   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: When a Distributed Team's Energy Vanishes into the Virtual Void 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.   "They weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte (describing Steve's team situation)   The infrastructure team looked promising on paper: Product Owner in Italy, hardware engineers in Budapest, software engineers in Bucharest, designers in the UK. The team started with energy and enthusiasm, but within a month, something shifted. People stopped showing up for daily stand-ups. Cameras went dark during meetings. Engagement in retrospectives withered. This wasn't just about being distributed—plenty of teams work across time zones successfully. The problem ran deeper. The Scrum Master had a conflict of interest, serving dual roles as both facilitator and engineer. Team members were simultaneously juggling three or four other projects, treating this work as just another item on an impossibly long list. Steve spent a couple of months watching the deterioration before recognizing the root cause: there was no leadership sponsorship or buy-in. Stakeholders weren't invested. The team wasn't actually a team—they were individuals happening to work on the same project. Steve considers this a failure because he couldn't solve it. Sometimes, the absence of organizational support creates an unsolvable puzzle. Without leadership commitment, even the most skilled Scrum Master can't manufacture the conditions for team success.   In this episode, we refer to The Phoenix Project by Gene Kim, a book about organizational culture disguised as a DevOps novel.   Self-reflection Question: Is your team truly dedicated to one mission, or are they a collection of individuals spread across competing priorities? Featured Book of the Week: The Phoenix Project by Gene Kim "There's a lot of good lightning bulb moments that go off." - Steve Martin   Steve describes The Phoenix Project as a book about culture, not just DevOps. Written like a novel following a mock company, it creates continuous light bulb moments for readers. The book resonated deeply with Steve because it exposed patterns he'd experienced firsthand—particularly the anti-pattern of single points of failure. Steve had worked with an engineer who would spend entire weekends doing releases, holding everything in his head, then burning out and taking three days off to recover. This engineer was the bottleneck, the single point of failure that put the entire system at risk. The Phoenix Project illuminates how knowledge hoarding and dependency on individuals creates organizational fragility. The solution isn't just technical—it's cultural. Teams need to share knowledge and understanding, deliberately de-risking the concentration of expertise in one person's mind. Steve recommends this book for anyone trying to understand why organizational transformation requires more than process changes—it demands a fundamental shift in how teams think about knowledge, risk, and collaboration.   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: When the Gospel of Agile Becomes a Barrier to Change 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.   "It took me a while to realize that that's what I was doing. I felt the reason wasn't working was them, it wasn't me." - Steve Martin   Steve carried the Scrum Guide like a Bible in his early days as an Agile coach. He was a purist—convinced he had an army of Agile practitioners behind him, ready to transform every team he encountered. When teams questioned his approach, he would shut down the conversation: "Don't challenge me on this, because this is how it's supposed to be." But pushing against the tide and spreading the gospel created something unexpected: resistance. The more Steve insisted on his purist view, the more teams pushed back. It took him a couple of years to recognize the pattern. The problem wasn't the teams refusing to change—it was his approach. Steve's breakthrough came when he started teaching and realized he needed to meet people where they are, not force them to come to him. Like understanding a customer's needs, he learned to build empathy with teams, Product Owners, and leaders. He discovered the power of creating personas for the people he was coaching, understanding their context before prescribing solutions. The hardest part wasn't learning this lesson—it was being honest about his failures and admitting that his righteous certainty had been the real impediment to transformation.   Self-reflection Question: Are you meeting your teams where they are, or are you pushing them toward where you think they should be?   [The Scrum Master Toolbox Podcast Recommends]

Finding Your Fit as a ScrumMasterHere's something nobody told me when I started as a Scrum Master: the most important interview isn't the one where they ask you about impediment removal or sprint velocity.It's the one you have with yourself.Everyone talks about whether you're a good fit for the role. But what about whether the environment is a good fit for you?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/

Natalia Curusi: From Spreadsheets to Discovery—Helping POs Make the Transition The Great Product Owner: Taking Ownership and Coaching the Team Forward 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.   "That person was not just a great product owner, but a great coach—he had excellent communication and stakeholder management skills, and he coached myself as a Scrum Master, showing me how product ownership should look like." - Natalia Curusi   Natalia worked with a Product Owner who embodied everything the role should be. He didn't come from a technical background, but he possessed exceptional domain knowledge, outstanding communication skills, and stakeholder management expertise you rarely find in one person. What made him truly remarkable was that he coached everyone around him, including Natalia as the Scrum Master.  He demonstrated full empowerment and ownership—making decisions himself rather than constantly escalating to higher management. When risks needed to be taken, he took them with courage and conviction. The team trusted him completely because he balanced business needs with team capacity, always understanding what they could realistically achieve. Over the past five years, this person has been promoted multiple times and now serves as a global director of product, still with the same company.  When Natalia thinks about what great product ownership looks like, she thinks of him—someone who combined technical understanding with coaching ability, took genuine ownership of outcomes, and empowered the team through clear vision and decisive leadership. These are exactly the skills that are hardest to find in the market, yet when you find them, the impact is transformative for the entire organization.   Self-reflection Question: Does your Product Owner take ownership and make decisions, or do they constantly escalate to higher management, preventing the team from moving forward with confidence? The Bad Product Owner: Assigned Without Training, Support, or Willingness "She was a great subject matter expert with deep domain knowledge, but the organization assigned her the product owner role without her willingness, without training, and while she was already 80% loaded with other responsibilities." - Natalia Curusi   Natalia encountered a Product Owner anti-pattern that reveals a systemic organizational failure. The person was an exceptional subject matter expert with incredible domain knowledge, but when the organization decided to adopt Agile, they assigned her the PO role like sticking a label on a box—no training, no consent, no preparation. She was already working at 80% capacity on other responsibilities and had no understanding of what product ownership meant. Frustrated and overwhelmed, she approached the role from a command-and-control mindset. At the project start, she brought a massive spreadsheet of requirements, expecting the team to implement them sequentially.  The team tried a different approach, wanting to understand problems before discussing solutions, but the PO surprised everyone by re-introducing the spreadsheet in a later meeting—a clear sign of misalignment and broken trust. Natalia, recognizing this was a battle she couldn't win without organizational support, chose to manage the relationship rather than create open conflict. She worked to mediate between the PO's spreadsheet approach and the team's need for discovery and iterative development. The real anti-pattern wasn't the individual—it was the organization assigning critical roles without providing training, time, or psychological safety. This situation illustrates why product ownership fails: not from bad people, but from bad systems that set people up to fail.   Self-reflection Question: When you see a struggling Product Owner, are you addressing the individual's behavior or the systemic conditions that set them up to fail in the first place?   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: Measuring What Matters Beyond Velocity and Story Points 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.   "We as Scrum Masters need to put a scope for ourselves—we need to aim to leave the place where we work a little bit better than it was, and to make sure that this place could improve itself without us." - Natalia Curusi   Natalia defines success for Scrum Masters with crystal clarity: leave the organization better than you found it, and ensure it can continue improving when you're gone. This means fostering independence and ownership in teams so they can perform whether you're on vacation, in another meeting, or have moved to coaching other teams.  The opposite pattern—where everything falls apart when the Scrum Master isn't present—reveals someone who hasn't truly succeeded in the role. Natalia also emphasizes the importance of establishing metrics early, but not the traditional ones.  Using velocity as a metric is an anti-pattern that focuses teams on the wrong outcomes. Instead, she recommends metrics like predictability, team morale, psychological safety measured through 360 feedback, and the quality of conversations both within teams and with stakeholders. But metrics alone don't tell the story.  Natalia champions the concept of Gemba walks—going to see what's actually happening, talking to people, observing the reality rather than just reviewing dashboard numbers. Some metrics are easily gamed, others provide only narrow perspectives on reality. The most important practice is using metrics to trigger reflection and adaptation, not as fixed targets. Natalia believes strongly that the quality of conversations—how teams discuss options, make decisions together, and adapt when facing pressure—reveals more about a Scrum Master's success than any velocity chart ever could. The ultimate question: can your team succeed without you?   Self-reflection Question: If you disappeared from your team tomorrow, would they continue improving, or would progress stop until someone replaced you? Featured Retrospective Format for the Week: Spotify Squad Health Check "This is a multidimensional retro that I run with teams every 2 to 3 months—you need around 30 minutes for it, and I often get insights and new ideas from this retrospective that help me as a Scrum Master." - Natalia Curusi   The Spotify Squad Health Check is Natalia's favorite retrospective format because it provides a comprehensive view of team health across multiple dimensions. Unlike traditional retrospectives that might focus on a single sprint or specific issue, this format examines the team's overall state across areas like teamwork, support, mission clarity, and technical quality. Teams rate themselves on various health indicators, creating a visual representation that reveals patterns over time.  What makes this particularly valuable is that it works whether you know the team well or are just starting with them—either way, you gain insights and "aha moments" about where the team truly stands. The multidimensional nature prevents teams from optimizing just one aspect while neglecting others, and the regular cadence (every 2-3 months) allows you to track trends and celebrate improvements.  For Natalia, this format consistently surfaces the hidden challenges that teams might not raise in regular retrospectives, making it an essential tool in her Scrum Master toolkit.   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: Demonstrating Your Value When the Market Questions Agile Roles 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.   "My challenging topic is about the demand of agility in the market—how do we fit ourselves as scrum masters in that AI era? How can we demonstrate our competence and contribution when there's a perception that agile roles bring little value?" - Natalia Curusi   Natalia faces the challenge every Scrum Master in 2025 grapples with: how to demonstrate value in an era when business perceives agile roles as optional overhead. The market has contracted, companies are optimizing budgets, and Scrum Masters often appear first on the chopping block.  There's talk of "blended roles" where developers are expected to absorb Scrum Master responsibilities, and questions about how AI might replace the human facilitation work that coaches provide. But Natalia believes the answer lies in understanding something fundamental: the Scrum Master is a deeply situational and contextual role that adapts to what the team needs each day.  Some teams need help with communication spaces, others need work structure like Kanban boards, still others need translation between technical realities and stakeholder expectations. The challenge is that this situational nature makes it incredibly hard to explain to business leaders who think in fixed job descriptions and measurable outputs. Natalia's approach involves bringing metrics—not velocity, which focuses on the wrong things, but metrics around team independence, continuous improvement, and organizational capability. She suggests concepts like Gemba walks—going to see what's actually happening rather than relying only on numbers. The real question Natalia poses is this: the biggest value we can bring to an organization is to leave it better than we found it, but how do we make that visible and tangible to business stakeholders who need justification for our roles?   Self-reflection Question: If you had to demonstrate your value as a Scrum Master using only observable evidence from the past month, what would you show your leadership?   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: The Dark Side of High-Performing Dream 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.   "I was proud of this team—I helped form them from the start, we traveled to the client together, they were mature and independent, they even jelled outside the workplace. This was my dream team." - Natalia Curusi   Natalia had built something special. The team was technically strong, emotionally connected, and highly productive. They socialized outside work, traveled together to client sites, and operated with remarkable independence. But when a new junior developer joined, everything started to unravel.  The existing team members were like heroes—fast, skilled, confident. The newcomer couldn't keep pace, and slowly Natalia noticed something disturbing: the team started making fun of the new member during retrospectives and stand-ups. The person became an outlier, a black swan ignored by the group. Natalia conducted one-on-one meetings with both the new member and the team, but the situation only worsened. The new person insisted they were fine and didn't need help. The team members claimed they were just joking around. Meanwhile, the team structure and morale deteriorated.  Natalia realized she was watching her dream team self-destruct through a form of bullying—something she hadn't even recognized at the time. Finally, she understood she couldn't handle this alone and escalated to the head of discipline and the organizational psychologist. Together, they decided to rotate the person to another team where they felt more comfortable. Natalia learned a painful lesson: as Scrum Masters, we don't need to solve everything ourselves, and sometimes the best solution is recognizing when to use the support structure around us rather than treating it as a personal failure.   In this episode, we refer to Coaching Agile Teams by Lyssa Adkins and Training from the Back of the Room by Sharon Bowman.   Self-reflection Question: When have you witnessed subtle forms of exclusion in your team, and did you recognize them early enough to intervene effectively? Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins "This was the first book about agile coaching that I read, and it's how I understood that I was already playing the scrum master role without even knowing it—I understood that I was already acting like a glue for the team." - Natalia Curusi   Natalia discovered Coaching Agile Teams at a pivotal moment in her career. The book revealed something profound: if you're irreplaceable, there's a problem. A great Scrum Master or coach makes themselves obsolete by growing team members who can replace them. The team should be able to perform independently when you're on vacation or move to another assignment. Lyssa Adkins showed Natalia that she needed to let go of over-control and over-responsibility, focusing instead on growing the team's capabilities. The book remains one of Natalia's top recommendations for every junior Scrum Master wanting to embrace the role, alongside Training from the Back of the Room, which teaches facilitators how to run interactive workshops where people learn from each other rather than just listening to slides.   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: When Your Technical Expertise Becomes Your Biggest Scrum Master Weakness 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 thought my technical background was my biggest strength, but I understood that this was my biggest weakness—I was coming into stand-ups saying 'I know how we need to fix that issue,' and I was a Scrum Master." - Natalia Curusi   Natalia stepped into her first blended role as team leader and Scrum Master full of confidence. With years of programming experience behind her, she believed she could guide her team through any technical challenge. But during morning stand-ups, she found herself suggesting solutions, directing technical approaches, and sharing her expertise freely. The team listened—after all, she was their former leader. They implemented her suggestions, but when those solutions failed, the team didn't have the thinking process to adapt them to their context.  Natalia realized she was preventing the team's learning and ownership by taking control away from them. The turning point came when she made a deliberate choice: she selected the most technical person on the team to become the technical authority and committed to never stepping on his feet again. From that moment forward, she focused purely on the Scrum Master role—asking questions, fostering collaboration, and shutting up to listen actively.  Years later, that technical lead followed her to another job, and they remain friends to this day. Natalia learned that her contribution wasn't about giving solutions—it was about keeping the team from losing ownership of their work.   Self-reflection Question: When you attend your team's daily stand-up, are you contributing to collaboration, or is your contribution keeping the team from owning their work?   [The Scrum Master Toolbox Podcast Recommends]

BONUS: The Agile Organization as a Learning System Think Like a Farmer, Not a Factory Manager "Go slow to go fast. If you want to go somewhere, go together as a team. Take a farmer's mentality."   Simon contrasts monoculture industrial thinking with the permaculture approach of Joel Salatin. Industrial approaches optimize for short-term efficiency but create fragile systems. Farmer thinking recognizes that healthy ecosystems require patience, diversity, and nurturing conditions for growth. The nervous system that's constantly stressed never builds much over time—think of the body, trust the body, let the body be a body. Value Masters, Not Scrum Masters "We need value masters, not Scrum Masters. Agile is a useful tool for delivering value, but value itself is primary. Everything else is secondary—Agile included."   Tom makes his most provocative point: if you asked a top manager whether they'd prefer an agile person or value delivery, the answer is obvious. Agile is one tactic among many for delivering value—not even a necessary one. The shift required is from process mastery to value mastery, from Scrum Masters to people who understand and can deliver on critical stakeholder values. The DOVE Manifesto "I wrote a paper called DOVE—Deliver Optimum Values Efficiently. It's the manifesto focusing on delivering value, delivering value, delivering value."   Tom offers his alternative to the Agile Manifesto: a set of principles laser-focused on value delivery. The document includes 10 principles on a single page that can guide any organization toward genuine impact. Everything else—processes, frameworks, methodologies—are secondary tools in service of this primary goal. Read Tom's DOVE manifesto here.  Building the Glue Between Social and Physical Technology "Value is created in interactions. That's where the social and physical technology meet—that joyous boundary where stuff gets done."   Simon describes seeing the world through two lenses: physical technology (visible tools and systems) and social technology (culture, relationships, the air we breathe). Eric Beinhoeker's insight is that progress happens at the intersection. The Gilbian learning loops provide the structure; trust and human connection provide the fuel. Together, they create organizations that can actually learn and adapt.   Further Reading To Support Your Learning Journey Resources & Further Reading Explore these curated resources to deepen your understanding of strategic planning, value-based management, and transformative organizational change.    

I figured it was about time I addressed this one. You can’t breathe without taking in some serious AI hype right now. How much is fluff and smoke, and how much is real? AND…how will this apply to Agile? Will AI Save Agile? Great question. I have a few gut-level reactions to this. First, I think there’s a gold-rush feel to what’s going on right now. With any new technology, especially the monumental ones, there’s always speculation that this ‘changes the game forever’. But that can’t always be true. On the one hand, AI has a lot of issues. But its early stages. I think the biggest threat is the unbridled greed that goes with mass adoption. Who’s regulating the copyrights of the material AI is trained on? Who makes sure that AI doesn’t recommend or do dangerous or immoral things? But the big question I have is “why would you want so much stuff created by robots?” I can’t articulate why, but I know I don’t want to read a book or watch a play written and mounted by robots. And hey, if LLM’s need our inventions to grow, learn and innovate, what happens when we no longer create ‘things’? AI’s Role in Agility As of this writing, so much of the conversation is about using AI to take the rote tasks out of a Scrum Master’s day…preparing reports or briefs, summarizing retrospectives, and writing user stories. But there’s also discussion that maybe AI can replace Scrum Masters and Coaches. That’s a little scary for those of us who hold or want to occupy these roles in the future. So maybe someday AI can plan our sprints, produce empirical estimates, and even hold coaching conversations. But Will AI Save Agile? That supposes that the solution to all of our current Agile pains have a known solution. After all, we can’t code or teach things that we have no certain knowledge of. And until we do, it would impossible for AI to magically fix what’s wrong with Agile in 2026. That’s still very much a human concern. Stay tuned – I’ll be exporing more about AI’s role in the future of Agile in some upcoming episodes as I learn more… **THE ALL NEW FORGE LIGHTNING** 12 Weeks to elite leadership! https://learning.fusechamber.com/forge-lightning **CREATE A PROFITABLE BUSINESS FROM YOUR AGILE SKILLS WITH FORGE GENESIS** Everything you need to ideate, validate, market, and sell to enterprise OR consumers. https://learning.fusechamber.com/the-forge-genesis **JOIN MY BETA COMMUNITY FOR AGILE ENTREPRENEURS AND INTRAPRENEURS** The latest wave in professional Agile careers. Get the support you need to Forge Your Freedom! Join for FREE here: https://learning.fusechamber.com/offers/Sa3udEgz **CHECK OUT ALL MY PRODUCTS AND SERVICES HERE:** https://learning.fusechamber.com **ELEVATE YOUR PROFESSIONAL STORYTELLING – Now Live!** The most coveted communications skill – now at your fingertips! https://learning.fusechamber.com/storytelling **JOIN THE FORGE*** New cohorts for Fall 2025! Email for more information: contact@badassagile.com **BREAK FREE OF CORPORATE AGILE!!*** Download my FREE Guide and learn how to shift from roles and process and use your agile skills in new and exciting ways! https://learning.fusechamber.com/future-of-agile-signup We’re also on YouTube! Follow the podcast, enjoy some panel/guest commentary, and get some quick tips and guidance from me: https://www.youtube.com/c/BadassAgile ****** Follow The LinkedIn Page: https://www.linkedin.com/showcase/badass-agile ****** Our mission is to create an elite tribe of leaders who focus on who they need to become in order to lead and inspire, and to be the best agile podcast and resource for effective mindset and leadership game. Contact us (contact@badassagile.com) for elite-level performance and agile coaching, speaking engagements, team-level and executive mindset/agile training, and licensing options for modern, high-impact, bite-sized learning and educational content. If you liked this episode, you should check out: Episode 240 – Why Big Agile Fails Non-Conformity is the Key To Your Agile Future Episode 151 – What's Next?

Scott Smith: Empathy and Availability Define Excellent Product Ownership 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: Always Present, Always Available, Always Curious "They are always present. They always make themselves available for team members that need them." - Scott Smith   Scott is currently working with a Product Owner who exemplifies what great PO collaboration looks like. This person is always present—not just physically but mentally engaged with the team's work and challenges. They make themselves available for team members who need them, responding actively on the team chat and interacting consistently.  What makes this PO stand out is their empathy and curiosity. Instead of being defensive when questions arise or challenges emerge, they lean into helping the team understand and solve problems. They show genuine curiosity about what the team is experiencing, asking questions and exploring solutions together rather than dictating answers.  This PO understands that their role isn't to be the smartest person in the room but to be the most available, most collaborative, and most curious. The result is a team that feels supported and empowered, with clear direction and someone who genuinely helps them answer the hard questions. Scott's experience with this PO demonstrates that presence, availability, empathy, and curiosity are the foundations of great Product Owner work.   Self-reflection Question: How present and available are you to your team, and do you approach their questions with curiosity or defensiveness? The Bad Product Owner: Never There When the Team Needs Direction "The PO was never present. The team had lack of clarity, and vision, and had no direction or someone who would help answer those questions." - Scott Smith   Scott has also experienced the opposite extreme—a Product Owner who was never present. This absence created a cascade of problems for the team. Without regular access to the PO, the team lacked clarity about priorities, vision, and direction. They had questions that went unanswered and decisions that couldn't be made.  The result was frustration and a team that couldn't move forward effectively. An absent PO creates a vacuum where uncertainty thrives. Teams end up making assumptions, second-guessing decisions, and feeling disconnected from the purpose of their work.  The lack of someone who can help answer strategic questions or provide guidance means the team operates in the dark, building things without confidence that they're building the right things. Scott's experience highlights a fundamental truth about Product Ownership: presence isn't optional.  Teams need a PO who shows up, engages, and stays connected to the work. Without that presence, even the most skilled team will struggle to deliver value because they can't align their efforts with the product vision and customer needs.   Self-reflection Question: If your team were asked whether you're present and available as a Product Owner or Scrum Master, what would they say?   [The Scrum Master Toolbox Podcast Recommends]

Scott Smith: Using MIRO to Build a Living Archive of Learning 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.   "We're in a servant leadership role. So, ask: is the team thriving? That's a huge indication of success." - Scott Smith   For Scott, success as a Scrum Master isn't measured by velocity charts or burn-down graphs—it's measured by whether the people are thriving. This includes everyone: the development team and the Product Owner.  As a servant leader, Scott's focus is on creating conditions where teams can flourish, and he has practical ways to gauge that health. Scott does a light touch check on a regular basis and a deeper assessment quarterly. Mid-sprint, he conducts what he calls a "vibe" check—a quick pulse to understand how people are feeling and what they need. During quarterly planning, the team retrospects and celebrates achievements from the past quarter, keeping and tracking actions to ensure continuous improvement isn't just talked about but lived. Scott's approach recognizes that success is both about the work being done and the people doing it. When teams feel supported, heard, and valued, the work naturally flows better. This people-first perspective defines what great servant leadership looks like in practice.   Self-reflection Question: How often do you check in on whether your team is truly thriving, and what specific indicators tell you they are? Featured Retrospective Format for the Week: MIRO as a Living History Museum "Use the multiple retros in the MIRO board as a shared history museum for the team." - Scott Smith   Scott leverages MIRO not just as a tool for running retrospectives but as a living archive of team learning and growth. He uses MIROVERSE templates to bring diversity to retrospective conversations, exploring the vast library of pre-built formats that offer themed and structured approaches to reflection. The magic happens when Scott treats each retrospective board not as a disposable artifact but as part of the team's shared history museum.  Over time, the accumulation of retrospective boards tells the story of the team's journey—what they struggled with, what they celebrated, what actions they took, and how they evolved. This approach transforms retrospectives from isolated events into a continuous narrative of improvement. Teams can look back at previous retros to see patterns, track whether actions were completed, and recognize how far they've come. MIRO becomes both the canvas for current reflection and the archive of collective learning, making improvement visible and tangible across time.   [The Scrum Master Toolbox Podcast Recommends]

In this Scrum.org Community Podcast episode,  Lindsay Velecina from Scrum.org sits down with Robb Pieper and Jason Malmstadt of Responsive Advisors to answer the real, practical questions practitioners have about self-management in Scrum in a live Ask a PST session.Listeners submitted questions like:How do you get management to support self-management?What should you do when a team resists taking ownership?How do you handle a disruptive team member without taking over?What metrics show that self-management actually works?How can junior Scrum Masters enable self-management when they're not technical?AND MANY MORE!Robb and Jason tackle these questions head-on, sharing stories from the field, strategies for creating healthy team boundaries, and tools to make decision-making transparent — including Delegation Poker, feedback loops, and working agreements. They also discuss how to tie self-management to real business outcomes to gain leadership buy-in.Whether you're just beginning your Scrum journey or coaching mature teams, this episode gives you actionable guidance and small experiments you can start using today.

Are You Protecting Your Team Against the Right Thing? - Mike CohnA lot has been written and said about the responsibility of a Scrum Master to protect the team.Examples of protecting the team typically involve running interference with well-meaning but overzealous product owners, stakeholders, and managers. Teams run into trouble all the time from people who want it all now or who keep adding more work in the middle or a sprint. Scrum Masters keep all that noise away so that the team can focus on delivery.But if you are only focused on problems coming from squeaky wheels, you're missing one of the biggest dangers out there: complacency.Agile is about continually getting better. I don't care how good a team is today; if they aren't better a year from now, they're not agile.Complacency can creep in when a team sees some initial improvement from adopting an agile approach. Team members will notice how improved they are and think that's enough.But there's almost always room for further improvement.Some teams become complacent about their process and stop looking for ways to deliver more value each iteration. Still other teams become complacent in seeking out new engineering practices that could make the team even better.Protect your team from complacency by setting high expectations and encouraging the team to set even higher expectations of their own performance.Teams that refuse to settle for the status quo are teams that advance from good to great.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/

Scott Smith: Why Great Scrum Masters Create Space for Breaks 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.   "Think of the people involved. Put yourself in the shoes of the other." - Scott Smith   Scott found himself in the middle of rising tension as voices escalated between the Product Owner and the development team. The PO was harsh, emotions were running high, and the conflict was intensifying with each exchange. In that moment, Scott knew he had to act.  He stepped in with a simple but powerful reminder: "We're on the same team." That pause—that momentary break—allowed everyone to step back and reset. Both the PO and the team members later thanked Scott for his intervention, acknowledging they needed that space to cool down and refocus on their shared outcome.  Scott's approach centers on empathy and perspective-taking. He emphasizes thinking about the people involved and putting yourself in their shoes. When tensions rise, sometimes the most valuable contribution a Scrum Master can make is creating space for a break, reminding everyone of the shared goal, and helping teams focus on the outcome rather than the conflict. It's not about taking sides—it's about serving the team by being the calm presence that brings everyone back to what matters most.   Self-reflection Question: When you witness conflict between team members or between the team and Product Owner, do you tend to jump in immediately or create space for the parties to find common ground themselves? Featured Book of the Week: An Ex-Manager Who Believed "It was about having someone who believed in me." - Scott Smith   Scott's most influential "book" isn't printed on pages—it's a person. After spending 10 years as a Business Analyst, Scott decided to take the Professional Scrum Master I (PSM I) course and look for a Scrum Master position. That transition wasn't just about skills or certification; it was about having an ex-manager who inspired him to chase his goals and truly believed in him. This person gave Scott the confidence to make a significant career pivot, demonstrating that sometimes the most powerful catalyst for growth is someone who sees your potential before you fully recognize it yourself. Scott's story reminds us that great leadership isn't just about managing tasks—it's about inspiring people to reach for goals they might not have pursued alone. The belief and encouragement of a single person can change the trajectory of someone's entire career.   [The Scrum Master Toolbox Podcast Recommends]

In this episode we're in conversation with Manjit Singh, the president and founder of Agilious and an instructor at ACT-IAC Academy. They delve into the importance of agile frameworks, particularly scrum, for government IT acquisition and modernization. Manjit shares his extensive technical background and the significance of scrum mastery in managing projects efficiently. He discusses the role of a Scrum Master, common misconceptions, the importance of asking the right questions, and the impact of emerging technologies like AI. The episode also highlights continuous upskilling and the value of lean principles in achieving productivity.Subscribe on your favorite podcast platform to never miss an episode! For more from ACT-IAC, follow us on LinkedIn or visit http://www.actiac.org.Learn more about membership at https://www.actiac.org/join.Donate to ACT-IAC at https://actiac.org/donate. Intro/Outro Music: See a Brighter Day/Gloria TellsCourtesy of Epidemic Sound(Episodes 1-159: Intro/Outro Music: Focal Point/Young CommunityCourtesy of Epidemic Sound)

Sara Di Gregorio: Coaching Product Owners from Isolation to Collaboration 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: Using User Story Mapping to Break Down PO Isolation "One of the key strengths is the ability to build a strong collaborative relationship with the Scrum team. We constantly exchange feedback, with the shared goal of improving both our collaborating and the way of working." - Sara Di Gregorio   Sara considers herself fortunate—she currently works with Product Owners who exemplify what great collaboration looks like. One of their key strengths is the ability to build strong collaborative relationships with the Scrum team. They don't wait for sprint reviews to exchange feedback; instead, they constantly communicate with the shared goal of improving both collaboration and ways of working.  These Product Owners involve the team early, using techniques like user story mapping after analysis phases to create open discussions around upcoming topics and help the team understand potential dependencies. They make themselves truly available—they observe daily stand-ups not as passive attendees but as engaged contributors. If the team needs five minutes to discuss something afterward, the Product Owner is ready. They attend Scrum events with genuine interest in working with the team, not just fulfilling an attendance requirement. They encourage open dialogue, even participating in retrospectives to understand how the team is working and where they can improve collaboration. What sets these Product Owners apart is their communication approach. They don't come in thinking they know everything or that they need to do everything alone. Their mindset is collaborative: "We're doing this together." They recognize that developers aren't just executors—they're users of the product, experts who can provide valuable perspectives.  When Product Owners ask "Why do you want this?" and developers respond with "If we do it this way, we can be faster, and you can try your product sooner," that's when magic happens. Great Product Owners understand that strong communication skills and collaborative relationships create better products, better teams, and better outcomes for everyone involved.   Self-reflection Question: How are your Product Owners involving the team early in discovery and analysis, and are they building collaborative relationships or just attending required events? The Bad Product Owner: The Isolated Expert Who Thinks Teams Just Execute   "Sometimes they feel very comfortable in their subject, so they assume they know everything, and the team has only to execute what they asked for." - Sara Di Gregorio   Sara has encountered Product Owners who embody the worst anti-pattern: they believe they don't need to interact with the development team because they're confident in their subject matter expertise. They assume they know everything, and the team's job is simply to execute what they ask for. These Product Owners work isolated from the development team, writing detailed user stories alone and skipping the interesting discussions with developers. They only involve the team when they think it's necessary, treating developers as order-takers rather than collaborators who could contribute valuable insights.  The impact is significant—teams lose the opportunity to understand the "why" behind features, Product Owners miss perspectives that could improve the product, and collaboration becomes transactional instead of transformational. Sara's approach to addressing this anti-pattern is patient but deliberate. She creates space for dialogue and provides training with the Product Owner to help them understand how important it is to collaborate and cooperate with the team. She shows them the impact of including the team from the beginning of feature study.  One powerful technique she uses is user story mapping workshops, bringing both the team and Product Owner together. The Product Owner explains what they want to deliver from their point of view, but then something crucial happens: the team asks lots of questions to understand "Why do you want this?"—not just "I will do it."  Through this exercise, Sara watched Product Owners have profound realizations. They understood they could change their mindset by talking with developers, who often are users of the product and can offer perspectives like "If we do it this way, we can be faster, and you can try your product sooner."  The workshop helps teams understand the big picture of what the Product Owner is asking for while helping the Product Owner reflect on what they're actually asking. It transforms the relationship from isolation to collaboration, from directive to dialogue, from assumption to shared understanding.   In this segment, we refer to the User Story Mapping blog post by Jeff Patton.   Self-reflection Question: Are your Product Owners writing user stories in isolation, or are they involving the team in discovery to create shared understanding and better solutions?   [The Scrum Master Toolbox Podcast Recommends]

Sara Di Gregorio: How to Know Your Team Has Internalized Agile Values 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.   "Scrum isn't just a process to follow, it's a way of working." - Sara Di Gregorio   For Sara, success as a Scrum Master isn't measured by what the team delivers—it's measured by how they grow. She knows that if you facilitate team growth in communication and collaboration, delivery will naturally improve.  The indicators she watches for are subtle but powerful. When teams come to her with specific requests outside the regular schedule—"Can we have 30 minutes to talk and reflect mid-sprint?"—she knows something has shifted. When teams want to reflect outside the retrospective cycle, it means they've internalized the value of continuous improvement, not just going through the motions. She listens for the word "goal" during sprint planning.  When team members start their planning by talking about goals, she feels a surge of recognition: "Okay, for me, this is very, very, very important." Success shows up in unexpected places. One of her colleague's teams pushed back during a cross-team meeting, saying "We're going out of the timebox" and suggesting they move the discussion to a different time. That kind of proactive leadership and accountability signals maturity. It means the team isn't just attending Scrum events because they have to—they truly understand why each event matters and actively participate to make them valuable.  When Sara first met a team, they asked if she wanted to change things. She said no. What she focuses on is how people improve and understand the process better. For her, it starts with the people—when people change and understand the value, that's when real changes happen in the company. It's about helping people feel good and be guided well, because when they're working well, that's when transformation becomes possible. As Sara reminds us, Scrum isn't just a process to follow—it's a way of working that teams must embrace, understand, and make their own.   Self-reflection Question: Are your teams coming to you asking for reflection time outside scheduled events, and what does that tell you about how deeply they've internalized continuous improvement? Featured Retrospective Format for the Week: Unstructured Retrospective After facilitating many structured retrospectives, Sara started experimenting with an unstructured format that brought new energy to team reflection. Instead of using predefined frameworks, she brings white paper, sticky notes, and sharpies of different colors. She opens with a simple question: "Guys, what impacted you mostly during the last week? How do you feel today?" Sometimes she starts with data and metrics; other times, she begins with how the team is feeling.  The key is creating open space for conversation rather than forcing it into a predetermined structure. What Sara discovered is remarkable: "They are more engaged, more open, and more present in the conversation, maybe because it was something new." Instead of the same structured format every time, the unstructured approach breaks the routine and creates space for true reflections that bring out something deeper and more meaningful. It allows people to express what's genuinely going on for them, not just what fits into a predefined template.  Sara doesn't abandon structured formats entirely—she alternates between structured and unstructured to keep retrospectives fresh and engaging. She also recommends, if you work hybrid, trying to schedule unstructured retrospectives for days when the team is in the office together. The physical presence combined with the open format creates an environment where teams can be more vulnerable, more creative, and more honest about what's really happening. The unstructured retrospective isn't about chaos—it's about trusting the team to surface what matters most to them, with the Scrum Master providing light facilitation and space for authentic reflection.   [The Scrum Master Toolbox Podcast Recommends]

5 Essential Skills Every Scrum Master NeedsBeing a Scrum Master isn't just about booking meetings and quoting the Scrum Guide. It's about showing up every day as a change agent — the one who helps people work better together, face complexity with courage, and actually deliver value.It's easy to forget that Scrum is fundamentally about people.Your job as a Scrum Master is to unlock that potential — not by managing them, but by enabling them.How to connect with AgileDad:- [website] ⁠https://www.agiledad.com/⁠- [instagram] ⁠https://www.instagram.com/agile_coach/⁠- [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠- [Linkedin] ⁠https://www.linkedin.com/in/leehenson/

Sara Di Gregorio: Facilitating Deeper Retrospectives—When to Step In and When to Step Back 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.   "When they start connecting and having an interesting discussion, I go to the corner, and I'm only trying to listen." - Sara Di Gregorio   Sara faces a challenge that many Scrum Masters encounter: teams that want to discuss too many topics during retrospectives without going deep on any of them. The team had plenty to talk about, but conversations stayed surface-level, never reaching the insights that drive real improvement. Sara recognized that the aim of the retrospective isn't to talk about everything—it's to go deeper on topics the team genuinely cares about.  So she started coaching teams to select just three main topics they wanted to discuss, helping them understand why prioritization matters and making explicit which topics are most important. But her real skill emerged in how she facilitated the discussions. When she saw communication starting to flow and team members becoming deeply connected to the topic, she moved to the corner and listened. She didn't abandon the team—she remained present, ready to help shy or quiet members speak up, watching the clock to respect timeboxes.  But she understood that when teams connect authentically, the Scrum Master's job is to create space, not fill it. Sara learned to ask better questions too. Instead of repeatedly asking "Why? Why? Why?"—which can feel accusatory—she reformulated: "How did you approach it? What happens?" When teams started blaming other teams, she redirected: "What can we influence? What can we do from our side?" She used visual tools like white paper, sharpies, and sticky notes to help teams visualize their discussion steps and create structured moments for questions.  Sometimes, when teams discussed complex technical topics beyond her understanding, she empowered them: "You are the main expert of this topic. Please, when someone sees that we're going out of topic or getting too detailed, raise your hand and help me bring the communication back to what we've chosen to talk about."  This balance—knowing when to step in with structure and when to step back and listen—is what transforms retrospectives from checkbox events into genuine opportunities for team growth.   Self-reflection Question: In your facilitation, are you creating space for deep team connection, or are you inadvertently filling the space that teams need to discover insights for themselves?   [The Scrum Master Toolbox Podcast Recommends]

Sara Di Gregorio: Rebuilding Agile Team Connection in the Remote Work Era 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 book helped me to shift from reacting to connecting, which completely changed the quality of conversation." - Sara Di Gregorio   When COVID forced Sara's team into full remote work, she noticed something troubling—the team was losing real connection. Replicating in-office meetings online simply didn't work. People attended meetings but weren't truly present. The spontaneous coffee machine conversations that built relationships and surfaced important information had vanished.  So Sara started experimenting. She introduced 5-minute chit-chat sessions at the start of every meeting: "Guys, how are you today? What happened yesterday?" She created "coffee all together" moments—10-minute virtual breaks where the team could drink coffee or have aperitivos together, sometimes three times per week. She established weekly feedback sessions every Friday morning—30 minutes to recap the week and understand what could improve.  These weren't just social niceties; they were deliberate efforts to recreate the human connections that remote work had stripped away. Sara recognized that mechanized interactions—"here are the things I need you to do, let's talk next steps"—kill team dynamics. Teams need moments where they relate to each other as people, not just as functions.  The experiments worked because they created space for genuine connection, allowing the team to maintain the trust and collaboration that makes effective teamwork possible, even when working remotely.   In this episode, we refer to Non-Violent Communication concepts and practices.   Self-reflection Question: How are you creating moments for your remote or hybrid team to connect as people, not just as colleagues executing tasks? Featured Book of the Week: Nonviolent Communication by Marshall Rosenberg Sara credits Nonviolent Communication by Marshall Rosenberg (translated in Italian as "Words are Windows, or They are Walls") as having a deep impact on her career. The book explores how to listen without judging, how to ask the right questions, and how to observe people to understand their real needs. But above all, it teaches how to communicate in a way that builds connection rather than creating barriers.  For Sara, the book was remarkably practical—she didn't just read it, she experimented with the techniques afterward. She explains: "I think that without this mindset, it's easy to fall into reactive communication, trying to defend, justify, or give quick answers. But that often blocks real understanding." The book helped her shift from reacting to connecting, which completely changed the quality of her conversations.  As a Scrum Master working with people every day—facilitating meetings, mediating conflicts, supporting teams—the way we communicate determines whether we open dialogue or close it. Sara found that taking time to reflect instead of giving quick answers transformed her ability to help teams discover dependencies, improve dialogue, and address communication issues. For anyone in the Scrum Master role, this book provides essential skills for building the kind of connection that makes true collaboration possible. In this segment, we also refer to the NVC episodes we have on the podcast. Check those out to learn more about Nonviolent Communication   [The Scrum Master Toolbox Podcast Recommends]

Sara Di Gregorio: When Teams Lose Trust—How Scrum Masters Rebuild It One Small Change at a Time Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I continue to approach this situation with openness, positivity, and trust, because I truly believe that even the smallest changes can make a difference over time." - Sara Di Gregorio   Sara faced one of the most challenging situations a Scrum Master can encounter—a team member who had lost all trust in change, creating a negative atmosphere that weighed heavily on the entire team. She remembers the heaviness on her shoulders, feeling personally responsible for the team's wellbeing. The negativity was palpable during every meeting, and it threatened to undermine the team's progress.  But Sara refused to give up. She started experimenting with different approaches: one-to-one conversations to understand what was happening, bringing intentional energy to meetings, and trying new facilitation techniques in retrospectives. She added personal check-ins, asking "How are you today?" at the start of stand-ups, consciously bringing positive energy even on days when she didn't feel it herself.  She discovered that listening—truly listening, not just hearing—means understanding how people feel, not just what they're saying. Sara learned that the energy you bring to interactions matters deeply. Starting the day with genuine interest, asking about the team's wellbeing, and even making small comments about the weather could create tiny shifts—a small smile that signaled something had changed.  Her approach was rooted in persistence and belief: she continued approaching the situation with openness, positivity, and trust, knowing that even the smallest changes can make a difference over time. For Sara, reestablishing a good environment wasn't about quick fixes—it was about showing up every day with the right energy and never giving up on her team.   Self-reflection Question: What energy are you bringing to your interactions with the team today, and how might that be shaping the team's atmosphere?   [The Scrum Master Toolbox Podcast Recommends]

Alidad Hamidi: The Tax Agile Teams Pay for Organizational Standards 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.   "If you set targets for people, they will achieve the target, even if that means destroying the system around them." - W. Edwards Deming (quoted by Alidad)   The tension is familiar to every Scrum Master working in large organizations: leadership demands standard operating models, flow time metrics below specific numbers, and reporting structures that fit neat boxes. Meanwhile, teams struggle under the weight of context-insensitive measurements that ignore the nuanced reality of their work. Alidad faces this challenge daily—creating balance between organizational demands and what teams actually need to transform and thrive.   His approach starts with a simple but powerful question to leaders: "What is it that you want to achieve with these metrics?" Going beyond corporate-speak to have real conversations reveals that most leaders want outcomes, not just numbers. Alidad then involves teams in defining strategies to achieve those outcomes, framing metrics as "the tax we pay" or "the license to play." When teams understand the intent and participate in the strategy, something surprising happens—most metrics naturally improve because teams are delivering genuine value, customers are happy, and team dynamics are healthy.   But context sensitivity remains critical. Alidad uses a vivid analogy: "If you apply lean metrics to Pixar Studio, you're gonna kill Pixar Studio. If you apply approaches of Pixar Studio to production line, they will go bankrupt in less than a month." Toyota's production line and Pixar's creative studio both need different approaches based on their context, team evolution, organizational maturity, and market environment. He advocates aligning teams to value delivery with end-to-end metrics rather than individual team measurements, recognizing that organizations operate in ecosystem models beyond simple product paradigms.   Perhaps most important is patience. "Try to not drink coffee for a week," Alidad challenges. "Even for a single person, one practice, it's very hard to change your behavior. Imagine for organization of hundreds of thousands of people." Organizations move through learning cycles at their own rhythm. Our job isn't to force change at the speed we prefer—it's to take responsibility for our freedom and find ways to move the system, accepting that systems have their own speed.   Self-reflection Question: Which metrics are you applying to your teams without considering their specific context, and what conversation do you need to have with leadership about the outcomes those metrics are meant to achieve?   [The Scrum Master Toolbox Podcast Recommends]

Alidad Hamidi: When a Billion-Dollar Team Becomes Invisible 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.   "Most of the times, it's not teams that are self-destructive or anything... Simple analogy is when a flower is not blooming, you don't fix the flower, you fix the soil." - Alidad Hamidi   The team sat on the sidelines, maintaining a large portfolio of systems while the organization buzzed with excitement about replatforming initiatives. Nobody seemed to care about them. Morale was low. Whenever technical challenges arose, everyone pointed to the same person for help. Alidad tried the standard playbook—team-building activities, bonding exercises—but the impact was minimal. Something deeper was broken, and it wasn't the team.   Then Alidad shifted his lens to systems thinking. Instead of fixing the flower, he examined the soil. Using the Viable Systems Model, he started with System 5—identity. Who were they? What value did they create? He worked with stakeholders to map the revenue impact of the systems this "forgotten" team maintained. The number shocked everyone: one billion dollars. These weren't legacy systems gathering dust—they were revenue-generating engines critical to the business. Alidad asked the team to run training series for each other, teaching colleagues about the ten different systems they managed. They created self-assessments of skill sets, making visible what had been invisible for too long. When Alidad made their value explicit to the organization, everything shifted. The team's perspective transformed. Later, when asked what made the difference, their answer was unanimous: "You made us visible. That's it." People have agency to change their environment, but sometimes they need someone to help the system see what it's been missing. Ninety percent of the time, when teams struggle, it's not the team that needs fixing—it's the soil they're planted in.   Self-reflection Question: What teams in your organization are maintaining critical systems but remain invisible to leadership, and what would happen if you made their value explicit? Featured Book of the Week: More Time to Think by Nancy Kline Alidad describes Nancy Kline's More Time to Think as transformative for his facilitation practice. While many Scrum Masters focus on filling space and driving conversations forward, this book teaches the opposite—how to create space and listen deeply. "It teaches you to create a space, not to fill it," Alidad explains. The book explores how to design containers—meetings, workshops, retrospectives—that allow deeper thinking to emerge naturally among team members.   For Alidad, the book answered a fundamental question: "How do you help people to find the solution among themselves?" It transformed his approach from facilitation to liberation, helping teams slow down so they can think more clearly. He first encountered the audiobook and was so impacted that he explored both "Time to Think" and this follow-up. While both are valuable, "More Time to Think" resonated more deeply with his coaching philosophy. The book pairs beautifully with systems thinking, helping Scrum Masters understand that creating the right conditions for thinking is often more powerful than providing the right answers. In this segment, we also refer to the book Confronting our freedom, by Peter Block et al.    [The Scrum Master Toolbox Podcast Recommends]

Alidad Hamidi: When Silence Becomes Your Most Powerful Coaching Tool 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 purposefully designed a moment of silence. Staying in the anxiety of being silenced. Do not interrupt the team. Put the question there, let them come up with a solution. It is very hard. But very effective." - Alidad Hamidi   Alidad walked into what seemed like a straightforward iteration manager role—what some use, instead of Scrum Master. The organization was moving servers to the cloud, a transformation with massive implications. When leadership briefed him on the team's situation, they painted a clear picture of challenges ahead. Yet when Alidad asked the team directly about the transformation's impact, the response was uniform: "Nothing."   But Alidad knew better. After networking with other teams, he discovered the truth—this team maintained software generating over half a billion dollars in revenue, and the transformation would fundamentally change their work. When he asked again, silence filled the room. Not the comfortable silence of reflection, but the heavy silence of fear and mistrust. Most facilitators would have filled that void with words, reassurance, or suggestions. Alidad did something different—he waited. And waited. For what felt like an eternity, probably a full minute, he stood in that uncomfortable silence, about to leave the room.   Then something shifted. One team member picked up a pen. Then another joined in. Suddenly, the floodgates opened. Debates erupted, ideas flew, and the entire board filled with impacts and concerns. What made the difference? Before that pivotal moment, Alidad had invested in building relationships—taking the team to lunch, standing up for them when managers blamed them for support failures, showing through his actions that he genuinely cared. The team saw that he wasn't there to tell them how to do their jobs. They started to trust that this silence wasn't manipulation—it was genuine space for their voices. This moment taught Alidad a profound lesson about Open Systems Theory and Socio-Technical systems—sometimes the most powerful intervention is creating space and having the courage to hold it.   Self-reflection Question: When was the last time you designed a moment of silence for your team, and what held you back from making it longer?   [The Scrum Master Toolbox Podcast Recommends]

Karim Harbott: Don't Scale Dysfunction—Fix the Team First 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.   "How do you define the success of a football manager? Football managers are successful when the team is successful. For Scrum Masters it is also like that. Is the team better than it was before?" - Karim Harbott   Karim uses a powerful analogy to define success for Scrum Masters: think of yourself as a football manager. A football manager isn't successful because they personally score goals—they're successful when the team wins. The same principle applies to Scrum Masters. Success isn't measured by how many problems you solve or how busy you are. It's measured by whether the team is better than they were before.  Are they more self-organizing? More effective? More aligned with organizational outcomes?  This requires a mindset shift. Unlike sprinters competing individually, Scrum Masters succeed by enabling others to be better.  Karim recommends involving the team when defining success—what does "better" mean to them? He also emphasizes linking the work of the team to organizational objectives. When teams understand how their efforts contribute to broader goals, they become more engaged and purposeful. But there's a critical warning: don't scale dysfunction! If a team isn't healthy, improving it is far more important than expanding your coaching to more teams.  A successful Scrum Master creates teams that don't need constant intervention—teams that can manage themselves, make decisions, and deliver value consistently. Just like a great football manager builds a team that plays brilliantly even when the manager isn't on the field.   Self-reflection Question: Is your team more capable and self-sufficient than they were six months ago, or have they become more dependent on you? Featured Retrospective Format for the Week: Systems Modeling with Causal Loop Diagrams "It shows how many aspects of the system there are and how things are interconnected. This helps us see something that we would not come up with in normal conversations." - Karim Harbott   Karim recommends using systems modeling—specifically causal loop diagrams—as a retrospective format. This approach helps teams visualize the complex interconnections between different aspects of their work. Instead of just listing what went wrong or right, causal loop diagrams reveal how various elements influence each other, often uncovering hidden feedback loops and unintended consequences.  The power of this format is that it surfaces insights the team wouldn't discover through normal conversation. Teams can then think of their retrospective actions as experiments—ways to interact with the system to test hypotheses about what will improve outcomes. This shifts retrospectives from complaint sessions to scientific inquiry, making them far more actionable and engaging. If your team is struggling with recurring issues or can't seem to break out of patterns, systems modeling might reveal the deeper dynamics at play.   [The Scrum Master Toolbox Podcast Recommends]

Are You Protecting Your Team Against the Right Thing? - Mike CohnA lot has been written and said about the responsibility of a Scrum Master to protect the team.Examples of protecting the team typically involve running interference with well-meaning but overzealous product owners, stakeholders, and managers. Teams run into trouble all the time from people who want it all now or who keep adding more work in the middle or a sprint. Scrum Masters keep all that noise away so that the team can focus on delivery.But if you are only focused on problems coming from squeaky wheels, you're missing one of the biggest dangers out there: complacency.Agile is about continually getting better. I don't care how good a team is today; if they aren't better a year from now, they're not agile.Complacency can creep in when a team sees some initial improvement from adopting an agile approach. Team members will notice how improved they are and think that's enough.But there's almost always room for further improvement.Some teams become complacent about their process and stop looking for ways to deliver more value each iteration. Still other teams become complacent in seeking out new engineering practices that could make the team even better.Protect your team from complacency by setting high expectations and encouraging the team to set even higher expectations of their own performance.Teams that refuse to settle for the status quo are teams that advance from good to great.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/

Karim Harbott: The Day I Discovered I Was a Scrum Project Manager, Not a Scrum Master 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 was telling the team what to do, instead of helping the team to be better on their own. There's a lot more to being a Scrum Master than Agile—working with people is such a different skillset." - Karim Harbott   Karim thought he had mastered Scrum. He had read the books, understood the framework, and was getting things done. His team seemed to be moving forward smoothly—until he stepped away for a few weeks.  But, when he returned, everything had fallen apart. The team couldn't function without him constantly directing their work. That's when Karim realized he had fallen into one of the most common anti-patterns in Agile: the Scrum Project Manager.  Instead of enabling his team to be more effective, he had become their bottleneck. Every decision flowed through him, every task needed his approval, and the team had learned to wait for his direction rather than taking ownership themselves. The wake-up call was brutal but necessary.  Karim discovered that pushing project management responsibilities to the people doing the work—as David Marquet advocates—was far more powerful than being the hero who solves all problems. The real skill wasn't in telling people what to do; it was in creating an environment where they could figure it out themselves. Geoff Watts calls this servant leadership, and Karim learned it the hard way: a great Scrum Master makes themselves progressively less necessary, not more indispensable.   Self-reflection Question: Are you enabling your team to be more effective, or have you become the person they can't function without?   [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: The PONO—Product Owners in Name Only and How They Destroy 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: Collaborative, Present, and Clear in Vision   "She was collaborative, and that meant that she was present—the opposite of the MIA product owner. She came, and she sat with the team, and she worked with them side by side. Even when she was working on something different, she'd be there, she'd be available." - Darryl Wright   Darryl shares an unusual story about one of the best Product Owners he's ever encountered—someone who had never even heard of Agile before taking the role. Working for a large consulting company with 170,000 staff worldwide, they faced a difficult project that nobody wanted to do. Darryl suggested running it as an Agile project, but the entire team had zero Agile experience. The only person who'd heard of Agile was a new graduate who'd studied it for one week at university—he became the Scrum Master. The executive sponsor, with her business acumen and stakeholder management skills, became the Product Owner despite having no idea what that meant.  The results were extraordinary: an 18-month project completed in just over 7 months, and when asked about the experience, the team's highest feedback was how much fun they had working on what was supposed to be an awful, difficult project. Darryl attributes this success to mindset—the team was open and willing to try something new.  The Product Owner brought critical skills to the role even without technical Agile knowledge: She was collaborative and present, sitting with the team and remaining available. She was decisive, making prioritization calls clearly so nobody was ever confused about priorities. She had excellent communication skills, articulating the vision with clarity that inspired the team. Her stakeholder management capabilities kept external pressures managed appropriately. And her business acumen meant she instantly understood conversations about value, time to market, and customer impact.  Without formal training, she became an amazing Product Owner simply by being open, willing, and committed. As Darryl reflects, going from never having heard of the role to being an inspiring Product Owner in 7 months was incredible—one of the most successful projects and teams he's ever worked with.   Self-reflection Question: If you had to choose between a Product Owner with deep Agile certification and no business skills, or one with strong business acumen and willingness to learn—which would serve your team better? The Bad Product Owner: The PONO—Product Owner in Name Only   "The team never saw the PO until the showcase. And so, the team would come along with work that they deemed was finished, and the product owner had not seen it before because he wasn't around. So he would be seeing it for the first time in the showcase, and he would then accept or reject the work in the showcase, in front of other stakeholders." - Darryl Wright   The most destructive anti-pattern Darryl has witnessed was the MIA—Missing in Action—Product Owner, someone who was a Product Owner in Name Only (PONO). This senior business person was too busy to spend time with the team, only appearing at the sprint showcase. The damage this created was systematic and crushing. The team would build work without Product Owner engagement, then present it in the showcase looking to be proud of their accomplishment.  The PO, seeing it for the first time, would accept or reject the work in front of stakeholders. When he rejected it, the team was crushed, deflated, demoralized, and made to look like fools in front of senior leaders—essentially thrown under the bus. This pattern violates multiple principles of Agile teamwork. First, there's no feedback loop during the sprint, so the team works blind, hoping they're building the right thing. Second, the showcase becomes a validation ceremony rather than a collaborative feedback session, creating a dynamic of subservience rather than curiosity. The team seeks approval instead of engaging as explorers discovering what delivers customer value together. Third, the PO positions themselves as judge rather than coach—extracting themselves from responsibility for what's delivered while placing all blame on the team.  As Deming's quote reminds us, "A leader is a coach, not a judge." When the PO takes the judge role, they're betraying fundamental Agile values.  The responsibility for what the team delivers belongs strictly to the Product Owner; the team owns how it's delivered.  When Darryl encounters this situation as a Scrum Master, he lobbies intensely with the PO: "Even if you can't spare any other time for the entire sprint, give us just one hour the night before the showcase." That single hour lets the team preview what they'll present, getting early yes/no decisions so they never face public rejection. The basic building block of any Agile or Scrum way of working is an empowered team—and this anti-pattern strips all empowerment away.   Self-reflection Question: Does your Product Owner show up as a coach who's building something together with the team, or as a judge who pronounces verdicts? How does that dynamic shape what your team is willing to try?   [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: The Retrospective Formats That Actually Generate Change 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. "My success is, how much have I helped the team achieve what they want? If what they want is to uplift quality, or to reduce their time to market, well then, my success is helping them achieve that." - Darryl Wright When Darryl enters a new organization, he's often told his success will be measured by percentage of Agile adoption or team maturity assessment scores. His response is direct: those are vanity metrics that show something for its own sake, not real success. True success requires multiple measures, carefully balanced to prevent gaming and to capture both the human and business dimensions of work. Darryl advocates balancing quantitative metrics like lead time and flow efficiency with qualitative measures like employee happiness and team self-assessment of productivity. He balances business outcomes like customer satisfaction and revenue with humanity metrics that track the team's journey toward high performance. Most importantly, Darryl believes his success metrics should be co-created with the team. If he's there to help the team, then success must be defined by how much he's helped them achieve what they want—not what he wants. When stakeholders fixate on output metrics like "more story points," Darryl uses a coaching approach to shift the conversation toward outcomes and value. "Would you be happy if your team checked off more boxes, but your customers were less happy?" he asks. This opens space for exploring what they really want to achieve and why it matters. The key is translating outputs into impacts, helping people articulate the business value or customer experience improvement they're actually seeking. As detailed in Better Value, Sooner, Safer, Happier by Jonathan Smart, comprehensive dashboards can track value across multiple domains simultaneously—balancing speed with quality, business success with humanity, quantitative data with qualitative experience. When done well, Agile teams can be highly productive, highly successful, and have high morale at the same time. We don't have to sacrifice one for the other—we can have both. Self-reflection Question: If your team could only track two metrics for the next sprint, what would they choose? What would you choose? And more importantly, whose choice should drive the selection? Featured Retrospective Format for the Week: The 4 L's and Three Little Pigs Darryl offers two favorites, tailored to different contexts. For learning environments, he loves the 4 L's retrospective: Liked, Learned, Lacked, and Longed For. This format creates space for teams to reflect on their learning journey, surfacing insights about what worked, what was missing, and what they aspire to moving forward. For operational environments, he recommends the Three Little Pigs retrospective, which brilliantly surfaces team strengths and weaknesses through a playful metaphor. The House of Straw represents things the team is weak at—nothing stands up, everything falls over. The House of Sticks is things they've put structure around, but it doesn't really work. The House of Bricks represents what they're solid on, what they can count on every time. Then comes the most important part: identifying the Big Bad Wolf—the scary thing, the elephant in the room that nobody wants to talk about but everyone knows is there. This format creates psychological safety to discuss the undiscussable. Darryl emphasizes two critical success factors for retrospectives: First, vary your formats. Teams that hear the same questions sprint after sprint will disengage, asking "why are you asking me again?" Different questions provide different lenses, generating fresh insights. Second, ensure actions come out of every retro. Nothing kills engagement faster than suggestions disappearing into the void. When people see their ideas lead to real changes, they'll eagerly return to the next retrospective. And don't forget to know your team—if they're sports fans, use sports retros; if they're scientists, use space exploration themes. Just don't make the mistake of running a "sailboat retro" with retiring mainframe engineers who'll ask if you think they're kindergarten children. For more retrospective formats, check out Retromat. [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: Why AI Adoption Will Fail Just Like Agile Did—Unless We Change 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. "People are looking to AI to solve their problems, and they're doing it in the same way that they previously looked to Agile to solve their problems for them. The problem with that is, of course, that Agile doesn't solve problems for you. What it does is it shines a light on where your problems are." - Darryl Wright The world has gone AI crazy, and Darryl sees history repeating itself in troubling ways. Organizations are rushing to adopt AI with the same magical thinking they once applied to Agile—believing that simply implementing the tool will solve their fundamental problems. But just as Agile reveals problems rather than solving them, AI will do the same. Worse, AI threatens to accelerate existing problems: if you have too many things moving at once, AI won't fix that, it will amplify the chaos. If you automate a bad process, you've simply locked in badness at higher speed. As Darryl points out, when organizations don't understand that AI requires them to still do the hard work of problem-solving, they're setting themselves up for disillusionment, and in five or twenty years, we'll hear "AI is dead" just like we now hear "Agile is dead." The challenge for Scrum Masters and Agile coaches is profound: how do you help people with something they don't know they need? The answer lies in returning to first principles. Before adopting any tool—whether Agile or AI—organizations must clearly define the problem they're trying to solve. As Einstein reportedly said, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions." Value stream mapping becomes essential, allowing teams to visualize where humans and AI agents should operate, with clear handovers and explicit policies. The cognitive load on software teams will increase dramatically as AI generates more code, more options, and more complexity. Without clear thinking about problems and deliberate design of systems, AI adoption will follow the same disappointing trajectory as many Agile adoptions—lots of activity, little improvement, and eventually, blame directed at the tool rather than the system. Self-reflection Question: Are you adopting AI to solve a clearly defined problem, or because everyone else is doing it? If you automated your current process with AI, would you be locking in excellence or just accelerating dysfunction? [The Scrum Master Toolbox Podcast Recommends]