Podcast appearances and mentions of will angela

Karim Harbott: From Requirements Documents to Customer Obsession—Redefining the PO Role 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: Strategic, Customer-Obsessed, and Vision-Driven   "The PO role in the team is strategic. These POs focus on the customer, outcomes, and strategy. They're customer-obsessed and focus on the purpose and the why of the product." - Karim Harbott   Karim believes the industry fundamentally misunderstands what a Product Owner should be. The great Product Owners he's seen are strategic thinkers who are obsessed with the customer. They don't just manage a backlog—they paint a vision for the product and help the entire team become customer-obsessed alongside them.  These POs focus relentlessly on outcomes rather than outputs, asking "why are we building this?" before diving into "what should we build?" They understand the purpose of the product and communicate it compellingly.  Karim references Amazon's "working backwards" approach, where Product Owners start with the customer experience they want to create and work backwards to figure out what needs to be built. Great POs also embrace the framework of Desirability (what customers want), Viability (what makes business sense), Feasibility (what's technically possible), and Usability (what's easy to use). While the PO owns desirability and viability, they collaborate closely with designers on usability and technical teams on feasibility.  This is critical: software is a team sport, and great POs recognize that multiple roles share responsibility for delivery. Like David Marquet teaches, they empower the team to own decisions rather than dictating every detail. The result? Teams that understand the "why" and can innovate toward it autonomously.   Self-reflection Question: Does your Product Owner paint a compelling vision that inspires the team, or do they primarily manage a list of tasks? The Bad Product Owner: The User Story Writer "The user story writer PO thinks it's their job to write full, long requirements documents, put it in JIRA, and assign it to the team. This is far away from what the PO role should be." - Karim Harbott   The anti-pattern Karim sees most often is the "User Story Writer" Product Owner. These POs believe their job is to write detailed requirements documents, load them into JIRA, and assign them to the team. It's essentially waterfall disguised as Agile—treating user stories like mini-specifications rather than conversation starters. This approach completely misses the collaborative nature of product development.  Instead of engaging the team in understanding customer needs and co-creating solutions, these POs hand down fully-formed requirements and expect the team to execute without question. The problem is that this removes the team's ownership and creativity. When POs act as the sole source of product knowledge, they become bottlenecks.  The team can't make smart tradeoffs or innovate because they don't understand the underlying customer problems or business context. Using the Desirability-Viability-Feasibility-Usability framework, bad POs try to own all four dimensions themselves instead of recognizing that designers, developers, and other roles bring essential perspectives. The result is disengaged teams, slow delivery, and products that miss the mark because they were built to specifications rather than shaped by collaborative discovery. Software is a team sport—but the User Story Writer PO forgets to put the team on the field.   Self-reflection Question: Is your Product Owner engaging the team in collaborative discovery, or just handing down requirements to be implemented?   [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]

Karim Harbott: You Can't Make a Flower Grow Faster—The Oblique Approach to Shaping Culture 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 can I make a flower grow faster? Culture is a product of the behaviors of people in the system." - Karim Harbott   For Karim, one of the biggest challenges—and enablers—in his current work is creating a supporting culture. After years of learning what doesn't work, he's come to understand that culture isn't something you can force or mandate. Like trying to make a flower grow faster by pulling on it, direct approaches to culture change often backfire.  Instead, Karim uses what he calls the "oblique approach"—changing culture indirectly by adjusting the five levers: leadership behaviors, organizational structure, incentives, metrics, and systems. Leadership behaviors are particularly crucial.  When leaders step back and encourage ownership rather than micromanaging, teams transform. Incentives have a huge impact on how teams work—align them poorly, and you'll get exactly the wrong behaviors.  Karim references Team of Teams by General Stanley McChrystal, which demonstrates how changing organizational structure and leadership philosophy can unlock extraordinary performance. He also uses the Competing Values Framework to help leaders understand different cultural orientations and their tradeoffs. But the most important lesson? There are always unexpected consequences. Culture change requires patience, experimentation, and a willingness to observe how the system responds. You can't force a flower to grow, but you can create the conditions where it thrives.   Self-reflection Question: Are you trying to change your organization's culture directly, or are you adjusting the conditions that shape behavior?   [The Scrum Master Toolbox Podcast Recommends]

Karim Harbott: Why System Design Beats Individual Coaching Every 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.   "You can't change people, but you can change the system. Change the environment, not the people." - Karim Harbott   Karim was coaching a distributed team that was struggling with defects appearing constantly during sprints. The developers and testers were at different sites, and communication seemed fractured. But Karim knew from experience that when teams are underperforming, the problem usually isn't the people—it's the system they're working in. He stepped back to examine the broader context, implementing behavior-driven development(BDD) and specification by example to improve clarity through BDD scenarios.  But the defects persisted.  Then, almost by accident, Karim discovered the root cause: the developers and testers were employed by different companies. They had competing interests, different incentives, and fundamentally misaligned goals. No amount of coaching the individuals would fix a structural problem like that.  It took months, but eventually the system changed—developers and testers were reorganized into unified teams from the same organization. Suddenly, the defects dropped dramatically. As Jocko Willink writes in Extreme Ownership, when something isn't working, look at the system first. Karim's experience proves that sometimes the most compassionate thing you can do is stop trying to fix people and start fixing the environment they work in.   Self-reflection Question: When your team struggles, do you look at the people or at the system they're embedded in? Featured Book of the Week: Scaling Lean and Agile Development by Craig Larman and Bas Vodde "This book was absolute gold. The way it is written, and the tools they talk about went beyond what I was talking about back then. They introduced many concepts that I now use." - Karim Harbott   Karim discovered Scaling Lean and Agile Development by accident, but it resonated with him immediately. The concepts Craig Larman and Bas Vodde introduced—particularly around LeSS (Large-Scale Scrum)—went far beyond the basics Karim had been working with. The book opened his eyes to system-level thinking at scale, showing how to maintain agility even as organizations grow.  It's packed with practical tools and frameworks that Karim still uses today. For anyone working beyond a single team, this book provides the depth and nuance that most scaling frameworks gloss over. Also worth reading: User Stories Applied by Mike Cohn, another foundational text that shaped Karim's approach to working with teams.   [The Scrum Master Toolbox Podcast Recommends]

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]

Darryl Wright: The Agile Team That Committed to Failure for 18 Sprints Straight 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. "As Deming said, a bad system will beat a good person every time." - Darryl Wright Darryl was called in to help a struggling team at a large energy retailer. The symptoms seemed straightforward—low morale, poor relationships, and chronic underdelivery. But as he asked questions, a heartbreaking pattern emerged. The team had been "committing" to 110 story points per sprint while consistently delivering only 30. For 18 sprints. When Darryl asked why the team would commit to numbers they couldn't possibly achieve, the answer was devastating: "The business needs that much." This wasn't a problem of skill or capability—it was learned helplessness in action. Sprint after sprint, the team experienced failure, which made them more despondent and less effective, creating a vicious downward spiral. The business lost trust, the team lost confidence, and everyone was trapped in a system that guaranteed continued failure. When Darryl proposed the solution—committing to a realistic 30 points—he was told it was impossible because "the business needs 110 points." But the business wasn't getting 110 points anyway. They were getting broken promises, a demoralized team, stress leave, high churn, and a relationship built on distrust. Darryl couldn't change the system in that case, but the lesson was clear: adult people who manage their lives perfectly well outside work can become completely helpless inside work when the system repeatedly tells them their judgment doesn't matter. As Ricardo Semler observes in Maverick!, people leave their initiative at the door when organizations create systems that punish honest assessment and reward false promises. Self-reflection Question: Is your team committing to what they believe they can achieve, or to what they think someone else wants to hear? What would happen if they told the truth? Featured Book of the Week: Better Value, Sooner, Safer, Happier by Jonathan Smart Darryl describes Better Value, Sooner, Safer, Happier by Jonathan Smart as a treasure trove of real-life experience from people who have "had their sleeves rolled up in the trenches" for decades. What he loves most is the authenticity—the authors openly share not just their successes, but all the things that didn't work and why. One story that crystallizes the book's brilliance involves Barclays Bank and their ingenious approach to change adoption. Facing resistance from laggards who refused to adopt Agile improvements despite overwhelming social proof, they started publishing lists of "most improved teams." When resisters saw themselves at the bottom of these public lists, they called to complain—and were asked, "Did you have improvements we didn't know about?" The awkward pause would follow, then the inevitable question: "How do I get these improvements?" Demand creation at its finest. Darryl particularly appreciates that the authors present at conferences saying, "Let me tell you about all the things we've stuffed up in major agile transformations all around the world," bringing genuine humility and practical wisdom to every page. [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: When Enthusiasm Became Interference—Learning to Listen as 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.   "Wait stands for Why Am I Talking? Just ask yourself, wait, why am I talking? Is this the right moment for you to give an idea, or is this the right moment to just listen and let them have space to come up with ideas?" - Darryl Wright   Early in his Agile journey, Darryl was evangelically enthusiastic about the principles and practices that had transformed his approach to leadership. He believed he had discovered the answers people were seeking, and his excitement manifested in a problematic pattern—he talked too much. Constantly jumping in with solutions, ideas, and suggestions, Darryl dominated conversations without realizing the impact. Then someone pulled him aside with a generous gift: "You're not really giving other people time to come up with ideas or take ownership of a problem."  They introduced him to WAIT—Why Am I Talking?—an acronym that would fundamentally shift his coaching approach. This simple tool forced Darryl to pause before speaking and examine his motivations. Was he trying to prove himself? Did he think he knew better? Or was this genuinely the right moment to contribute? As he practiced this technique, Darryl discovered something profound: when he held space and waited, others would eventually step forward with insights and solutions.  The concept of "small enough to try, safe enough to fail" became his framework for deciding when to intervene. Not every moment requires a Scrum Master to step in—sometimes the most powerful coaching happens in silence. By developing better skills in active listening and learning to hold space for others, Darryl transformed from someone who provided all the answers into someone who created the conditions for shared leadership to emerge.   In this episode, we refer to David Marquet's episodes on the podcast for practical techniques on holding space and enabling leadership in others.   Self-reflection Question: When was the last time you caught yourself jumping in with a solution before giving your team space to discover it themselves? What would happen if you waited just five more minutes?   [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: How to Coach POs Who Treat Developers Like Mindless Robots In this episode, we refer to the previous episodes with David Marquet, author of Turn the Ship Around! The Great Product Owner: Trust and the Sprint Review That Changes Everything 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. "She was like, oh my gosh, I've never seen this before, I didn't think it was possible. I just saw you deliver stuff in 2 weeks that I can actually use." - Alex Sloley In 2011, Alex worked with a client organization creating software for external companies. They needed a Product Owner for a new Agile team, and a representative from the client—who had never experienced Scrum—volunteered for the role. She was initially skeptical, having never witnessed or heard of this approach. Alex gently coached her through the process, asking her to trust the team and be patient. Then came the first Sprint Review, and everything changed. For the first time in her career, she saw working product delivered in just two weeks that she could actually touch, see, and use. Her head exploded with possibility. Even though it didn't have everything and wasn't perfect, it was remarkably good. That moment flipped a switch—she became fully engaged and transformed into a champion for Agile adoption, not just for the team but for the entire company. Alex reflects that she embodied all five Scrum values: focus (trusting the team's capacity), commitment (attending and engaging in all events), openness (giving the new approach a chance), respect (giving the team space to succeed), and courage (championing an unfamiliar process). The breakthrough wasn't about product ownership techniques—it was about creating an experience that reinforced Scrum values, allowing her to see the potential of a bright new future. Self-reflection Question: What practices, techniques, or processes can you implement that will naturally and automatically build the five Scrum values in your Product Owner? The Bad Product Owner: When Control Becomes Domination 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 basically just owned the team. The developers on the team might as well have been mindless robots, because they were being assigned all the work, told how much work they could do in a sprint, what the work was." - Alex Sloley In 2018, while working with five interconnected Product Owners, Alex observed a Sprint Planning session that revealed a severe anti-pattern. One Product Owner completely controlled everything, telling the team exactly what work they would take into the Sprint, assigning specific work to specific people by name, and dictating precisely how they would implement solutions down to technical details like which functions and APIs to use. The developers were reduced to helpless executors with no autonomy, while the Scrum Master sat powerless in the corner. Alex wondered what caused this dynamic—was the PO a former project manager? Had the team broken trust in the past? What emotional baggage or trauma led to this situation? His approach started with building trust through coffee meetings and informal conversations, crucially viewing the PO not as the problem but as someone facing their own impediment. He reframed the challenge as solving the Product Owner's problem rather than fixing the Product Owner. When he asked, "Why do you have to do all this? Can't you trust the team?" and suggested the PO could relax if they delegated, the response was surprisingly positive. The PO was willing to step back once given permission and assurance. Alex's key lesson: think strategically about how to build trust and who needs to build trust with whom. Sometimes the person who appears to be creating problems is actually struggling under their own burden. Self-reflection Question: When you encounter a controlling Product Owner, do you approach the situation as "fixing" the PO or as "solving the PO's problem"? How might this reframe change your coaching strategy? [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: Why Sticky Notes Are Your Visualization Superpower in Retrospectives Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Like the smell, the vibe is something you feel. If you're having a successful impact on the organization or on teams as a Scrum Master, you can feel it, you can smell it. It's intangible." - Alex Sloley Alex introduces a compelling concept from Sumantra Ghoshal about "the smell of the workplace"—you can walk into an environment and immediately sense whether it smells like fresh strawberries and cream or a dumpster fire. In Australia, there's a cultural reference from the movie "The Castle" about "the vibe of the thing," and Alex emphasizes that as a successful Scrum Master, you can feel and smell when you're having an impact. While telling executives you're measuring "vibe" might be challenging, Alex shares three concrete ways he's measured success. The key insight is that success isn't always measurable in traditional ways, but successful Scrum Masters develop an intuition for sensing when their work is making a meaningful difference. Self-reflection Question: Can you articulate the "vibe" or "smell" of your current team or organization? What specific indicators tell you whether your Scrum Master work is truly making an impact beyond the metrics? Featured Retrospective Format for the Week: Sticky Notes for Everything Alex champions any retrospective format that includes sticky notes, calling them a "visualization superpower." With sticky notes, teams can visualize anything—the good, the bad, improvements, options, possibilities, and even metrics. They make information transparent, which is critical for the inspect-and-adapt cycle that forms the heart of Scrum. Alex emphasizes being strategic about visualization: identify a challenge, figure out how to make it visual, and then create experiments around that visualization. Once something becomes visible, magic happens because the team can see patterns they've never noticed before. You can use different sizes, colors, and positions to visualize constraints in the system, including interruptions, unplanned work, blocker clustering, impediments, and flow. This approach works not just in retrospectives but in planning, reviews, and daily scrums. The key principle is that you must have transparency in order to inspect, and you must inspect to adapt. Alex's practical advice: be strategic about what you choose to visualize, involve the team in determining how to make challenges visible, and watch as the transparency naturally leads to insights and improvement ideas. [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: Coaching Teams Trapped Between Agile Aspirations and Organizational Control 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 team says, oh, we want to try to do things this way, and the org keeps coming back and saying stuff like, no, no, no, you can't do that, because in this org, we don't allow that." - Alex Sloley Alex shares his current challenge working with a 10-person pilot Scrum team within a 1,500-person organization that has never done Agile before. While the team appears open-minded and eager to embrace agile ways of working, the organization continuously creates impediments by dictating how the team must estimate, break down work, and operate. Management tells them "the right way" to do everything, from estimation techniques to role-based work assignments, even implementing RACI matrices that restrict who can do what type of work. Half the team has been with the organization for six months or less, making it comfortable to simply defer to authority and follow organizational rules. Through coaching conversation, Alex explores whether the team might be falling into learned helplessness or simply finding comfort in being told what to do—both positions that avoid accountability. His experimental approach includes designing retrospective questions to help the team reflect on what they believe they're empowered to do versus what management dictates, and potentially using delegation cards to facilitate conversations about decision-making authority. Alex's key insight is recognizing that teams may step back from empowerment either out of fear or comfort, and identifying which dynamic is at play requires careful, small experiments that create safe spaces for honest dialogue. Self-reflection Question: When your team defers to organizational authority, are they operating from learned helplessness, comfort in avoiding accountability, or genuine respect for hierarchy? How can you design experiments to uncover the real dynamic at play? [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: When Toxic Leadership Creates Teams That Self-Destruct 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 would take notes at every team meeting, so that later on they could argue with team members about what they committed to, and what they said in meetings." - Alex Sloley Alex recounts working with a small team where a project manager created such a toxic environment that one new hire quit after just eight hours on the job. This PM would belittle team members publicly, take detailed notes to use as weapons in contract negotiations, and dominate the team through intimidation. The situation became so severe that one team member sent an email that sounded like a suicide note. When the PM criticized Alex's "slide deck velocity," comparing four slides per 15 minutes to Alex's one, he realized the environment was beyond salvaging. Despite coaching the team and attempting to introduce Scrum values, Alex ultimately concluded that management was encouraging this behavior as a control mechanism. The organization lacked trust in the team, creating learned helplessness where team members became submissive and unable to resist. Sometimes, the most important lesson for a Scrum Master is recognizing when a system is too toxic to change and having the courage to walk away. Alex emphasizes that respect—one of the core Scrum values—was completely absent, making any meaningful transformation impossible. In this segment, we talk about “learned helplessness”.  Self-reflection Question: How do you recognize when a toxic environment is being actively encouraged by the system rather than caused by individual behavior? What are the signs that it's time to exit rather than continue fighting? Featured Book of the Week: The Goal by Eliyahu M. Goldratt Alex describes his complex relationship with The Goal by Goldratt—it both inspires and worries him. He struggles with the text because the concepts are so deep and meaningful that he's never quite sure he's fully understood everything Goldratt was trying to convey. The book was difficult to read, taking him four times longer than other agile-related books, and he had to reread entire sections multiple times. Despite the challenge, the concepts around Theory of Constraints and systems thinking have stayed with him for years. Alex worries late at night that he might have missed something important in the book.  He also mentions reading The Scrum Guide at least once a week, finding new tidbits each time and reflecting on why specific segments say what they say. Both books share a common thread—the text that isn't in the text—requiring readers to dig deeper into the underlying principles and meanings rather than just the surface content. [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: The Sprint Planning That Wouldn't End - A Timeboxing Failure 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. "Although I knew about the steps of sprint planning, what I didn't really understand was the box of time versus the box of scope." - Alex Sloley Alex shares a critical learning moment from his first team as a Scrum Master. After six months in the role, during an eight-hour sprint planning session for a four-week sprint, he successfully completed the "what" portion but ran out of time before addressing "how." Rather than respecting the timebox, Alex forced the team to continue planning for another four hours the next day—blowing the timebox by 50%. This experience taught him a fundamental lesson: the difference between scope-boxing and timeboxing. In waterfall, we try to control scope while time slips away. In Scrum, we fix time and let scope adjust. Alex emphasizes that timeboxing isn't just about keeping meetings short—it's about limiting work in process and maintaining focus. His practical tip: use visible timers to train yourself and your teams to respect timeboxes. This mindset shift from controlling scope to respecting time remains one of the most important lessons for Scrum Masters. Self-reflection Question: How often do you prioritize completing a planned agenda over respecting the timebox? What message does this send to your team about the values you're reinforcing? [The Scrum Master Toolbox Podcast Recommends]

Renee Troughton: Analytics From Day One and Four Other Principles of Great POs 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. "Product owners who think about their products as just a backlog that I prioritize, and I get some detailed requirements from stakeholders, and I give that to the team... that's not empowering the team. And it's probably leading you to building the wrong thing, just faster." The Bad Product Owner: The Backlog Manager Without Vision Renee describes a pattern of Product Owners who don't understand product management—they lack roadmaps, strategy, and never speak to customers. These POs focus solely on backlogs, prioritizing detailed requirements from stakeholders without testing hypotheses or learning about their market. Taking an empathetic view, Renee notes these individuals may have fallen into the role without passion, never seeing what excellence looks like, and struggling with extreme time poverty. Product ownership is one of the hardest roles from a time perspective—dealing with legislative requirements, compliance, risk, fail-and-fix work, and constant incoming demands. Drowning in day-to-day urgency, they lack breathing space for strategic thinking.  These POs also struggle with vulnerability, feeling they should have all answers as leaders, making it difficult to admit knowledge gaps. Without organizational safety to fail, they can't demonstrate the confidence balanced with humility needed to test hypotheses and potentially be wrong. The result is building the wrong thing faster, without empowering teams or creating real value. Self-reflection Question: Are you managing your Product Owners' workload and supporting their strategic thinking time, or are you allowing them to drown in tactical work that prevents them from truly leading their products? The Great Product Owner: Analytics from Day One and Market Awareness "They really iterated, I think, 5 key principles quite consistently... the one thing that did really shape my thinking at that time was... Analytics from day one." Renee celebrates a Chief Product Owner who led 13 teams with extraordinary effectiveness. This PO consistently communicated five key principles, with "analytics from day one" being paramount—emphasizing the critical need to know immediately if new features work and understanding customer behavior from launch. This PO demonstrated deep market awareness, regularly spending time in Silicon Valley, understanding innovation trends and where the industry was heading. They maintained a clear product vision and could powerfully sell the dream to stakeholders.  Perhaps most impressively, they brought urgency during a competitive "space race" situation when a former leader left with intellectual property to build a competing product. Despite this pressure, they never allowed compromise on quality—rallying teams with mission and purpose while maintaining standards. This combination of strategic vision, market knowledge, data-driven decision-making, and balanced urgency created an environment where teams delivered excellence under competitive pressure. [The Scrum Master Toolbox Podcast Recommends]

Renee Troughton: From Lower-Order to Higher-Order Values in Scrum 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, as a senior leader, demonstrate vulnerability, it creates real magic in an organization where others can open up and be their authentic self." Renee defines success for Scrum Masters through deeply human values: integrity, holding her truth, being compassionately authentic, caring, open, honest, listening, and vulnerable. She emphasizes that vulnerability as a senior leader creates transformative magic in organizations, allowing others to bring their authentic selves to work. Drawing on Byron Katie's "Loving What Is" and Frederick Laloux's "Reinventing Organizations," Renee explains that many corporate organizations focus on lower-order values like results and performance, while more autonomous organizations prioritize higher-order values rooted in the heart. When having conversations with people, Renee connects with them as human beings first—not rushing to business if someone is struggling personally. Success means seeing people completely for who they are, not as resources to be changed or leveraged. The foundation for collaboration, empowerment, and autonomy is trust, respect, and safety. Renee emphasizes that without these fundamental values in place, everything else implodes. She demonstrates how vulnerability, active listening, and accepting people where they are creates the fertile ground for successful teams and organizations. Self-reflection Question: Do you demonstrate vulnerability as a leader, creating space for others to bring their authentic selves to work, or do you hide behind a professional facade that prevents genuine human connection? Featured Retrospective Format for the Week: Themed Retrospectives (Monopoly, Sports, Current Events) "It gave a freshness to it. And it gave almost like a livelihood or a joyfulness to it as an activity as well." Renee recommends themed retrospectives like the Monopoly Retro or sports-themed formats that use current events or cultural references (aka metaphor retrospectives). While working at a consultancy, they would theme retrospectives every week around different topics—football, news events, or various scenarios—using collages of pictures showing different emotions (upset, angry, happy). Team members would identify with feelings and reframe their week within the theme's context, such as "it was a rough game" or "we didn't score enough goals." The brilliance of this approach is covering the same retrospective questions while bringing freshness, creativity, and joyfulness to the activity. These metaphorical formats allow teams to verbalize things that aren't easily expressible in structured formats, triggering different perspectives and creative thinking. The format stays consistent while feeling completely new, maintaining engagement while avoiding retrospective fatigue. [The Scrum Master Toolbox Podcast Recommends]

Renee Troughton: Managing Dependencies and Downstream Bottlenecks in Scrum 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. "For the actual product teams, it's not a problem for them... It's more the downstream teams that aren't the product teams, that are still dependencies... They just don't see that work until, hey, we urgently need this." Renee brings a dual-edged challenge from her current work with dozens of teams across multiple business lines. While quarterly planning happens at a high level, small downstream teams—middleware, AI, data, and even non-technical teams like legal—are not considered in the planning process. These teams experience unexpected work floods with dramatic peaks and troughs throughout the quarter. The product teams are comfortable with ambiguity and incremental delivery, but downstream service teams don't see work coming until it arrives urgently. Through a coaching conversation, Renee and Vasco explore multiple experimental approaches: top-to-bottom stack ranking of initiatives, holding excess capacity based on historical patterns, shared code ownership where downstream teams advise rather than execute changes, and using Theory of Constraints to manage flow into bottleneck teams. They discuss how lack of discovery work compounds the problem, as teams "just start working" without identifying all players who need involvement. The solution requires balancing multiple strategies while maintaining an experimentation mindset, recognizing that complex systems require sensing our way toward solutions rather than predicting them. Self-reflection Question: Are you actively managing the flow of work to prevent downstream bottlenecks, or are you allowing your "downstream teams" to be repeatedly overwhelmed by last-minute urgent requests? [The Scrum Master Toolbox Podcast Recommends]

Renee Troughton: The Hidden Cost of Constant Restructuring in Agile Organizations Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Trust and safety are the most fundamental foundations of a team to perform. And so you are just breaking the core of teams when you're doing this." Renee challenges us to look beyond team dysfunction and examine the "dirty little secrets" in organizations—leadership-driven anti-patterns that destroy team performance. She reveals a cyclical pattern of constant restructuring that occurs every six months in many organizations, driven by leaders who avoid difficult performance management conversations and instead force people through redundancy rounds. This creates a cascade of fear, panic, and victim mindset throughout the organization. Beyond restructuring, Renee identifies other destructive patterns including the C-suite shuffle (where new CEOs bring in their own teams, cascading change throughout the organization) and the insourcing/outsourcing swings that create chaos over 5-8 year cycles. These high-level decisions drain productivity for months as teams storm and reform, losing critical knowledge and breaking the trust and safety that are fundamental for high performance. Renee emphasizes that as Agile coaches and Scrum Masters, we often don't feel empowered to challenge these decisions, yet they represent the biggest drain on organizational productivity. Self-reflection Question: Have you identified the cyclical organizational anti-patterns in your workplace, and do you have the courage to raise these systemic issues with senior leadership? Featured Book of the Week: Loving What Is by Byron Katie "It teaches you around how to reframe your thoughts in the day-to-day life, to assess them in a different light than you would normally perceive them to be." Renee recommends "Loving What Is" by Byron Katie as an essential tool for Scrum Master introspection. This book teaches practical techniques for reframing thoughts and recognizing that problems we perceive "out there" are often internal framing issues. Katie's method, called "The Work," provides a worksheet-based approach to introspection that helps identify when our perceptions create unnecessary suffering. Renee also highlights Marshall Rosenberg's "Nonviolent Communication" as a companion book, which uses language to tap into underlying emotions and needs. Both books offer practical, actionable techniques for self-knowledge—a critical skill for anyone in the Scrum Master role. The journey these books provide leads to inner peace through understanding that many challenges stem from how we internally frame situations rather than external reality. We have many episodes on NVC, Nonviolent Communication, which you can dive into and learn from experienced practitioners.  [The Scrum Master Toolbox Podcast Recommends]

Renee Troughton: How to Navigate Mandatory Deadlines in Scrum 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 said to the CIO at the time, we're not going to hit this. In fact, we'll be... I can actually tell you, we're gonna be 3 weeks late... And he said: ‘Just make it work!'" Renee shares a powerful story from her work on a mandatory legislative compliance project where reality clashed with executive expectations. Working with a team new to Agile, she carefully established velocity over two sprints and projected the delivery timeline. The challenge intensified when sales continued promising bespoke features to clients while the deadline remained fixed. Despite transparently communicating the team would miss the mandatory date by three weeks, leadership demanded she "just make it work" without providing solutions. Renee found herself creating a misleading burn-up chart to satisfy executive confidence, while the organization played a dangerous game of chicken—waiting for another implementer to admit delays first. This experience taught her the critical importance of courage in conversations with leaders and the need to clearly separate business decisions from development team responsibilities. Sometimes the best we can do is provide transparency and let leaders own the consequences of their choices. In this episode, we refer to the seminal book on large projects: The Mythical Man Month, by Frederick Brooks. Self-reflection Question: When faced with unrealistic demands from leadership, do you have the courage to maintain transparency about your team's reality, even when it means refusing to create false artifacts of confidence? [The Scrum Master Toolbox Podcast Recommends]

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

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

Tom Molenaar: Systemic Change Management—Making the Emotional Side of Change Visible 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 tend to skip the phase where we just give the person the space to grieve, to not know, instead of that, we tend to move to solutions maybe too quick." Tom faces a significant challenge as he prepares to start with new teams transitioning between value streams in a SAFe environment. The teams will experience multiple changes simultaneously - new physical locations, new team dependencies, and organizational restructuring. Tom applies systemic change management principles, outlining five critical phases: sense of urgency, letting go, not knowing, creation, and new beginning. He emphasizes the importance of making the emotional "understream" visible, giving teams space to grieve their losses, and helping them verbalize their feelings before moving toward solutions. In this episode, we refer to Systemic Change Management, an approach that views organizations as complex, interconnected systems—rather than collections of independent parts. Instead of focusing only on individual skills, isolated processes, or top-down directives, SCM works with the whole system (people, structures, culture, and external environment) to create sustainable transformation. Self-reflection Question: How comfortable are you with sitting in uncertainty and allowing teams to process change without immediately jumping to solutions? [The Scrum Master Toolbox Podcast Recommends]

Tom Molenaar: How to Spot and Fix Lack of Trust in Scrum 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 people don't speak up, it's because there's no trust. The team showed that they did not feel free to express their opinions." Tom describes working with a team that appeared to be performing well on the surface - they were reaching their goals and had processes in place. However, deeper observation revealed a troubling dynamic: a few dominant voices controlled discussions while half the team remained silent during ceremonies. Through one-on-ones, Tom discovered team members felt judged and unsafe to express their ideas. Using the Lencioni Pyramid as a framework, he helped the team address the fundamental lack of trust that was preventing constructive conflict and genuine collaboration. Featured Book of the Week: Empowered by Marty Cagan Tom recommends "Empowered" by Marty Cagan as a book that significantly influenced his approach to team coaching. The book focuses on empowering teams and organizations to deliver great products while developing ordinary people into extraordinary performing teams. Tom appreciates its well-structured approach that covers all necessary elements without getting lost in details. The book provides practical tools for effective coaching, including techniques for regular one-on-ones, active listening, constructive feedback, setting clear expectations, celebrating success, and creating a culture of learning from failure. [The Scrum Master Toolbox Podcast Recommends]

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

Terry Haayema: The Product Owner Who Made Retros Unsafe (And How We Fixed It) Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The biggest anti-pattern was that he made the retro unsafe... he would come to the retro and called people out for things that had not been done." The Bad Product Owner: The PO Who Made Retros Unsafe Terry describes a product owner who came from a management background focused on widgets and KPIs, completely unprepared for the collaborative nature of the product owner role. This person's biggest anti-pattern was making retrospectives unsafe by calling out individual team members for things not completed or not done to his satisfaction. When gentle coaching interventions failed, Terry took the dramatic step of excluding the PO from retrospectives entirely. Surprisingly, this shock treatment worked - when the PO asked why he wasn't invited, Terry used SBI feedback (Situation, Behavior, Impact) to help him understand how his actions were destroying team dynamics. The story has a positive ending, with the PO eventually understanding and changing his approach. In this segment, we refer to the Retrospective Prime Directive, and the SBI feedback framework. The Great Product Owner: The Customer Connector Terry's best product owner example saw their role not just as the voice of the customer, but as the connector between team and customers. Instead of relying solely on user stories and personas, this PO organized regular informal events where real customers and team members could meet, share pizza and beer, and have genuine conversations. These social connections led to deep customer understanding and resulted in their best feature ever - a simple addition that showed customers their last six orders for easy reordering. This feature increased both order frequency and size while dramatically improving the team's ability to empathize with their users. Self-reflection Question: How might you help your product owner move from being the voice of the customer to being the bridge that connects your team directly with real users? [The Scrum Master Toolbox Podcast Recommends]

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

Terry Haayema: When Consensus Becomes Paralysis—The Nemawashi Challenge For Agile Software Development 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 problem I'm facing is 'too much consensus'... we talk, bounce ideas, but we don't get going." Terry shares his current coaching challenge in a Japanese company where their cultural practice of Nemawashi (consensus building) has become a barrier to progress. While working across the entire organization, he's discovered that quality is suffering because teams aren't clear about desired outcomes before starting work. The excessive focus on building consensus means initiatives bounce between stakeholders without ever gaining momentum. Terry explains how he's experimenting with delaying detailed refinement to build shared understanding as teams progress, rather than trying to achieve perfect consensus upfront. He uses the metaphor of flying a plane - pilots don't stick rigidly to flight plans but constantly make small course corrections based on real-time feedback. Self-reflection Question: In your organization, what well-intentioned practices have become obstacles to the very outcomes they were designed to achieve? [The Scrum Master Toolbox Podcast Recommends]

Terry Haayema: The High Cost of Unsafe Agile Retrospectives Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "She was kind of like the mum for the team... she was actually the glue that held the team together." Terry tells the story of a team that was functioning like a feature factory until a business analyst became their champion and "team mom." This BA supported everyone through agile transformation and helped build trust and healthy conflict. However, when she mentioned something in a retrospective that led to her being put on performance management and eventually leaving, the team rapidly self-destructed. They lost their sense of belonging and teamness, retreating back to working as independent professionals rather than collaborating. The story illustrates how leadership actions can instantly destroy weeks or months of trust-building work, and how critical psychological safety is for sustainable team performance. For more critical points on how to be a great leader, check this episode with Captain David Marquet, a thought leader in the leadership space who wrote Turn the Ship Around!  Featured Book of the Week: The Five Dysfunctions of a Team by Patrick Lencioni Terry credits The Five Dysfunctions of a Team by Patrick Lencioni as massively influential in his career, particularly praising how Lencioni demonstrates that without trust as a foundation, teams cannot achieve anything else. The book's framework shows how lack of trust prevents healthy conflict, which prevents commitment, which prevents accountability, which prevents results. Terry found the way Lencioni illustrates these dysfunctions and their cascading effects to be incredibly valuable for understanding team dynamics and what's needed to build high-performing teams. In this segment, we also refer to Agile Software Development with Scrum, by Schwaber and Beedle. Self-reflection Question: What would happen to your team's dynamics if your most supportive, trust-building team member suddenly left tomorrow? [The Scrum Master Toolbox Podcast Recommends]

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

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

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

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

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

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

Bernie Maloney: Problems vs. Solutions: The Great Product Owner Distinction Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Strategic Problem Solver Bernie describes an exemplary Product Owner from a stealth program sponsored by a CTO, where the company needed to create new intellectual property. This Great Product Owner understood that Agile operates in three dimensions: most organizations only focus on outputs and delivery (first dimension), some reach outcomes (second dimension), but the truly great ones operate in the third dimension of strategic or business agility - defining problems worth solving. This Product Owner knew that high-performing teams need to understand what problem is worth solving rather than just receiving solutions to build. They embraced the Mobius loop approach, focusing on discovering the right problems rather than jumping straight to solutions. In this segment, we refer to the Mobius Loop, and to Steve Blank's work on the job of a startup.  We also refer to the episode with Elliott Parker on the critical importance of the “startup mindset” to foster innovation in larger organizations.  The Bad Product Owner: The Backlog Jockey with Authority Issues Bernie identifies the anti-pattern of Product Owners being treated as mere "backlog jockeys" by their organizations, which forces them into solution-building mode rather than problem-solving mode. These Product Owners don't understand the importance of saying "no" and lack clarity about intent and goals. The worst case Bernie encountered was a team manager who also served as Product Owner, wielding positional authority that shut down team communication. This person would interrupt daily scrums, causing teams to revert to waiting for direction rather than self-organizing. The combination of unclear intent and positional authority creates a toxic environment that destroys team autonomy and psychological safety. Self-reflection Question: Is your Product Owner focused on defining problems worth solving, or are they primarily managing a backlog of predetermined solutions? [The Scrum Master Toolbox Podcast Recommends]

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

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

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

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

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

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

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

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

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

Salum Abdul-Rahman: Learning to Communicate Value in Public and Non-Profit Sectors' Product Development Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Systematic Value Communicator Salum describes working with a Product Owner who had a PhD in data science on a public sector visualization project. This exceptional PO was extremely systematic in working with stakeholders and possessed a unique ability to bridge abstract concepts with concrete implementations. In the public sector, where monetary feedback is absent, this PO excelled at thinking about value achievement and communicating it effectively to the team. They had the magical capability to involve stakeholders while demystifying complex requirements, helping the team understand not just engagement metrics but how their work would change society and the world. The Bad Product Owner: The Absentee Specialist The most common anti-pattern Salum encounters is the absentee Product Owner - typically a specialist assigned to the PO role while maintaining their full-time job as a domain expert. With only 10-20% time allocation, these POs lack the capacity to fulfill their responsibilities effectively. They often don't have the time or knowledge to develop essential PO skills, requiring extensive hand-holding to understand even basic concepts like user stories. Salum's approach involves booking time directly in their calendar for backlog refinement sessions and providing comprehensive guidance to help them understand the role, though this intensive support is necessary due to their limited availability for skill development. In this segment, we refer to the concept of ‘enshitification' by Cory Doctorow, and refer to Tom Gilb's bonus episode on the Scrum Master Toolbox Podcast.  Self-reflection Question: How do you ensure your Product Owner has both the time allocation and skill development needed to truly serve the team and stakeholders effectively? [The Scrum Master Toolbox Podcast Recommends]

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

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

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

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