POPULARITY
Categories
1,621 episodes with Scrum
485 episodes with Scrum
215 episodes with Scrum
287 episodes with Scrum
144 episodes with Scrum
273 episodes with Scrum
208 episodes with Scrum
152 episodes with Scrum
147 episodes with Scrum
123 episodes with Scrum
123 episodes with Scrum
137 episodes with Scrum
76 episodes with Scrum
89 episodes with Scrum
115 episodes with Scrum
48 episodes with Scrum
60 episodes with Scrum
53 episodes with Scrum
67 episodes with Scrum
40 episodes with Scrum
23 episodes with Scrum
53 episodes with Scrum
34 episodes with Scrum
62 episodes with Scrum
29 episodes with Scrum
64 episodes with Scrum
36 episodes with Scrum
22 episodes with Scrum
25 episodes with Scrum
56 episodes with Scrum
40 episodes with Scrum
19 episodes with Scrum
23 episodes with Scrum
29 episodes with Scrum
24 episodes with Scrum
75 episodes with Scrum
35 episodes with Scrum
15 episodes with Scrum
52 episodes with Scrum
35 episodes with Scrum
42 episodes with Scrum
29 episodes with Scrum
33 episodes with Scrum
32 episodes with Scrum
20 episodes with Scrum
22 episodes with Scrum
14 episodes with Scrum
25 episodes with Scrum
21 episodes with Scrum
13 episodes with Scrum
33 episodes with Scrum
15 episodes with Scrum
32 episodes with Scrum
221 episodes with Scrum
13 episodes with Scrum
14 episodes with Scrum
8 episodes with Scrum
11 episodes with Scrum
25 episodes with Scrum
167 episodes with Scrum
23 episodes with Scrum
10 episodes with Scrum
6 episodes with Scrum
9 episodes with Scrum
8 episodes with Scrum
9 episodes with Scrum
6 episodes with Scrum
9 episodes with Scrum
17 episodes with Scrum
6 episodes with Scrum
8 episodes with Scrum
8 episodes with Scrum
137 episodes with Scrum
12 episodes with Scrum
26 episodes with Scrum
6 episodes with Scrum
8 episodes with Scrum
120 episodes with Scrum
4 episodes with Scrum
4 episodes with Scrum
4 episodes with Scrum
9 episodes with Scrum
8 episodes with Scrum
16 episodes with Scrum
8 episodes with Scrum
4 episodes with Scrum
107 episodes with Scrum
7 episodes with Scrum
7 episodes with Scrum
104 episodes with Scrum
104 episodes with Scrum
11 episodes with Scrum
12 episodes with Scrum
10 episodes with Scrum
10 episodes with Scrum
6 episodes with Scrum
4 episodes with Scrum
4 episodes with Scrum
5 episodes with Scrum
5 episodes with Scrum
10 episodes with Scrum
27 episodes with Scrum
5 episodes with Scrum
11 episodes with Scrum
9 episodes with Scrum
6 episodes with Scrum
6 episodes with Scrum
9 episodes with Scrum
9 episodes with Scrum
5 episodes with Scrum
7 episodes with Scrum
4 episodes with Scrum
10 episodes with Scrum
12 episodes with Scrum
5 episodes with Scrum
5 episodes with Scrum
8 episodes with Scrum
4 episodes with Scrum
3 episodes with Scrum
6 episodes with Scrum
15 episodes with Scrum
2 episodes with Scrum
15 episodes with Scrum
6 episodes with Scrum
4 episodes with Scrum
7 episodes with Scrum
4 episodes with Scrum
4 episodes with Scrum
4 episodes with Scrum
4 episodes with Scrum
3 episodes with Scrum
13 episodes with Scrum
2 episodes with Scrum
3 episodes with Scrum
7 episodes with Scrum
4 episodes with Scrum
9 episodes with Scrum
69 episodes with Scrum
3 episodes with Scrum
68 episodes with Scrum
5 episodes with Scrum
3 episodes with Scrum
2 episodes with Scrum
11 episodes with Scrum
Agile in Construction: Team Happiness as the True Measure of Scrum Master Success in Construction With Felipe Engineer-Manriquez Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The teams that are having fun and are light-hearted, making jokes—these are high-performing teams almost 99% of the time. But the teams that are overly sarcastic or too quiet? They're burning out." - Felipe Engineer-Manriquez Felipe offers a refreshingly human definition of success for Scrum Masters: team happiness. After years of traumatic experiences in construction—days when he pounded his steering wheel in frustration during his commute—Felipe developed what he calls being a "human thermometer." He can sense a team's emotional state within 5 minutes of being with them. His proxy for success is a simple Likert scale of 1-5: 5 is Nirvana (working at Google with massages), and 1 is wanting to jump out the window. Felipe emphasizes that most people in construction internalize stress and push it down, so you have to ask directly. When he asked an estimator this question, the man quietly admitted he was at a 2—ready to walk away. Without asking, Felipe would never have known. The key insight: schedule improvements happen as teams move closer to a 5. And the foundation of it all? Understanding. "People do not have an overt need to be loved," Felipe shares from his Scrum training. "They have an overt need to be understood." A successful Scrum Master meddles appropriately, runs toward problems, and focuses on understanding teammates before trying to implement change. Self-reflection Question: If you asked each of your team members to rate their happiness from 1-5 today, what do you think they would say, and what would you learn that you don't currently know? Featured Retrospective Format for the Week: Start/Stop/Keep Felipe's favorite retrospective format is Start/Stop/Keep—but his approach to introducing it is what makes the difference. He connects it to something construction teams already know: the post-mortem. He explains the morbid origin of the term (surgeons standing around a dead patient discussing what went wrong) to emphasize the seriousness of learning. Then he reframes the retrospective as a recurring post-mortem—a "lessons learned" cycle. Start: What should we begin doing that will make things better? Stop: What should we no longer do that doesn't add value? Keep: What good things are we doing that we want to maintain? Felipe uses silent brainstorming so everyone has time to think, then makes responses visible on a whiteboard or digital display. The cadence scales with sprint length—45 minutes for a week, 2 hours for two weeks, half a day for a month. His current team committed to monthly retrospectives and pre-writes their Start/Stop/Keep items, making the facilitated session efficient and focused. [The Scrum Master Toolbox Podcast Recommends]
Agile in Construction: The DOWNTIME Strategy—Eliminating Waste Before Adding Process With Felipe Engineer-Manriquez Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "My first rule is that I will do no harm. And if something goes wrong, I will take full responsibility with leadership. My neck is literally on the line." - Felipe Engineer-Manriquez Felipe shares his change strategy for introducing Lean and Agile into construction projects, and it starts with an unexpected principle borrowed from Hippocrates: do no harm. He explicitly tells teams this promise, putting his neck on the line to build trust. But the real magic happens in what comes next: instead of adding new processes, Felipe first helps teams stop doing things. Using the DOWNTIME acronym (Defects, Overproduction, Waiting, Transportation, Inventory, Motion, Excess processing), he identifies wasteful activities that don't add value. In construction, 60-80% of every dollar doesn't add value from the customer's perspective—compared to manufacturing (above 50% value) or agriculture (90% value). Felipe's approach: eliminate waste first to create excess capacity, then introduce new processes. On a project that was 2 years behind schedule with lawyers already engaged, he spent just 5 minutes with the team defining a visible milestone goal on a whiteboard. Two weeks later, they met their schedule and improved by 4 days—the first time ever. The superintendent said, "Never in the entire time I've worked here have we ever met a schedule commitment." The secret? Free up capacity before adding anything new. In this episode, we refer to the 8 wastes video by Orbus and WIP limits. Self-reflection Question: Before introducing your next process improvement, what wasteful activity could you help your team stop doing to free up the capacity they need to embrace change? [The Scrum Master Toolbox Podcast Recommends]
Hiring for Scrum roles is harder than it looks. Making the wrong call can derail an Agile transformation before it even starts. In this episode, Brian and Cort unpack what to actually look for in Scrum Masters, Product Owners, and Developers—beyond the job title and shiny certifications.
Agile in Construction: Over-Commitment and Silence—The Deadly Duo Destroying Your Teams With Felipe Engineer-Manriquez Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I don't think people are bad. They don't self-destruct because they're bad. What I do see is people getting crushed in terribly bad systems." - Felipe Engineer-Manriquez Felipe shares a powerful insight about team dysfunction: teams don't self-destruct because of bad people—they get crushed by broken systems. On a hospital construction project, he witnessed a dangerous pattern: over-commitment coupled with silence. People would commit to pouring concrete on Thursday when there wasn't even rebar in place—a physical impossibility. But psychological safety was so low that no one could say the emperor had no clothes. Felipe's approach? Ask obvious questions that break the pattern. "Don't you need this so you can do that?" This simple question, framed with verb-noun phrases, surfaces what cannot be spoken. He positions himself as "just a simple, dumb general contractor" who doesn't understand—creating safety for others to speak truth. The turning point comes when you slow down, make work visible, and allow people to say no. As Felipe puts it: "For real accountability, if people are not allowed to say no, then they actually can't make a real promise." Silence is not alignment, and saying yes in low-trust environments is actually hiding from accountability. In this segment, we talk about psychological safety and systems thinking in team dynamics. Self-reflection Question: When you see a team over-committing to impossible deadlines, what question could you ask that surfaces the truth without putting individuals at risk? Featured Book of the Week: The Goal by Eliyahu Goldratt Felipe chose The Goal by Eliyahu Goldratt as the most transformative book of his early lean career. He describes it as "the number one game changer"—a fictional story that teaches the Theory of Constraints in a way you can internalize. The famous "Herbie story" within the book illustrates how helping the slowest part of a process speeds up the entire system. Felipe emphasizes that Theory of Constraints is often skipped in Scrum training when classes run out of time, leaving many credentialed Scrum Masters without this essential knowledge. He uses these principles daily with the Last Planner System in construction—creating visual boards that look like Gantt charts (because construction loves schedules) but function like Scrum boards with days of the week instead of "to do, doing, done." [The Scrum Master Toolbox Podcast Recommends]
Story Point Estimations are failing your Team! - Here We Go Again...Story Pointing wasn't a completely novel idea. It evolved out of the Delphi method — a research technique that helped drive consensus and forecasting built on collective wisdom. In 1950s, RAND Corporation began using it as a way to forecast the effect of technology on warfare.So, it wasn't just an idea dreamed up by someone in the Agile community randomly — no. It's actually based on a scientific approach. Something that's been applied and true in other disciplines for many, many years.And, when Scrum needed a prescriptive technique to help the Teams estimate and measure the amount of work the Team could consistently deliver Sprint after Sprint, this became a recommended approach.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/
Agile in Construction: Stop Teaching and Start Doing—The Secret to Agile Adoption in Construction With Felipe Engineer-Manriquez Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I forgot a couple key things. Number one, they don't have the enthusiasm and love for these new ways of working like I do because they didn't understand the problem that they were in." - Felipe Engineer-Manriquez Felipe shares a powerful failure story from his early days adopting Lean and Agile in construction. After discovering Jeff Sutherland's "Red Book" and experiencing incredible results using Scrum with his 4-year-old son on a weekend project, he was eager to bring these methods to his construction team. The problem? He immediately went into teaching mode. His boss Nate and the rest of the team wanted nothing to do with Scrum—they Googled it, saw it was "a software thing," and shut down completely. This is what Felipe now calls the "Not Invented Here Syndrome"—people resist ideas that don't originate from their domain. The breakthrough came when Felipe stopped teaching and started doing. He calls it the "ninja Scrum approach"—embodying the processes and tools without labeling them, making work visible, and delivering results. When he managed $25 million worth of scopes using these methods silently, one project manager named Tom stopped him and said, "We've never come to a project where people held their promises." Within a year, even his resistant boss Nate acknowledged the transformation in a post-mortem review. The lesson: don't teach until people pull for the teaching. In this episode, we refer to NoEstimates and Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland. Self-reflection Question: When you introduce new practices to a team, do you wait until they pull for the teaching, or do you default to explaining before they've seen the value? [The Scrum Master Toolbox Podcast Recommends]
Cristina Cranga: Coaching Product Owners From Output Obsession to Value Conversations Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, we refer to the work of Esko Kilpi on conversations and episodes on Nonviolent Communication (NVC) on the podcast. The Great Product Owner: A People Person Who Clarifies Before Deciding "He was comfortable saying 'I don't know yet. What do you think?' It was a bi-directional conversation, not just one-way." - Cristina Cranga The best Product Owner Cristina worked with was fundamentally a people person and a leader—human skills, not just hard skills. What made him exceptional was his approach to conversation: he started by clarifying the problem first, then decided. By doing this, he separated requests from decisions and made trade-offs explicit. He was comfortable admitting uncertainty, asking "What do you think?" and engaging the team in co-creation rather than issuing directives. Cristina emphasizes that between the PO and Scrum Master, there's a special bond—a strong leadership partnership that teams look to as a reference. She highlights the concept of "ask more, say less": when you ask questions, you collect information that leads to better, more validated decisions. The communication process, as outlined in Nonviolent Communication by Marshall Rosenberg, has four components: observation, feelings, needs, and requests. Great POs embody this by treating uncertainty as part of their job, engaging teams more deeply, and connecting work to value rather than just output. Self-reflection Question: How often does your Product Owner ask "What do you think?" and what would change if they separated requests from decisions more explicitly? The Bad Product Owner: Output Obsession and the Velocity Trap "Success is measured by how much is delivered, not what changes. Teams get faster, but not smarter." - Cristina Cranga The worst Product Owner anti-pattern Cristina has witnessed is output obsession—measuring success by how much is delivered rather than what actually changes for users or the business. When velocity replaces outcomes as the primary metric, teams get faster but not smarter. Faster doesn't equal smarter. This anti-pattern is particularly dangerous in an AI-accelerated environment where delivery speed is no longer a constraint. The challenge for practitioners is shifting this mindset. The strongest POs make different choices: they own their decisions at the team level, make decisions explicit, treat uncertainty as part of the job, and connect work to value. When POs break free from output obsession, the results are powerful: faster alignment, no decision hallucinations, more engaged teams willing to experiment, and genuine connection between work and value. In this segment, we refer to Nonviolent Communication by Marshall Rosenberg. Self-reflection Question: If you removed velocity from your team's dashboard tomorrow, what conversations would emerge about actual value delivered? [The Scrum Master Toolbox Podcast Recommends]
Cristina Cranga: Decision Quality as the True Measure of Scrum Master Effectiveness Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "A Scrum Master is successful when teams make better decisions, faster, with clear trade-offs—everything else is a side effect, not the job." - Cristina Cranga Cristina offers a refreshingly clear definition of Scrum Master success for 2026: increasing the team's decision quality under accelerating change. She emphasizes that success as a term changes over time, and what mattered in previous years may not be what matters now. It's not about ceremony fluency or even making yourself unnecessary—those are side effects. The core of success is helping teams navigate complexity and AI-driven acceleration by making better decisions faster with explicit trade-offs. Cristina describes this as an evolution from a "mechanic" role—focused on ceremonies, flow, and structure—to a strategic role. The Scrum Master elevates into a leader of team systems and human behaviors, possibly even becoming an AI integration enabler. This requires reskilling and upskilling as the environment changes. Her prompt for self-reflection: How can you orient your execution of the Scrum Master role more towards strategic aspects, focusing on decision quality as the opposite of decision hallucination? Self-reflection Question: What would change in your daily work if you measured your success by the quality of decisions your team makes rather than the smoothness of your ceremonies? Featured Retrospective Format for the Week: Start/Stop/Continue Cristina advocates for simplicity in retrospectives, choosing the classic Start/Stop/Continue format. But she emphasizes that the format itself is secondary—what matters is the environment you create and the outcomes you achieve. Her two key conditions for any retrospective: an actionable plan and a simple conversational approach. She challenges Scrum Masters to focus on the "how" rather than the "what"—how do you hold the space? How do you hold the silence? How do you approach disagreements? The power of Start/Stop/Continue lies in its simplicity, which frees facilitators to focus on creating psychological safety. Cristina also warns against the instinct to take ownership of action items yourself—instead, delegate to team members so they own their problems and become more committed to finding solutions. [The Scrum Master Toolbox Podcast Recommends]
Nicco has been playing some Blake Manor...however, Sean has also been a marriage fairy. Meanwhile, Brody has some deep dive impressions on Big Hops and Date Everything. Mad Catz, dawg. MORE PLACES TO FIND USCrubscribe ► https://bit.ly/CrubcastGet the show early and get exclusive content at our Patreon ► https://www.patreon.com/crubOur Crubcasts are recorded LIVE at https://www.twitch.tv/crub_official every Tuesday at 7pm Eastern, with EXCLUSIVE Pre- and Post-ShowsJoin our Discord ► https://crub.org/joinBlueSky ► https://bsky.app/profile/crub.orgCome join our Steam group ► https://steamcommunity.com/groups/crubclubPodcasts are available on Apple, Google, Spotify, and other platforms are available at ► https://crub.orgSHOW NOTESThe Séance of Blake Manor:https://store.steampowered.com/app/1395520/The_Sance_of_Blake_Manor/Big Hops:https://store.steampowered.com/app/1221480/Big_Hops/Loop Hero:https://store.steampowered.com/app/1282730/Loop_Hero/Date Everything:https://store.steampowered.com/app/2201320/Date_Everything/TODAY'S CRUBCAST HOSTSBrody: https://www.youtube.com/@RACROXNicco: https://www.youtube.com/channel/UCl56kbl3tb-KiGEHT7MUGUgSean: https://www.youtube.com/@WolfkaosaunCHAPTERS00:00 Scrum says hello, Sean is the Ohio Marriage Fairy08:45 Modern Family and the new A$AP Rocky10:21 Brody has been playing Big Hops14:53 Sean's been playing Loop Hero and trying to beat 100 games20:03 The Mad Catz Memory Card24:19 Brody Dated Everything32:28 A walk down dating sim memory lane ★ Support this podcast on Patreon ★
Cristina Cranga: Why Speed Without Value Creates Chaos in AI-Accelerated Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "When output becomes cheap, value becomes harder to see. AI is amplifying this risk." - Cristina Cranga Cristina brings a timely challenge to the table: how do Scrum Masters stay focused on value when AI tools are accelerating delivery to unprecedented speeds? Teams are delivering faster than ever—AI provides code, tests, documentation, even backlog items—but speed is no longer the constraint. The real challenge is meaning. Teams struggle to explain why their work matters to users or the business. Cristina frames this as a shift from "delivery" as the primary keyword to "value." She suggests that Scrum Masters are evolving from facilitators of flow to protectors of intent—what she playfully calls "strategic guardians of the value chain" or even "value masters." Together with Vasco, they explore experiment ideas around building clarity of value cycles with product owners, bringing signals of value into earlier backlog work, and helping teams validate faster, not just deliver more. The key insight: in an AI-accelerated world, the Scrum Master's role becomes more strategic, focused on ensuring teams make better decisions with clear trade-offs rather than just executing ceremonies. Self-reflection Question: How might you help your product owner build a "clarity of value" cycle that tests ideas before they reach the development team? [The Scrum Master Toolbox Podcast Recommends]
Cristina Cranga: Why Nice Teams Still Fail and the Power of Honest Conversations Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Sometimes you can change people by only listening to them. Not giving advice—don't become an advice monster." - Cristina Cranga Cristina shares her experience of sensing that something was off with a team but being unable to pinpoint exactly what it was. Instead of jumping to conclusions, she paused, reflected, and created an intervention plan centered on one thing: starting honest conversations. Through one-on-one discussions with team members, she discovered that the problem wasn't performance or process—it was something deeper. Expectations weren't aligned with reality, and frustration stemmed from a company culture that didn't offer psychological safety. Cristina introduces the concept of the "advice monster"—someone who constantly tells others what they should do rather than simply listening. She emphasizes that as Scrum Masters, we need to recognize the three layers of our influence: control, influence, and no control. Even when we can't solve problems, being present and listening can create profound change. The key is self-awareness of our own vulnerability as humans and compassion for others who might be at 80% or 10% of their mental health and energy on any given day. In this segment, we talk about the importance of psychological safety and active listening in team dynamics. Self-reflection Question: How often do you enter conversations with the intention of truly understanding rather than solving, and what might you discover if you listened more and advised less? Featured Book of the Week: The Fearless Organization by Amy Edmondson Cristina chose The Fearless Organization by Amy Edmondson as her most influential book because it explains what Scrum Masters see every day but struggle to name. The book provides a mental model for why teams don't speak up and how to influence behavior without forcing it. As Cristina puts it: "She explains why nice teams still fail. Silence is not always alignment and politeness—most of the time, it's distrust." The book repositions the Scrum Master role from someone focused on ceremonies to someone who creates the conditions for psychological safety. It also explains why process alone doesn't fix everything and helps Scrum Masters measure what really matters in a team. [The Scrum Master Toolbox Podcast Recommends]
Cristina Cranga: When Teams Stop Testing Reality and Fall Into Decision Hallucinations 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. "Over time, what I notice is that teams stop testing reality. They optimize execution around constraints that might no longer exist." - Cristina Cranga Cristina introduces a powerful concept she calls "decision hallucinations"—the perception of constraints and boundaries that aren't actually real or present. In her experience working with teams in complex matrix environments, she noticed a troubling pattern: team members would say things like "we can't change this because it's already decided" or "the priority comes from the top level" without ever verifying these assumptions. The impact on team behavior was significant—teams stopped asking questions, stopped having conversations with stakeholders, and began operating within perceived limitations rather than actual ones. Cristina emphasizes that as Agile practitioners, our work isn't just about ceremonies and metrics—it's about supporting and facilitating decision processes. When she encouraged teams to ask better questions like "Is this an assumption-based decision or an explicit shared choice?", something beautiful happened: options reappeared, conversations changed, and teams realized they were constrained by perception rather than reality. She uses the famous duck vs. rabbit optical illusion from psychology to illustrate how our brains can only see one reality at a time, making the case that we must constantly test our view of reality through continuous conversations with stakeholders. In this episode, we refer to the work of Esko Kilpi on conversations and the duck vs rabbit image from psychology. Self-reflection Question: When was the last time you challenged an assumption your team operates under, and what did you discover when you tested that reality? [The Scrum Master Toolbox Podcast Recommends]
Mohini Kissoon: The One Question That Transforms Messengers Into Product Owners The Great Product Owner: The Calm Navigator Who Shields the Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "He said "no" often, but he did it with such clarity that people respected it. It's not just no—it's giving the reason why." - Mohini Kissoon Mohini has had the privilege of working with many great Product Owners, but one stood out for his calm demeanor and ability to navigate complex situations. Whatever stakeholders threw at him, he remained professional and calm—and critically, he never transferred that pressure onto the team. He had built strong relationships with stakeholders and was the go-to person who commanded respect across the organization. When stakeholders demanded features that didn't align with team goals, he would acknowledge the request, explain the trade-offs, and offer to revisit it once the current direction was validated. He said no often, but with such clarity and reasoning that people respected his decisions. This Product Owner also shielded the team from ad hoc requests, handling stakeholder bypass attempts so developers could maintain focus. He would only bring truly urgent items—like compliance issues—directly to the team. With his helicopter view, he understood how incoming work would impact different stakeholders and parts of the business. Most importantly, he was a good listener who gave the team space to grow and experiment while challenging them constructively. Self-reflection Question: When you work with your Product Owner, do they shield the team from chaos or pass it through unfiltered—and how might you help them develop that protective capability? The Bad Product Owner: The Messenger Who Couldn't Say No Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "When the team would ask 'why are we building this?' the answer would be 'because sales asked for it.' There was no triaging, no challenging stakeholders—just saying yes." - Mohini Kissoon Mohini shares a story about a Product Owner who appeared to be doing everything right on paper: attending ceremonies, responding to questions, being present for the team, and working closely with stakeholders. But the team was constantly frustrated with scope creep, and the root cause was that this Product Owner was operating as a messenger, not a decision maker. She would bring requests from stakeholders directly into the backlog with no prioritization based on value and no pushback. Major new work would appear at sprint planning that hadn't been discussed during backlog refinement. The team was committing to 100 story points but only completing 40, with items constantly carrying over. When Mohini was brought in to help, she asked one simple question that changed everything: "What is the vision for your product?" The Product Owner couldn't answer—because nobody had ever asked her before. Mohini ran a product vision workshop with her and key stakeholders, created a one-page strategy identifying target users, core problems, and success metrics, and established a working agreement that backlog items must align with identified goals. She also introduced prioritization sessions involving stakeholders. The transformation came when the Product Owner finally felt equipped to say no with informed reasoning. Self-reflection Question: Does your Product Owner have a clear product vision they can articulate, and if not, what workshop or conversation could you facilitate to help them discover it? [The Scrum Master Toolbox Podcast Recommends]
Mohini Kissoon: The Language Test That Reveals True Team Ownership Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "When I see my team taking ownership of their work, taking ownership of the Scrum events, asking questions, challenging each other constructively without waiting for me—that's when I know I've done my job." - Mohini Kissoon Mohini defines success for Scrum Masters through three distinct lenses. First, she looks for teams that take ownership—of their work, of the Scrum events, of asking questions and challenging each other constructively without waiting for her to intervene. When she can observe from the sidelines while the team self-manages, she knows she has shaped the right conditions for them to thrive. Second, success means having metrics that demonstrate improvement over time: team happiness, flow, and how individuals have grown in their roles. These metrics aren't just for the team—they're for sharing with leadership to show the positive impact created. Third, and perhaps most importantly, success is about creating psychological safety where team members feel comfortable disagreeing, engaging in healthy conflict, and being creative without taking things personally. One powerful indicator Mohini uses is the language of the team: do they say "their sprint goal" or "our sprint goal"? This subtle shift from passive to possessive language reveals the true level of ownership the team has developed. It's an easy thing to observe but often missed by Scrum Masters. Self-reflection Question: Listen carefully in your next sprint planning or daily scrum—does your team use "we" and "our" language, or do they speak about the work as something external to them? Featured Retrospective Format for the Week: Timeline Retrospective Mohini finds herself returning to the Timeline retrospective more than any other format, especially when a team has been going through something complex—a difficult sprint, a major release, or a quarterly review with a working group. The format helps people pause and reflect on what has happened before jumping into "what do we change next?" In a physical room, she draws a line on the whiteboard and invites people to add sticky notes for key moments that stood out during the period. In virtual settings, she uses a digital whiteboard. The moments can be good, bad, confusing, or stressful—anything significant. The exercise starts silently, giving everyone space to think without being influenced. Then the team walks through the timeline chronologically, sharing stories behind their notes. What makes this format powerful is that it creates shared understanding before asking for solutions. Team members often realize that others experienced the same event differently. However, Mohini warns that the timeline can feel overwhelming when you see all the stickies on the board. The key is to build a bridge before jumping to actions: have the team identify patterns, vote on items to discuss further, and only then derive concrete actions from the prioritized items. [The Scrum Master Toolbox Podcast Recommends]
Agile in 2026 Looks Nothing Like ScrumThat delay cost us 42,000 failed checkout attempts and a week of executive explanations. Nothing was broken in the code. The failure was procedural. The fix was ready. The sprint boundary said no.That was the moment we stopped pretending Scrum was helping us ship.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/
Mohini Kissoon: Beyond the AI Fear—Discovering What Makes Scrum Masters Truly Irreplaceable Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The real challenge isn't whether AI will replace Scrum Masters. It's whether we understand what parts of our work are actually irreplaceable—and whether we're spending our time on those things." - Mohini Kissoon Mohini is wrestling with a challenge that's coming up repeatedly in conversations with Agile coaches and Scrum Masters: the anxiety around AI and what it means for their role. She hears questions like "Will AI replace Scrum Masters?" but believes we're asking the wrong question. The real challenge is understanding which parts of our work are truly irreplaceable and demonstrating value in those areas. People might think that AI can generate sprint reports and analyze team metrics—so why do we need Scrum Masters? But what's missing is the human touch: reading the room, sensing unspoken tension, building trust through presence, and asking questions that shift perspectives. Mohini and Vasco explore how the Scrum Master role may have accidentally become defined by process and structure rather than impact on teams. The solution lies in showing value through concrete metrics—demonstrating improvement in team happiness, flow, cycle time, and lead time. Scrum Masters need to use storytelling and create history that shows the before and after. They should leverage champions from teams they've worked with to share testimonials. We are like diplomats: we work through influence and need allies both inside and outside the team to support our work. Self-reflection Question: If AI could handle all the administrative and mechanical aspects of your Scrum Master role tomorrow, what would you spend your time doing—and are you already investing enough time in those irreplaceable human elements? [The Scrum Master Toolbox Podcast Recommends]
Mohini Kissoon: When Politeness Becomes the Enemy of Team Growth—Escaping the Conflict Avoidance Trap Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Conflict isn't the enemy. It's when we're avoiding conflict that it becomes an issue for teams." - Mohini Kissoon Mohini shares a story about the worst self-destructive pattern she has witnessed: teams that are overly polite to avoid addressing conflicts. She worked with a team that prided themselves on being collaborative and drama-free, but beneath that politeness was a hesitancy to have difficult conversations. It started small—in sprint planning, the Product Owner would propose unrealistic scope, and people would just nod and accept. Someone might say "that's quite ambitious," but no one would actually push back. In retrospectives, feedback was always wrapped in layers of positive framing. When a developer consistently delivered work that didn't meet the Definition of Done, no one called it out directly—they just quietly fixed it or worked around it. After three months, side conversations started emerging where people would pull Mohini aside to share concerns they would never voice in the room. The team was skipping the storming phase of the Tuckman model, and this avoidance eventually led to missed deadlines and frustrated stakeholders. The key learning: healthy conflict brings the energy teams need to innovate and grow. In this segment, we talk about the Tuckman model and why the storming phase is essential for team development. Self-reflection Question: Is your team's harmony genuine collaboration, or is it a facade hiding unspoken frustrations that will eventually surface at the worst possible moment? Featured Book of the Week: Turn the Ship Around by David Marquet Mohini discovered Turn the Ship Around by David Marquet at a time when she was working with multiple teams and feeling exhausted from being the person everyone looked to for answers. She thought that's what servant leadership meant, but she was actually creating dependency rather than capability. The book tells the story of how Marquet took command of the worst-performing submarine in the US Navy and transformed it into the best by fundamentally changing how leadership worked. "Instead of the traditional leader-follower model, he built a leader-to-leader structure where everyone was expected to think, decide, and own their work," Mohini explains. The key insight was that we don't just empower teams—we need to build an environment where they can grow and don't need permission to excel. This shifted Mohini's approach: instead of saying "here's what I think we should do," she started asking "what have you tried so far? What do you intend to do next?" The book also emphasizes that pushing decision-making down requires providing the knowledge and context teams need to make good decisions. [The Scrum Master Toolbox Podcast Recommends]
Scrum Is NOT Dead... It's Obsolete?(Did someone actually Go here?) AAAAAAAhhhhhhhh!Stand-ups are still happening. Sprint planning still blocks calendars every few weeks. Retrospectives still end with “we should communicate better.” Jira boards are still very busy.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/
In this episode I'm joined by Lee Robinson to talk about his new book 'Jonty: The Life of Jonathan Parkin', arguably the greatest rugby league scrum-half of all time. Jonty's career began as a teenager with Wakefield Trinity before World War One and ended in 1932, by which time he had become the first player ever to tour Down Under three times, twice as captain, and had played in every international match in which he could be selected before his international retirement in 1930. He did all this during what was arguably Trinity's poorest ever decade. Perhaps most importantly, Jonty was the archetype of the typical scrum-half - combative, tricky and with an inbuilt hostility to authority - and his influence is till felt today. The book is available from https://www.ebay.co.uk/itm/136704396053 and you can discover a whole lot more about Wakefield Trinity's history at https://www.trinityheritage.co.uk For more on the history of rugby and the other football codes, take a look at www.rugbyreloaded.com (where you can find the links for this episode) and follow me on Twitter at @collinstony
Mohini Kissoon: How to Break the Cycle of Dominant Personalities in Agile Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I confused silence with agreement. My silence as a facilitator had been giving the wrong impression to the team: that this kind of dynamic is acceptable." - Mohini Kissoon In her first year as a Scrum Master, Mohini was full of energy and deeply committed to doing Scrum by the book. She had just earned her certification and joined a mid-sized product team where a senior developer—let's call him Tom—was brilliant but quite dominant. In every session, Tom would speak first, speak longest, and often override the ideas of junior developers. Mohini noticed this pattern but didn't intervene, assuming that Tom's experience and the others' silence meant agreement. Over several sprints, stand-ups became reporting sessions to Tom rather than collaborative planning. Junior developers gradually stopped offering ideas in fear of being shut down. When Mohini finally reached out to the team members individually, one of them was even considering leaving the organization—they felt like "just a cog in the machine." This was the wake-up call Mohini needed. She realized she had been focusing intensely on the mechanics while missing the human dynamics entirely. The solution came through coaching Tom on active listening and introducing facilitation techniques like silent brainstorming and round-robin sharing, giving everyone the opportunity to contribute without being influenced. Self-reflection Question: When you observe dominant voices silencing others on your team, do you intervene immediately, or do you wait to see if the situation resolves itself—and what does that choice cost your team? [The Scrum Master Toolbox Podcast Recommends]
Carmela Then: Why the Best Product Owners Let Go of What They're Best At The Great Product Owner: The Humble Leader Who Served His Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "He was there, he was present, he was serving the team." - Carmela Then Carmela worked with a Product Owner at a bank who embodied everything servant leadership should look like. This wasn't a PO who lorded his business expertise over the team—instead, he brought cookies, cracked jokes, and made everyone feel valued regardless of their role. He knew the product landscape intimately and participated in every refinement session, yet remained approachable and coachable. When team members came to him confused about stakeholder requests, he willingly stepped in as a mediator. Perhaps most impressively, he actively worked to break down the hierarchical mindset that often plagues traditional organizations. In the beginning, testers felt they couldn't question the business analyst or Product Owner. By the end, QA team members were confidently pointing out missing scenarios and use cases—and the PO would respond with genuine appreciation: "Oh yes! We missed it! Let's prioritize that story for the next sprint." This PO understood that his role wasn't to have all the answers, but to create an environment where anyone could contribute their expertise. The result was a truly flat, collaborative Scrum team operating exactly as Scrum was designed to work. Self-reflection Question: How accessible are you to your team, and do you create an environment where anyone—regardless of role—feels comfortable challenging your thinking? The Bad Product Owner: When Expertise Becomes a Barrier to Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "He knows everything himself, and everything is in his head. So nobody else knows what he has in his head." - Carmela Then Carmela describes a Product Owner who wasn't a bad person—in fact, he was incredibly capable. He knew the business from front to back, understood the systems intimately from years of analyst work, and could even write pseudocode himself. The problem? His very competence became a barrier to team collaboration. Because he knew so much, he struggled to articulate his ideas to others. Frustrated that developers couldn't read his mind, he started writing the code himself and handing it to developers with instructions to simply implement it. The result was disengaged developers who had no understanding of the bigger picture, and a PO who was drowning in work that wasn't his to do. Carmela approached this with humility, asking what she calls "dumb questions" and requesting that he draw things on paper so she could understand. She made excuses about her "bad memory" to create documentation that could be shared with the whole team. Over multiple Program Increments, she gently coached him to trust his team: "You are one person. Please let the team help you. The developers are great at what they do—if you share what you're trying to achieve, they can write code that's more efficient and easier to maintain." Eventually, he learned to let go of the coding and focus on what only he could do: sharing his deep business knowledge. Self-reflection Question: As a leader, what tasks are you holding onto that you should be delegating—and what is your reluctance costing your team? [The Scrum Master Toolbox Podcast Recommends]
Carmela Then: Why Teams Hate Agile (And How to Change That) Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "They just hate it. They absolutely hate it. They had Agile fatigue." - Carmela Then Carmela describes what success looks like for a Scrum Master, and her answer might surprise you. Years ago, she might have pointed to metrics like cycle time. Today, she measures success by whether teams embrace Agile and Scrum rather than resent it. She joined a team that was exhausted and bitter—their previous Scrum Master had been a micromanaging project manager in disguise. Stories were broken into disconnected tasks: one for development, one for testing, with no relationship between them. At the end of a sprint, nobody could answer whether something actually worked in production. The team hated Agile with a passion. Carmela approached them differently—not as a threatening authority figure, but as a humble business analyst there to help. She let the Product Owner vent his frustrations about Agile in a retrospective. Then, without preaching, she simply showed them another way: how to break down features properly, how to create end-to-end visibility, how to write stories that delivered actual value. Slowly, the team began to experience what Agile was meant to feel like. They stopped being "task deliverers" and started becoming value creators. The transformation wasn't overnight, but the result was a team that finally understood—and even appreciated—why Agile works. Self-reflection Question: If you asked your team whether they love or hate Agile, what would they say—and are you brave enough to ask? Featured Retrospective Format for the Week: Emotional Seismograph Carmela recommends the Emotional Seismograph as her go-to retrospective format. The setup is simple but powerful: create a graph with the sprint days on the horizontal axis and emotion levels on the vertical (happy at the top, sad at the bottom). Each team member draws a line showing how they felt throughout the sprint. The visual result is striking—and the conversations it triggers are invaluable. Carmela focuses on the extremes: moments of great happiness and moments of stress. She has team members add sticky notes to explain those peaks and valleys, allowing common themes to emerge. Her philosophy is that positive emotions drive productivity: "When the team is having a positive experience throughout their workday, they're actually more productive. Stress is the silent killer—it makes people sick, takes them out physically and mentally, and people will just quit." By putting a finger on the emotional pulse of the team, Scrum Masters can identify what to continue doing and what needs to change to lift the team into a better experience. [The Scrum Master Toolbox Podcast Recommends]
Topics: Brant revisits being 'hat guy' and how he went Twitter viral over the holidays with an unintended hot take. Quotes: "We can't quite pin down why he's so cool." "A lot of things we do don't make kingdom sense." "Unity is a defining characteristic of believers." "Good job everyone, except for that one lady." . . . Holy Ghost Mama Pre-Order! Want more of the Oddcast? Check out our website! Watch our YouTube videos here. Connect with us on Facebook!
Carmela Then: From Requirements Chaos to Story Mapping Success—How Planning Transforms 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. "We can't continue to do this. Something has to change." - Carmela Then Carmela shares a story of organizational chaos that will resonate with many Agile practitioners. She joined a company where teams would jump straight into writing requirements without pausing to understand what they were trying to achieve. Vendor deliverables were thrown "over the fence" to internal technology teams with the assumption that everyone would magically know what to do. For almost a year, this pattern continued: teams writing stories on the fly while building, creating massive rework, confusion, and burnout. The Product Owner faced constant stakeholder disappointment, having to explain what wasn't delivered and why. Then came the breakthrough moment—the PO reached out and said, "We can't continue to do this." Carmela introduced a structured approach: workshops that brought business stakeholders and subject matter experts together to walk through end-to-end business processes. She implemented story mapping—visualizing the journey from beginning to end, with each major step broken into smaller, actionable stories. Critically, she built in feedback loops: playback sessions where the team validated their understanding with stakeholders before committing to development. The result? Teams could now distinguish between well-understood work they could start immediately and the "hairy" items that needed more investigation. The Product Owner could make informed prioritization decisions, and the entire team gained visibility into the bigger picture. Self-reflection Question: How often does your team pause to map the full end-to-end journey before diving into requirements, and what might you be missing by skipping this step? [The Scrum Master Toolbox Podcast Recommends]
Carmela Then: When Remote Teams Stop Listening—The Silent Killer of Agile Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Two minutes into it, my mind's starting to wander and I started to do my own thing." - Carmela Then Carmela paints a vivid picture of a distributed team stretched across Sydney, New Zealand, India, and beyond—a team where communication had quietly become the enemy of progress. The warning signs were subtle at first: in meetings with 20 people on the call, only two or three would speak for the entire hour or two, with no visual aids, no PowerPoints, no drawings. The result? Within minutes, attention drifted, and everyone assumed someone else understood the message. The speakers believed their ideas had landed; the listeners had already tuned out. This miscommunication compounded sprint after sprint until, just two months before go-live, the team was still discussing proof of concept. Trust eroded completely, and the Product Owner resorted to micromanagement—tracking developers by the hour, turning what was supposed to be an Agile team into a waterfall nightmare. Carmela points to a critical missing element: the Scrum Master had been assigned delivery management duties, leaving no one to address the communication dysfunction. The lesson is clear—in remote, cross-cultural teams, you cannot simply talk your way through complex ideas; you need visual anchors, shared artifacts, and constant verification that understanding has truly been achieved. In this segment, we talk about the importance of visual communication in remote teams and psychological safety. Self-reflection Question: How do you verify that your message has truly landed with every team member, especially when working across time zones and cultures? Featured Book of the Week: How to Win Friends and Influence People by Dale Carnegie Carmela recommends How to Win Friends and Influence People by Dale Carnegie, a timeless classic that remains essential reading for every Scrum Master. As Carmela explains, "We work with people—customers are people, and our team, they are human beings as well. Whether we want it or not, we are leaders, we are coaches, and sometimes we could even be mentors." Written during the Great Depression and predating software entirely, this book emphasizes that relationships and understanding people are the foundation of personal and professional success. Carmela was first introduced to the book by a successful person outside of work who advised her not just to read it once, but to revisit it every year. For Scrum Masters navigating team dynamics, stakeholder relationships, and the human side of Agile, Carnegie's principles remain as relevant today as they were nearly a century ago. [The Scrum Master Toolbox Podcast Recommends]
Carmela Then: The Scrum Master Who Learned That Perfect Boards Don't Build Perfect Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The failure part is, instead of leading the team to work toward a common vision, I was probably one of the persons that helped the divide." - Carmela Then Carmela shares a vulnerable story from her first Scrum Master role at a bank. Armed with training, certifications, and the ability to build a beautiful physical Scrum board with perfectly straight lines, she believed she was ready to lead. But Carmela quickly discovered a crucial truth: mastering the mechanics of Scrum is vastly different from serving a team's real needs. Instead of showing up as a humble learner willing to grow alongside her team, she put on a facade of competence and confidence. When two Product Owners began fighting for dominance, rather than stepping back and focusing the teams on their shared purpose, Carmela found herself drawn into the political battle, supporting one PO over the other. The result was devastating—a toxic environment where one PO was demoted, and talented team members left the organization entirely. Looking back, Carmela recognizes that her failure wasn't about the Scrum board or ceremonies; it was about not putting the customer and common goals at the center. She learned that Scrum Masters must lead with humility, focus on outcomes rather than egos, and help teams unite rather than divide. In this episode, we refer to John C. Maxwell and Failing Forward by John C. Maxwell. Self-reflection Question: When was the last time you prioritized looking competent over truly serving your team's needs, and what did that cost you? [The Scrum Master Toolbox Podcast Recommends]
Steve Martin: Coaching Product Owners to Be the Voice of the Customer In this episode, we refer to Henrik Kniberg's "Product Owner in a Nutshell" video and Product Ownership by Geoff Watts. The Great Product Owner: Rob Gard's Customer Obsession Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The role of the PO really is to help the team empathize with the user, the customer of the product, because that's how they can develop great solutions." - Steve Martin Rob Gard worked at a fintech firm and is now CPO of a major fintech company. Steve describes him as having a brilliant mind and being a real agileist—someone Steve learned a huge amount about Agile from. Rob's defining characteristic was his absolute obsession with the user. Everything focused on customer pain points. Working with engineering teams serving military customers, Rob held regular workshops with those customers to understand their pain firsthand. He was literally the voice of the customer, not theoretically but practically. Rob pushed and challenged teams to be more innovative, always looking for better ways of providing better software. His gift was communication—specifically, briefing the team on the problem rather than just reading out stories in refinement sessions. This is the anti-pattern many Product Owners fall into: going through the motions, reading requirements without context. Real product ownership, as Rob demonstrated, is telling a story that helps the team empathize and understand the pain. When teams can internalize customer problems, they develop better solutions. Rob's ability to communicate the problem into the minds of teams enabled them to serve customers more effectively. This is the essence of great Product Ownership: not being a proxy for management, not juggling multiple teams, but being deeply connected to customer pain and translating that pain into context the team can work with. Self-reflection Question: Do your refinement sessions tell stories that help the team empathize with customer pain, or do you just read out requirements? The Bad Product Owner: Proxies for Management Instead of Customer Advocates Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "They weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte Steve emphasizes that Product Owners often have great intentions but struggle due to lack of training and coaching. The anti-patterns are systemic: commercial managers "dressed up" as Product Owners without understanding the role. Project managers transitioning to PO roles—though Steve notes PMs can make really good POs with proper support. The most damaging pattern is Product Owners spread across multiple teams, having very little time to focus on any single team or their customers. These POs become proxies—representing the voice of senior management rather than the voice of the customer. They cascade requirements downward instead of bringing customer insights upward. The solution isn't to criticize these struggling Product Owners but to help them understand their role and see what good looks like. Steve recommends Henrik Kniberg's "Product Owner in a Nutshell" video—15 minutes, 15 years old, still profoundly relevant. He also points to Product Ownership by Geoff Watts and formal training like CSPO or IC Agile Product Ownership courses. The fundamental issue is meeting Product Owners where they are, providing coaching and support to transform them from management proxies into customer advocates. When POs understand their role as empathy builders between customers and teams, everything changes. Self-reflection Question: Is your Product Owner the voice of senior management or the voice of the customer? [The Scrum Master Toolbox Podcast Recommends]
Steve Martin: Making Scrum Master Success Visible with OKRs That Actually Work Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "It is not the retrospective that is the success of the retrospective. It is the ownership and accountability where you take improvements after the session." - Steve Martin The biggest problem for Scrum Masters isn't just defining success—it's being able to shout it from the rooftops with tangible evidence. Steve champions OKRs as an amazing way to define and measure success, but with a critical caveat: they've historically been poorly written and implemented in dark rooms by executives, then cascaded down to teams who never bought in. Steve's approach is radically different. Create OKRs collectively with the team, stakeholders, and end users. Start by focusing on the pain—what problems or pain points do customers, users, and stakeholders actually experience? Make the objective the goal to solve that problem, then define how to measure progress with key results. When everyone is bought in—Scrum Master, engineers, Product Owner, stakeholders, leaders—all pulling in the same direction, magic happens. Make progress visible on the wall like a speedometer, showing exactly where you are at any moment. For an e-commerce checkout, the problem might be too many steps. The objective: reduce pain for users checking out quickly. The baseline: 15 steps today. The target: 5 clicks in three months. Everyone can see the dial moving. Everything should focus on the customer as the endpoint. The challenge is distinguishing between targets imposed from above ("increase sales by 10%") and objectives created collaboratively based on factors the team can actually control. Find what you can control first, work with customers to understand their pain, and start from there. Self-reflection Question: Can you articulate your team's success with specific, measurable outcomes that everyone—from developers to executives—understands and owns? Featured Retrospective Format for the Week: Post-Retro Actions and Ownership The success of a retrospective isn't the retrospective itself—it's what happens after. Steve emphasizes that ownership and accountability matter more than the format of the session. Take improvements from the retrospective and bring them into the sprint as user stories with clear structure: this is the problem, how we'll solve it, and how we'll measure impact. Assign collective ownership—not just a single person, but the whole team owns the improvement. Then bring improvements into the demo so the team showcases what changed. This creates cultural transformation: the team themselves want to bring improvements, not just because the Scrum Master pushed them. For ongoing impediments, conduct root cause analysis. Create a system to escalate issues beyond the team's control—make these visible on another board or with the leadership team. Find peers in pain: teams with the same problems can work together collectively. The retrospective format matters less than this system of ownership, action, measurement, and visibility. Stop retrospective theatre—going through the motions without taking action. Make improvements real by treating them like any other work: visible, measured, owned, and demonstrated. [The Scrum Master Toolbox Podcast Recommends]
Steve Martin: Why Agile Fatigue Means We Need to Change Our Approach Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "We teach transformation, we support transformation, we help change, but we don't really understand what they're changing from." - Steve Martin Steve believes Agile as a whole is on the back foot, possibly regressing. There's palpable fatigue in the industry, and transformation in its current form hasn't been the success we hoped. Organizations still need to work in a state of agility—making rapid decisions, aligning teams, delivering value at pace—but they're exhausted by how we've implemented Agile. As Agile professionals, Steve argues, we have a responsibility to take stock and reflect on what's not working. The problem isn't that organizations don't need agility; it's that we've been force-feeding them frameworks without understanding their context. Steve invokes an ancient principle: "When the student is ready, the teacher will appear." But we haven't waited for readiness—we've barged in with Big Bang transformations, bringing 10, 15, or 20 Agile coaches to "save the world." The solution requires meeting people where they are, understanding what they're changing from, not just what they're changing to. Steve's coaching conversation centers on a radical idea: stop trying to help teams that don't want to be helped. Focus on teams already interested in incremental, adaptable delivery. Run small pilots, learn what works, then scale when ready. The age of prescriptive transformation is over. We need to adapt to the reality of the moment, experiment with what works, and have the courage to change the plan when our approach isn't working. Self-reflection Question: Are you forcing Agile on teams that aren't ready, or are you working with those who genuinely want to improve their delivery approach? [The Scrum Master Toolbox Podcast Recommends]
Steve Martin: When a Distributed Team's Energy Vanishes into the Virtual Void Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "They weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte (describing Steve's team situation) The infrastructure team looked promising on paper: Product Owner in Italy, hardware engineers in Budapest, software engineers in Bucharest, designers in the UK. The team started with energy and enthusiasm, but within a month, something shifted. People stopped showing up for daily stand-ups. Cameras went dark during meetings. Engagement in retrospectives withered. This wasn't just about being distributed—plenty of teams work across time zones successfully. The problem ran deeper. The Scrum Master had a conflict of interest, serving dual roles as both facilitator and engineer. Team members were simultaneously juggling three or four other projects, treating this work as just another item on an impossibly long list. Steve spent a couple of months watching the deterioration before recognizing the root cause: there was no leadership sponsorship or buy-in. Stakeholders weren't invested. The team wasn't actually a team—they were individuals happening to work on the same project. Steve considers this a failure because he couldn't solve it. Sometimes, the absence of organizational support creates an unsolvable puzzle. Without leadership commitment, even the most skilled Scrum Master can't manufacture the conditions for team success. In this episode, we refer to The Phoenix Project by Gene Kim, a book about organizational culture disguised as a DevOps novel. Self-reflection Question: Is your team truly dedicated to one mission, or are they a collection of individuals spread across competing priorities? Featured Book of the Week: The Phoenix Project by Gene Kim "There's a lot of good lightning bulb moments that go off." - Steve Martin Steve describes The Phoenix Project as a book about culture, not just DevOps. Written like a novel following a mock company, it creates continuous light bulb moments for readers. The book resonated deeply with Steve because it exposed patterns he'd experienced firsthand—particularly the anti-pattern of single points of failure. Steve had worked with an engineer who would spend entire weekends doing releases, holding everything in his head, then burning out and taking three days off to recover. This engineer was the bottleneck, the single point of failure that put the entire system at risk. The Phoenix Project illuminates how knowledge hoarding and dependency on individuals creates organizational fragility. The solution isn't just technical—it's cultural. Teams need to share knowledge and understanding, deliberately de-risking the concentration of expertise in one person's mind. Steve recommends this book for anyone trying to understand why organizational transformation requires more than process changes—it demands a fundamental shift in how teams think about knowledge, risk, and collaboration. [The Scrum Master Toolbox Podcast Recommends]
Steve Martin: When the Gospel of Agile Becomes a Barrier to Change Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "It took me a while to realize that that's what I was doing. I felt the reason wasn't working was them, it wasn't me." - Steve Martin Steve carried the Scrum Guide like a Bible in his early days as an Agile coach. He was a purist—convinced he had an army of Agile practitioners behind him, ready to transform every team he encountered. When teams questioned his approach, he would shut down the conversation: "Don't challenge me on this, because this is how it's supposed to be." But pushing against the tide and spreading the gospel created something unexpected: resistance. The more Steve insisted on his purist view, the more teams pushed back. It took him a couple of years to recognize the pattern. The problem wasn't the teams refusing to change—it was his approach. Steve's breakthrough came when he started teaching and realized he needed to meet people where they are, not force them to come to him. Like understanding a customer's needs, he learned to build empathy with teams, Product Owners, and leaders. He discovered the power of creating personas for the people he was coaching, understanding their context before prescribing solutions. The hardest part wasn't learning this lesson—it was being honest about his failures and admitting that his righteous certainty had been the real impediment to transformation. Self-reflection Question: Are you meeting your teams where they are, or are you pushing them toward where you think they should be? [The Scrum Master Toolbox Podcast Recommends]
Xmas Special: Recovering the Essence of Agile - What's Already Working in Software-Native Organizations In this BONUS Xmas Special episode, we explore what happens when we strip away the certifications and branded frameworks to recover the essential practices that make software development work. Building on Episode 2's exploration of the Project Management Trap, Vasco reveals how the core insights that sparked the Agile revolution remain valid - and how real organizations like Spotify, Amazon, and Etsy embody these principles to thrive in today's software-driven world. The answer isn't to invent something new; it's to amplify what's already working. Agile as an Idea, Not a Brand "The script (sold as the solution) will eventually kill the possibility of the conversation ever happening with any quality." We establish a parallel between good conversations and good software development. Just as creating "The Certified Conversational Method™" with prescribed frameworks and certification levels would miss the point of genuine dialogue, the commodification of agile into Agile™ has obscured its essential truth. The core idea was simple and powerful: build software in small increments, get it in front of real users quickly, learn from their actual behavior, adapt based on what you learn, and repeat continuously. This wasn't revolutionary - it was finally recognizing how software actually works. You can't know if your hypothesis about user needs is correct until users interact with it, so optimize for learning speed, not planning precision. But when the need to certify and validate "doing Agile right" took over, the idea got packaged, and often the package became more important than the principle. Four Fundamental Practices That Enable Living Software "Every deployment was a chance to see how users actually responded." Software-native organizations distinguish themselves through core practices that align with software as a living capability. In this episode, we review four critical ones: First, iterative delivery means shipping the smallest valuable increment possible and building on it - Etsy's transformation from quarterly releases in 2009 to shipping 50+ times per day by 2012 exemplifies this approach, where each small change serves as a learning opportunity. Second, tight feedback loops get software in front of real users as fast as possible, whether through paper prototypes or production deployments. Third, continuous improvement of the process itself creates meta-feedback loops, as demonstrated by Amazon's "You Build It, You Run It" principle introduced by Werner Vogels in 2006, where development teams running their own services in production learn rapidly to write more resilient code. Fourth, product thinking over project thinking organizes teams around long-lived products rather than temporary projects, allowing teams to develop deep expertise and become living capabilities themselves, accumulating knowledge and improving over time. Spotify's Evolutionary Approach "The Spotify model has nothing to do with Spotify really. It was just a snapshot of how that one company worked at the time." Spotify's journey reveals a critical insight often missed in discussions of their famous organizational model. Starting with standard Scrum methodology pre-2012, they adopted the squad model around 2012 with autonomous teams organized into tribes, documented in Henrik Kniberg and Anders Ivarsson's influential white paper (direct PDF link). But post-2016, internal staff and agile coaches noted that the "Spotify model" had become mythology, and the company had moved on from original concepts to address new challenges. As Kniberg himself later reflected, the model has taken on a life of its own, much like Lean's relationship to Toyota. The key insight isn't the specific structure - it's that Spotify treated their own organizational design as a living capability, continuously adapting based on what worked and what didn't rather than implementing "the model" and declaring victory. That's software-native thinking applied to organization design itself. Amazon's Two-Pizza Teams and Massive Scale "Amazon deploys code every 11.7 seconds on average. That's over 7,000 deployments per day across the organization." (see this YouTube video of this talk) Amazon's two-pizza team principle goes far deeper than team size. Teams small enough to be fed with two pizzas (roughly 6-10 people) gain crucial autonomy and ownership: each team owns specific services and APIs, makes their own technical decisions, runs their services in production, and manages inter-team dependencies through APIs rather than meetings. This structure enabled Amazon to scale massively while maintaining speed, as teams could iterate independently without coordinating with dozens of other teams. The staggering deployment frequency - over 7,000 times per day as of 2021 - is only possible with a software-native structure for the company itself, demonstrating that this isn't just about managing software delivery but touches everything, including how teams are organized. Why These Practices Work "These practices work because they align with what software actually is: a living, evolvable capability." The effectiveness of software-native approaches stems from their alignment with software's true nature. Traditional project approaches assume we can know requirements upfront, estimate accurately, build it right the first time, and reach a meaningful "done" state. Software-native approaches recognize that requirements emerge through interaction with users, estimation is less important than rapid learning, "right" is discovered iteratively rather than designed upfront, and "done" only happens when we stop evolving the software. When Etsy ships 50 times per day, they're optimizing for learning where each deployment is a hypothesis test. When Amazon's teams own services end-to-end, they're creating tight feedback loops where teams feel the pain of their own decisions directly. When Spotify continuously evolves their organizational model, they're treating their own structure as software that should adapt to changing needs. The Incomplete Picture and the Question of Universal Adoption "If these approaches work, why aren't they universal?" We're not trying to paint a unrealistically rosy picture - these organizations aren't perfect. Spotify has had well-documented challenges with their model, Amazon's culture has been criticized as demanding and sometimes brutal, and Etsy has gone through multiple strategic shifts. But what matters is that they're practicing software-native development at scale, and it's working well enough that they can compete and thrive. They're not following a playbook perfectly but embodying principles and adapting continuously. This raises the critical question that will be explored in the next episode: if these approaches work, why do so many organizations still operate in project mode, and why do "agile transformations" so often fail to deliver real change? Understanding the resistance - what we call The Organizational Immune System - is essential to overcoming it. References for Further Reading A book on the shift from "projects" to "products": "Project to Product" by Mik Kersten About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.
We love to say we're Agile… but then we bury our teams under complexity, overstuffed user stories, bloated processes, and “just in case” documentation.In this episode, Kate Megaw and Ryan Smith unpack one deceptively simple piece of Scrum wisdom inspired by a quote from Steven Merchant: You can always simplify.From product backlog items that read like novels, to daily scrums that feel like executive status meetings, to processes that exist only because “that's the rule” - this conversation dives into why teams overcomplicate, how fear sneaks into our work, and what Scrum looks like when we finally let go.If your teams feel busy but not effective, this one's for you.
Natalia Curusi: From Spreadsheets to Discovery—Helping POs Make the Transition The Great Product Owner: Taking Ownership and Coaching the Team Forward Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "That person was not just a great product owner, but a great coach—he had excellent communication and stakeholder management skills, and he coached myself as a Scrum Master, showing me how product ownership should look like." - Natalia Curusi Natalia worked with a Product Owner who embodied everything the role should be. He didn't come from a technical background, but he possessed exceptional domain knowledge, outstanding communication skills, and stakeholder management expertise you rarely find in one person. What made him truly remarkable was that he coached everyone around him, including Natalia as the Scrum Master. He demonstrated full empowerment and ownership—making decisions himself rather than constantly escalating to higher management. When risks needed to be taken, he took them with courage and conviction. The team trusted him completely because he balanced business needs with team capacity, always understanding what they could realistically achieve. Over the past five years, this person has been promoted multiple times and now serves as a global director of product, still with the same company. When Natalia thinks about what great product ownership looks like, she thinks of him—someone who combined technical understanding with coaching ability, took genuine ownership of outcomes, and empowered the team through clear vision and decisive leadership. These are exactly the skills that are hardest to find in the market, yet when you find them, the impact is transformative for the entire organization. Self-reflection Question: Does your Product Owner take ownership and make decisions, or do they constantly escalate to higher management, preventing the team from moving forward with confidence? The Bad Product Owner: Assigned Without Training, Support, or Willingness "She was a great subject matter expert with deep domain knowledge, but the organization assigned her the product owner role without her willingness, without training, and while she was already 80% loaded with other responsibilities." - Natalia Curusi Natalia encountered a Product Owner anti-pattern that reveals a systemic organizational failure. The person was an exceptional subject matter expert with incredible domain knowledge, but when the organization decided to adopt Agile, they assigned her the PO role like sticking a label on a box—no training, no consent, no preparation. She was already working at 80% capacity on other responsibilities and had no understanding of what product ownership meant. Frustrated and overwhelmed, she approached the role from a command-and-control mindset. At the project start, she brought a massive spreadsheet of requirements, expecting the team to implement them sequentially. The team tried a different approach, wanting to understand problems before discussing solutions, but the PO surprised everyone by re-introducing the spreadsheet in a later meeting—a clear sign of misalignment and broken trust. Natalia, recognizing this was a battle she couldn't win without organizational support, chose to manage the relationship rather than create open conflict. She worked to mediate between the PO's spreadsheet approach and the team's need for discovery and iterative development. The real anti-pattern wasn't the individual—it was the organization assigning critical roles without providing training, time, or psychological safety. This situation illustrates why product ownership fails: not from bad people, but from bad systems that set people up to fail. Self-reflection Question: When you see a struggling Product Owner, are you addressing the individual's behavior or the systemic conditions that set them up to fail in the first place? [The Scrum Master Toolbox Podcast Recommends]
Natalia Curusi: Measuring What Matters Beyond Velocity and Story Points Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "We as Scrum Masters need to put a scope for ourselves—we need to aim to leave the place where we work a little bit better than it was, and to make sure that this place could improve itself without us." - Natalia Curusi Natalia defines success for Scrum Masters with crystal clarity: leave the organization better than you found it, and ensure it can continue improving when you're gone. This means fostering independence and ownership in teams so they can perform whether you're on vacation, in another meeting, or have moved to coaching other teams. The opposite pattern—where everything falls apart when the Scrum Master isn't present—reveals someone who hasn't truly succeeded in the role. Natalia also emphasizes the importance of establishing metrics early, but not the traditional ones. Using velocity as a metric is an anti-pattern that focuses teams on the wrong outcomes. Instead, she recommends metrics like predictability, team morale, psychological safety measured through 360 feedback, and the quality of conversations both within teams and with stakeholders. But metrics alone don't tell the story. Natalia champions the concept of Gemba walks—going to see what's actually happening, talking to people, observing the reality rather than just reviewing dashboard numbers. Some metrics are easily gamed, others provide only narrow perspectives on reality. The most important practice is using metrics to trigger reflection and adaptation, not as fixed targets. Natalia believes strongly that the quality of conversations—how teams discuss options, make decisions together, and adapt when facing pressure—reveals more about a Scrum Master's success than any velocity chart ever could. The ultimate question: can your team succeed without you? Self-reflection Question: If you disappeared from your team tomorrow, would they continue improving, or would progress stop until someone replaced you? Featured Retrospective Format for the Week: Spotify Squad Health Check "This is a multidimensional retro that I run with teams every 2 to 3 months—you need around 30 minutes for it, and I often get insights and new ideas from this retrospective that help me as a Scrum Master." - Natalia Curusi The Spotify Squad Health Check is Natalia's favorite retrospective format because it provides a comprehensive view of team health across multiple dimensions. Unlike traditional retrospectives that might focus on a single sprint or specific issue, this format examines the team's overall state across areas like teamwork, support, mission clarity, and technical quality. Teams rate themselves on various health indicators, creating a visual representation that reveals patterns over time. What makes this particularly valuable is that it works whether you know the team well or are just starting with them—either way, you gain insights and "aha moments" about where the team truly stands. The multidimensional nature prevents teams from optimizing just one aspect while neglecting others, and the regular cadence (every 2-3 months) allows you to track trends and celebrate improvements. For Natalia, this format consistently surfaces the hidden challenges that teams might not raise in regular retrospectives, making it an essential tool in her Scrum Master toolkit. [The Scrum Master Toolbox Podcast Recommends]
How I Turn Around a Struggling Scrum Team in 90 DaysPeople often assume you can “fix” a struggling Scrum team by tightening ceremonies, updating Jira / Azure Devops, or pushing velocity. It's a nice idea, but it's not real. Teams don't turn around because you run cleaner standups. They turn around because the system around them becomes clearer, more aligned, and more stable.After coaching and leading delivery teams across banks, telcos, utilities, airports, insurers, and product companies, I've seen the same pattern repeat. A real turnaround takes time. Ninety days is the right horizon. Not because teams are slow, but because real change happens in stages.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/
В этом выпуске «Scrum‑мастерской» Мария Дьякова разговаривает с Артуром Неком, лидером направления целеполагания в Сбере. Он рассказывает, как пришёл к OKR через задачи стыковки подразделений в ритейле и построение системы целеполагания в компании Reg.ru, почему увидел именно в этом подходе не только способ считать цифры, но и инструмент для осмысленного диалога между командами и руководителями.Гости разбирают, чем OKR отличаются от KPI, какие задачи реально решают с их помощью разные компании — от Intel до Amazon, и какие существуют «школы» применения OKR. Артур делится примерами типичных ошибок в формулировке целей, объясняет, что такое амбициозность в метриках на самом деле, и показывает, как OKR помогают фокусироваться на важных рычагах роста, вовремя «переобуваться» и снижать конфликты между уровнями управления.Слушайте выпуск на всех популярных платформах: ⚪️ Apple: https://apple.co/467bc3C
Natalia Curusi: Demonstrating Your Value When the Market Questions Agile Roles Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "My challenging topic is about the demand of agility in the market—how do we fit ourselves as scrum masters in that AI era? How can we demonstrate our competence and contribution when there's a perception that agile roles bring little value?" - Natalia Curusi Natalia faces the challenge every Scrum Master in 2025 grapples with: how to demonstrate value in an era when business perceives agile roles as optional overhead. The market has contracted, companies are optimizing budgets, and Scrum Masters often appear first on the chopping block. There's talk of "blended roles" where developers are expected to absorb Scrum Master responsibilities, and questions about how AI might replace the human facilitation work that coaches provide. But Natalia believes the answer lies in understanding something fundamental: the Scrum Master is a deeply situational and contextual role that adapts to what the team needs each day. Some teams need help with communication spaces, others need work structure like Kanban boards, still others need translation between technical realities and stakeholder expectations. The challenge is that this situational nature makes it incredibly hard to explain to business leaders who think in fixed job descriptions and measurable outputs. Natalia's approach involves bringing metrics—not velocity, which focuses on the wrong things, but metrics around team independence, continuous improvement, and organizational capability. She suggests concepts like Gemba walks—going to see what's actually happening rather than relying only on numbers. The real question Natalia poses is this: the biggest value we can bring to an organization is to leave it better than we found it, but how do we make that visible and tangible to business stakeholders who need justification for our roles? Self-reflection Question: If you had to demonstrate your value as a Scrum Master using only observable evidence from the past month, what would you show your leadership? [The Scrum Master Toolbox Podcast Recommends]
Natalia Curusi: The Dark Side of High-Performing Dream Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I was proud of this team—I helped form them from the start, we traveled to the client together, they were mature and independent, they even jelled outside the workplace. This was my dream team." - Natalia Curusi Natalia had built something special. The team was technically strong, emotionally connected, and highly productive. They socialized outside work, traveled together to client sites, and operated with remarkable independence. But when a new junior developer joined, everything started to unravel. The existing team members were like heroes—fast, skilled, confident. The newcomer couldn't keep pace, and slowly Natalia noticed something disturbing: the team started making fun of the new member during retrospectives and stand-ups. The person became an outlier, a black swan ignored by the group. Natalia conducted one-on-one meetings with both the new member and the team, but the situation only worsened. The new person insisted they were fine and didn't need help. The team members claimed they were just joking around. Meanwhile, the team structure and morale deteriorated. Natalia realized she was watching her dream team self-destruct through a form of bullying—something she hadn't even recognized at the time. Finally, she understood she couldn't handle this alone and escalated to the head of discipline and the organizational psychologist. Together, they decided to rotate the person to another team where they felt more comfortable. Natalia learned a painful lesson: as Scrum Masters, we don't need to solve everything ourselves, and sometimes the best solution is recognizing when to use the support structure around us rather than treating it as a personal failure. In this episode, we refer to Coaching Agile Teams by Lyssa Adkins and Training from the Back of the Room by Sharon Bowman. Self-reflection Question: When have you witnessed subtle forms of exclusion in your team, and did you recognize them early enough to intervene effectively? Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins "This was the first book about agile coaching that I read, and it's how I understood that I was already playing the scrum master role without even knowing it—I understood that I was already acting like a glue for the team." - Natalia Curusi Natalia discovered Coaching Agile Teams at a pivotal moment in her career. The book revealed something profound: if you're irreplaceable, there's a problem. A great Scrum Master or coach makes themselves obsolete by growing team members who can replace them. The team should be able to perform independently when you're on vacation or move to another assignment. Lyssa Adkins showed Natalia that she needed to let go of over-control and over-responsibility, focusing instead on growing the team's capabilities. The book remains one of Natalia's top recommendations for every junior Scrum Master wanting to embrace the role, alongside Training from the Back of the Room, which teaches facilitators how to run interactive workshops where people learn from each other rather than just listening to slides. [The Scrum Master Toolbox Podcast Recommends]
Episode Overview In this episode of the John Kitchens Coach Podcast, John Kitchens and Joel Perso break down Milestone 5 of the Agent to CEO Framework: The Execution Roadmap—the critical bridge between strategy and real-world results. Most agents don't fail because they lack ideas or effort. They fail because they work on the wrong things, in the wrong order, with no execution rhythm. John and Joel unpack why second-best problems kill momentum, how to identify the single biggest constraint in your business, and how elite CEOs turn long-term vision into focused 90-day sprints. This episode is a masterclass in prioritization, accountability, and disciplined execution—designed for agents and team leaders who are done guessing and ready to scale with intention. Key Topics Covered Why Most Businesses Stall The real reason businesses fail: working hard on the wrong problems Why second-best problems only create incremental results How to identify the one thing that can 2–3X your business in 90 days The CEO Mindset Shift Moving from task-based thinking to purpose-driven execution Understanding your role as a leader in an AI-powered, consumer-driven market Why your value must go beyond tasks that can be automated Identifying Your True Constraint The most common constraints at each revenue level: Under six figures: no compelling offer Six figures to $500K: not enough leads $500K–$1M: conversion issues $1M–$3M: delivery bottlenecks and owner dependency Traffic, conversion, fulfillment, and retention—how to diagnose what's really broken The Execution Roadmap Explained Turning strategy into a focused 90-day action plan Why one priority per quarter beats five half-finished initiatives How to reverse engineer outcomes instead of guessing your way forward Setting Objectives That Actually Work Writing clear, measurable objective statements Defining success before starting Avoiding vague goals filled with buzzwords and zero accountability Key Results & Accountability How to define results—not tasks Why numbers matter more than opinions Creating key results that stretch the team without overwhelming them Ownership & Execution Rhythm The power of single-point ownership (one person, not a committee) Using weekly sprints to maintain momentum Why reporting beats brainstorming in execution meetings How Scrum principles accelerate progress without chaos Build, Fix, or Optimize Deciding whether your next move is: Building something new Fixing what's broken Optimizing what's already working Why optimization often produces the fastest ROI Resources & Mentions Agent to CEO Framework – Core operating system for scaling with clarity Scrum by Jeff Sutherland – Execution rhythm and sprint methodology Good Strategy / Bad Strategy by Richard Rumelt CoachKitchens.ai – AI-powered execution support for real estate CEOs John Kitchens Executive Coaching → https://johnkitchens.coach Final Takeaway Execution—not effort—is the difference between agents who stay stuck and CEOs who scale. If you can identify your real constraint, commit to one priority, assign clear ownership, and execute in focused 90-day sprints, everything changes. Clarity eliminates overwhelm. Discipline creates momentum. And momentum compounds into freedom. "If you could only work on one thing for the next 90 days that would 2–3X your business, what would it be?" That question—and your willingness to answer it honestly—determines your next level. Connect with Us: Instagram: @johnkitchenscoach LinkedIn: @johnkitchenscoach Facebook: @johnkitchenscoach If you enjoyed this episode, be sure to subscribe and leave a review. Stay tuned for more insights and strategies from the top minds. See you next time!
Natalia Curusi: When Your Technical Expertise Becomes Your Biggest Scrum Master Weakness Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I thought my technical background was my biggest strength, but I understood that this was my biggest weakness—I was coming into stand-ups saying 'I know how we need to fix that issue,' and I was a Scrum Master." - Natalia Curusi Natalia stepped into her first blended role as team leader and Scrum Master full of confidence. With years of programming experience behind her, she believed she could guide her team through any technical challenge. But during morning stand-ups, she found herself suggesting solutions, directing technical approaches, and sharing her expertise freely. The team listened—after all, she was their former leader. They implemented her suggestions, but when those solutions failed, the team didn't have the thinking process to adapt them to their context. Natalia realized she was preventing the team's learning and ownership by taking control away from them. The turning point came when she made a deliberate choice: she selected the most technical person on the team to become the technical authority and committed to never stepping on his feet again. From that moment forward, she focused purely on the Scrum Master role—asking questions, fostering collaboration, and shutting up to listen actively. Years later, that technical lead followed her to another job, and they remain friends to this day. Natalia learned that her contribution wasn't about giving solutions—it was about keeping the team from losing ownership of their work. Self-reflection Question: When you attend your team's daily stand-up, are you contributing to collaboration, or is your contribution keeping the team from owning their work? [The Scrum Master Toolbox Podcast Recommends]
Episode Overview In this episode of the John Kitchens Coach Podcast, John Kitchens and Joel Perso break down Milestone 5 of the Agent to CEO Framework: The Execution Roadmap—the critical bridge between strategy and real-world results. Most agents don't fail because they lack ideas or effort. They fail because they work on the wrong things, in the wrong order, with no execution rhythm. John and Joel unpack why second-best problems kill momentum, how to identify the single biggest constraint in your business, and how elite CEOs turn long-term vision into focused 90-day sprints. This episode is a masterclass in prioritization, accountability, and disciplined execution—designed for agents and team leaders who are done guessing and ready to scale with intention. Key Topics Covered Why Most Businesses Stall The real reason businesses fail: working hard on the wrong problems Why second-best problems only create incremental results How to identify the one thing that can 2–3X your business in 90 days The CEO Mindset Shift Moving from task-based thinking to purpose-driven execution Understanding your role as a leader in an AI-powered, consumer-driven market Why your value must go beyond tasks that can be automated Identifying Your True Constraint The most common constraints at each revenue level: Under six figures: no compelling offer Six figures to $500K: not enough leads $500K–$1M: conversion issues $1M–$3M: delivery bottlenecks and owner dependency Traffic, conversion, fulfillment, and retention—how to diagnose what's really broken The Execution Roadmap Explained Turning strategy into a focused 90-day action plan Why one priority per quarter beats five half-finished initiatives How to reverse engineer outcomes instead of guessing your way forward Setting Objectives That Actually Work Writing clear, measurable objective statements Defining success before starting Avoiding vague goals filled with buzzwords and zero accountability Key Results & Accountability How to define results—not tasks Why numbers matter more than opinions Creating key results that stretch the team without overwhelming them Ownership & Execution Rhythm The power of single-point ownership (one person, not a committee) Using weekly sprints to maintain momentum Why reporting beats brainstorming in execution meetings How Scrum principles accelerate progress without chaos Build, Fix, or Optimize Deciding whether your next move is: Building something new Fixing what's broken Optimizing what's already working Why optimization often produces the fastest ROI Resources & Mentions Agent to CEO Framework – Core operating system for scaling with clarity Scrum by Jeff Sutherland – Execution rhythm and sprint methodology Good Strategy / Bad Strategy by Richard Rumelt CoachKitchens.ai – AI-powered execution support for real estate CEOs John Kitchens Executive Coaching → https://johnkitchens.coach Final Takeaway Execution—not effort—is the difference between agents who stay stuck and CEOs who scale. If you can identify your real constraint, commit to one priority, assign clear ownership, and execute in focused 90-day sprints, everything changes. Clarity eliminates overwhelm. Discipline creates momentum. And momentum compounds into freedom. "If you could only work on one thing for the next 90 days that would 2–3X your business, what would it be?" That question—and your willingness to answer it honestly—determines your next level. Connect with Us: Instagram: @johnkitchenscoach LinkedIn: @johnkitchenscoach Facebook: @johnkitchenscoach If you enjoyed this episode, be sure to subscribe and leave a review. Stay tuned for more insights and strategies from the top minds. See you next time!
The Rugby Odds: George Hook solves Scrum Crisis, Shameful Sharks, Super Saints, Glasgow Game, Dupont by Matt McCarthy
We're doing Scrum. Why does everything take so long to finish?For many teams, delivery bogs down because of the way individuals approach the work itself.Most teams are still working in a sequence: one person finishes their part, hands it off, and then the next person begins. Designers wait for analysis to finish. Developers wait for designs. Testers wait for the code to be done. Everyone's optimizing for their own efficiency — but the team as a whole slows down.That might feel to individuals like the “right” way to work, but it comes with real costs: Mistakes go unnoticed until late in the process — and keep happening until then.Too much work is started toward the end of the sprint, creating bottlenecks and delays, which means features take longer to reach your users, and feedback takes longer to reach the team.Time to market, or time to value, is extended.Even when teams are doing “agile” on the surface, these large handoffs are the opposite of how an agile team works.To deliver value quickly, team members have to learn to stop waiting for someone else to finish before they start–in other words, they need to overlap work.When one type of task looks like it's dependent on another type of task, teams accustomed to overlapping work find ways to begin the second task before the first is completed. Coders start coding while the designer is still designing. Testers start creating tests even while the coder is coding.Why do teams cling to this outdated way of working?When teams first try working this way, many team members resist it. They're used to holding on to their work until it's perfect and “ready.” They might find the idea of overlapping work to be too messy and inefficient.Consider, for example, a tester. To be as efficient as possible, this tester would like to begin testing only after coding is complete. To test any earlier risks repeating work by re-running, or even re-designing, tests.What these team members need to realize is that optimizing for the efficiency of any one role prolongs the amount of time it takes to complete each new feature. Overlapping work is key to working in an agile way.For example, imagine that a developer is building a search results page for an eCommerce site. The page allows users to filter results by product attributes such as size, color, and more. Results can also be sorted by price, popularity, rating, and so on. If a programmer develops all of that before handing it over to a tester then no work has overlapped.If, however, the programmer handed it to the tester in pieces then testing could overlap with programming. The programmer could, for example, provide the tester with a version of the page without filtering or sorting. While a tester checks that, the developer adds filtering by size. Then color. Then sorting. The work overlaps — and everything moves faster.Two simple ways to encourage this way of working:Ask teams to shrink task size. Breaking big tasks into bite-sized pieces makes it easier for roles to overlap and collaborate. As handoffs get smaller, collaboration gets easier.Try swarming. Swarming is an extreme form of overlapping work that helps teams learn to let go of a “my work, your work” mindset and sequential “finish-to-start” mentality. When a team swarms, the whole team focuses on just one (or maybe two) items at a time.I'm not suggesting swarming as a long-term solution or the optimal way to work. It's a temporary, artificial constraint on work in process designed to force teams to find new ways to collaborate and move faster together. The goal is to remove the limit later, and have team members continue to apply the lessons they learned when they were forced to over-collaborate.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/
Scott Smith: Empathy and Availability Define Excellent Product Ownership Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Always Present, Always Available, Always Curious "They are always present. They always make themselves available for team members that need them." - Scott Smith Scott is currently working with a Product Owner who exemplifies what great PO collaboration looks like. This person is always present—not just physically but mentally engaged with the team's work and challenges. They make themselves available for team members who need them, responding actively on the team chat and interacting consistently. What makes this PO stand out is their empathy and curiosity. Instead of being defensive when questions arise or challenges emerge, they lean into helping the team understand and solve problems. They show genuine curiosity about what the team is experiencing, asking questions and exploring solutions together rather than dictating answers. This PO understands that their role isn't to be the smartest person in the room but to be the most available, most collaborative, and most curious. The result is a team that feels supported and empowered, with clear direction and someone who genuinely helps them answer the hard questions. Scott's experience with this PO demonstrates that presence, availability, empathy, and curiosity are the foundations of great Product Owner work. Self-reflection Question: How present and available are you to your team, and do you approach their questions with curiosity or defensiveness? The Bad Product Owner: Never There When the Team Needs Direction "The PO was never present. The team had lack of clarity, and vision, and had no direction or someone who would help answer those questions." - Scott Smith Scott has also experienced the opposite extreme—a Product Owner who was never present. This absence created a cascade of problems for the team. Without regular access to the PO, the team lacked clarity about priorities, vision, and direction. They had questions that went unanswered and decisions that couldn't be made. The result was frustration and a team that couldn't move forward effectively. An absent PO creates a vacuum where uncertainty thrives. Teams end up making assumptions, second-guessing decisions, and feeling disconnected from the purpose of their work. The lack of someone who can help answer strategic questions or provide guidance means the team operates in the dark, building things without confidence that they're building the right things. Scott's experience highlights a fundamental truth about Product Ownership: presence isn't optional. Teams need a PO who shows up, engages, and stays connected to the work. Without that presence, even the most skilled team will struggle to deliver value because they can't align their efforts with the product vision and customer needs. Self-reflection Question: If your team were asked whether you're present and available as a Product Owner or Scrum Master, what would they say? [The Scrum Master Toolbox Podcast Recommends]
Scott Smith: Using MIRO to Build a Living Archive of Learning Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "We're in a servant leadership role. So, ask: is the team thriving? That's a huge indication of success." - Scott Smith For Scott, success as a Scrum Master isn't measured by velocity charts or burn-down graphs—it's measured by whether the people are thriving. This includes everyone: the development team and the Product Owner. As a servant leader, Scott's focus is on creating conditions where teams can flourish, and he has practical ways to gauge that health. Scott does a light touch check on a regular basis and a deeper assessment quarterly. Mid-sprint, he conducts what he calls a "vibe" check—a quick pulse to understand how people are feeling and what they need. During quarterly planning, the team retrospects and celebrates achievements from the past quarter, keeping and tracking actions to ensure continuous improvement isn't just talked about but lived. Scott's approach recognizes that success is both about the work being done and the people doing it. When teams feel supported, heard, and valued, the work naturally flows better. This people-first perspective defines what great servant leadership looks like in practice. Self-reflection Question: How often do you check in on whether your team is truly thriving, and what specific indicators tell you they are? Featured Retrospective Format for the Week: MIRO as a Living History Museum "Use the multiple retros in the MIRO board as a shared history museum for the team." - Scott Smith Scott leverages MIRO not just as a tool for running retrospectives but as a living archive of team learning and growth. He uses MIROVERSE templates to bring diversity to retrospective conversations, exploring the vast library of pre-built formats that offer themed and structured approaches to reflection. The magic happens when Scott treats each retrospective board not as a disposable artifact but as part of the team's shared history museum. Over time, the accumulation of retrospective boards tells the story of the team's journey—what they struggled with, what they celebrated, what actions they took, and how they evolved. This approach transforms retrospectives from isolated events into a continuous narrative of improvement. Teams can look back at previous retros to see patterns, track whether actions were completed, and recognize how far they've come. MIRO becomes both the canvas for current reflection and the archive of collective learning, making improvement visible and tangible across time. [The Scrum Master Toolbox Podcast Recommends]
Scott Smith: Building a Coaching Service Where Survey Scores Become Living Improvement 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 is about feedback from coaching clients." - Scott Smith Scott is tackling one of the most challenging aspects of organizational transformation: turning annual survey results into continuous improvement. Working with a domain of about 30 people, Scott is exploring how to create a coaching service that doesn't just react to once-a-year data but actively drives ongoing growth. The typical pattern in many organizations is familiar—conduct an annual survey, review the scores, maybe have a few discussions, and then wait another year. Scott is experimenting with a different approach. He's setting up a coaching service that focuses on real-time feedback from the people being coached, making improvement a living practice rather than an annual event. The strategy starts with a pilot, testing the concept before scaling across the entire domain. Scott's measure of success is pragmatic and human-centered: feedback from coaching clients. Not abstract metrics or theoretical frameworks, but whether the people receiving coaching find value in what's being offered. This approach reflects a fundamental principle of Agile coaching—start small, experiment, gather feedback, and iterate based on what actually works for the people involved. Scott is building improvement infrastructure that puts continuous learning at the center, transforming how organizations think about growth from an annual checkbox into an ongoing conversation. Self-reflection Question: If you were to implement a coaching service in your organization, how would you measure its success beyond traditional survey scores? [The Scrum Master Toolbox Podcast Recommends]
In this week's Rugby Pod, the lads wrap up the Quilter Nations Series before diving head-first into the return of domestic rugby, with big Premiership and URC results to get stuck into. We're also welcoming Springbok legend Gurthrö Steenkamp for an unbelievable deep-dive into scrum culture, Rassie's revolution, and life in France. We check in on Bath's statement win at the StoneX to Exeter's comeback in Sale, plus a massive round in the URC as the Stormers storm Thomond and Scarlets stun Glasgow. The Rugby F.C. documentary has blown up on YouTube, fans are asking how to help Rugby Lions FC, and we're back on the road with a London live show this Wednesday ahead of the Champions Cup kicking off exclusively on Premier Sports. Add in some transfer news, a few reds in France, and all the Good, Bad & Ugly, and some shoutouts, and it's another stacked episode of the world's most listened-to rugby podcast. Learn more about your ad choices. Visit podcastchoices.com/adchoices
Scott Smith: Why Great Scrum Masters Create Space for Breaks Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Think of the people involved. Put yourself in the shoes of the other." - Scott Smith Scott found himself in the middle of rising tension as voices escalated between the Product Owner and the development team. The PO was harsh, emotions were running high, and the conflict was intensifying with each exchange. In that moment, Scott knew he had to act. He stepped in with a simple but powerful reminder: "We're on the same team." That pause—that momentary break—allowed everyone to step back and reset. Both the PO and the team members later thanked Scott for his intervention, acknowledging they needed that space to cool down and refocus on their shared outcome. Scott's approach centers on empathy and perspective-taking. He emphasizes thinking about the people involved and putting yourself in their shoes. When tensions rise, sometimes the most valuable contribution a Scrum Master can make is creating space for a break, reminding everyone of the shared goal, and helping teams focus on the outcome rather than the conflict. It's not about taking sides—it's about serving the team by being the calm presence that brings everyone back to what matters most. Self-reflection Question: When you witness conflict between team members or between the team and Product Owner, do you tend to jump in immediately or create space for the parties to find common ground themselves? Featured Book of the Week: An Ex-Manager Who Believed "It was about having someone who believed in me." - Scott Smith Scott's most influential "book" isn't printed on pages—it's a person. After spending 10 years as a Business Analyst, Scott decided to take the Professional Scrum Master I (PSM I) course and look for a Scrum Master position. That transition wasn't just about skills or certification; it was about having an ex-manager who inspired him to chase his goals and truly believed in him. This person gave Scott the confidence to make a significant career pivot, demonstrating that sometimes the most powerful catalyst for growth is someone who sees your potential before you fully recognize it yourself. Scott's story reminds us that great leadership isn't just about managing tasks—it's about inspiring people to reach for goals they might not have pursued alone. The belief and encouragement of a single person can change the trajectory of someone's entire career. [The Scrum Master Toolbox Podcast Recommends]
Scott Smith: The Spotlight Failure That Taught a Silent Lesson About Recognition 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. "Not everybody enjoys the limelight and being called out, even for great work." - Scott Smith Scott was facilitating a multi-squad showcase with over 100 participants, and everything seemed to be going perfectly. Each squad had their five-minute slot to share achievements from the sprint, and Scott was coordinating the entire event. When one particular team member delivered what Scott considered fantastic work, he couldn't help but publicly recognize them during the introduction. It seemed like the perfect moment to celebrate excellence in front of the entire organization. But then his phone rang. The individual he had praised was unhappy—really unhappy. What Scott learned in that moment transformed his approach to recognition forever. The person was quiet, introverted, and conservative by nature. Being called out without prior notice or permission in front of 100+ people wasn't a reward—it was uncomfortable and unwelcome. Scott discovered that even positive recognition requires consent and awareness of individual preferences. Some people thrive in the spotlight, while others prefer their contributions to be acknowledged privately. The relationship continued well afterward, but the lesson stuck: check in with individuals before publicly recognizing them, understanding that great coaching means respecting how people want to be celebrated, not just that they should be celebrated. Self-reflection Question: How do you currently recognize team members' achievements, and have you asked each person how they prefer to be acknowledged for their contributions? [The Scrum Master Toolbox Podcast Recommends]
© 2020-2026 Ivy Podcast Discovery LLC
