Scrum Master Toolbox Podcast: Agile storytelling from the trenches

Every week day, Certified Scrum Master, Agile Coach and Business Consultant Vasco Duarte interviews Scrum Masters and Agile Coaches from all over the world to get you actionable advice, new tips and tricks, improve your craft as a Scrum Master with daily doses of inspiring conversations with Scrum Masters from the all over the world. Stay tuned for BONUS episodes when we interview Agile gurus and other thought leaders in the business space to bring you the Agile Business perspective you need to succeed as a Scrum Master. Some of the topics we discuss include: Agile Business, Agile Strategy, Retrospectives, Team motivation, Sprint Planning, Daily Scrum, Sprint Review, Backlog Refinement, Scaling Scrum, Lean Startup, Test Driven Development (TDD), Behavior Driven Development (BDD), Paper Prototyping, QA in Scrum, the role of agile managers, servant leadership, agile coaching, and more!

BONUS #NoEstimates, Throughput, and the Superstition of Project Management With Felipe Engineer-Manriquez 04/04/2026

BONUS #NoEstimates, Throughput, and the Superstition of Project Management With Felipe Engineer-Manriquez BONUS: Why Your Plan Is Lying to You — #NoEstimates, Throughput, and the Superstition of Project Management This episode is a cross-post from , Felipe Engineer-Manriquez's podcast exploring Lean and Agile in construction. In this conversation, Felipe interviews Vasco about the #NoEstimates movement, throughput-based planning, and why traditional project management is still stuck in the middle ages of managing creative work. The Human Side of Scrum That the Scrum Guide Doesn't Cover "When you go into a daily meeting and you start looking at the people in that room, maybe they are the exact same people that were there yesterday, but the team is totally different. Somebody might have had a bad night's sleep, somebody might have had an argument with their spouse. These are human beings. These are not machines that you can just distribute work to." Vasco's path to agile coaching started with a realization that most practitioners eventually reach: the problems in software development aren't technological. They're about people — getting agreements, sharing information at the right time, making the collective brain of a team actually function. The gives you organizing principles — how many meetings, who's in them — but it says almost nothing about the real-time feedback cycle between humans that makes or breaks a team. That's why the Scrum Master role exists: to be the lubricant for human interactions, to break down complex ideas into items the collective mind can process. It's the piece that makes Scrum work, and it's the piece that's hardest to teach. From Project Manager to #NoEstimates — The Bet That Changed Everything "The PM wanted 15 items per sprint, and the team said 'yeah, we can do 15.' I said, this is not gonna happen. The team had been delivering between five and eight items per sprint. I said, I'm gonna be positive — I'm gonna say seven. And no surprise, by the end of the sprint, they delivered seven." Vasco started as a project manager — and not the easy certification kind. He went through , which means six months of training, a four-hour written exam, and an expert interview, just for the entry level. Planning and estimating was the job. Then he ran his first Scrum project, specifically to prove it couldn't work. By the second month, he couldn't understand how anything else could work. The team delivered something to show every single sprint — something that never happened with traditional project management. The turning point came when he made a bet with a product manager: the PM needed 15 items per sprint, the team committed to 15, but historical throughput was 5-8 items. Reality delivered seven. That moment crystallized the #NoEstimates insight: we can't fight reality, but we can choose which seven items to deliver. Reality Is a Bitch — Why Linear Predictive Planning Fails "Never believe the plan. Or as in Scarface — never get high on your own supply. It's so unbelievable how project managers still today believe their freaking plans." At , Vasco managed a program of 500 people across 100 teams on four continents. No way to get everyone in a room. So he tracked system-level throughput — features delivered to integration per week. Six months into a twelve-month project, the data said they'd be at least six months late. He told the program manager: cut scope now. The program manager did what every PMI-trained program manager does — sent an email asking all 100 teams if they'd deliver on time. Every single team said yes. Nobody wants to be first to admit they're late. Twelve months in, they discovered they were six months late. The project got canceled. 500 people, millions of euros, all because somebody believed the plan. Linear predictive planning is useful for exploring what might be possible if nothing goes wrong. It is not reality. The only tool that reflects reality is throughput — the number of items completed per unit of time. Earned Value Management — George Orwell at His Best "It's not earned, it's spent. It's not value, it's cost. It's not management, it's just observation. Monty Python could not have come up with a better name." Felipe shares a story that mirrors the absurdity: an industrial project with a dedicated 35-person earned value management department. Before the meeting even started, the department head announced, "Let's all acknowledge that earned value management is more an art than a science." Their charts were made up, the contractor's charts were made up, and the goal of the meeting was to agree that the project would finish on time — regardless of what any data said. This is where traditional project management ends up when it disconnects from throughput: a $30 million scope addition with zero additional time, defended by charts that a mediocre attorney can invalidate in the first week of litigation. Felipe knows — he spent a year being cross-examined by forensic schedulers whose full-time job is proving that construction schedules are fiction. One Small Experiment to Test #NoEstimates "Never convince anyone. Convince yourself. Once you're convinced, whatever other people say, it doesn't really matter because you're not gonna take them seriously anyway." Here's how to validate throughput-based planning with your own data: take the last 10 sprints (or periods). Calculate the average throughput and control limits from the first five. Then check whether the next five sprints fall within that range. They will. If you're in software and using , you already have this data. You don't need anyone's permission. You don't need to change anything. Just look at what your team actually delivers versus what they planned to deliver. The gap between those two numbers is the gap between superstition and reality. About Felipe Engineer-Manriquez Felipe Engineer-Manriquez is a best-selling author, international keynote speaker, Project Delivery Services Director at The Boldt Company, host of podcast, and a proven construction change-maker implementing Lean and Agile practices on projects from millions to billions of dollars worldwide. He is a Registered Scrum Trainer™ (RST), Registered Scrum Master™ (RSM), and recipient of the Lean Construction Institute Chairman's Award. His book is the first practical guide for applying Scrum in construction. You can link with . /episode/index/show/scrummastertoolbox/id/40591680

The Adaptable Product Owner — How Progress Over Perfection Drives Real Value in Scrum | Bhavin Shukla 04/03/2026

The Adaptable Product Owner — How Progress Over Perfection Drives Real Value in Scrum | Bhavin Shukla Bhavin Shukla: The Adaptable Product Owner — How Progress Over Perfection Drives Real Value in Scrum In this episode, we refer to as a key tool for maintaining focus and alignment. The Great Product Owner: Embedding Prioritization as a Daily Discipline 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: . "She had this section called 'Not Required Anymore.' Every time, it was a very subtle and a very respectful way of saying to the team: great idea, but the goals changed. We don't need it anymore." - Bhavin Shukla Bhavin describes a Product Owner who turned prioritization into a living discipline. She built a culture of co-creation where everyone contributed ideas to the backlog, but she also saw the biggest risk coming early: misalignment from siloed ideas. Her approach was to use story maps extensively in refinements and planning, communicating weekly with customers to collect feedback. When the direction changed — and it regularly did — she articulated the shift clearly: "Goals changed, here's what we're doing now." Her stroke of genius was a section on the story map called "Not Required Anymore," where deprioritized ideas landed respectfully. Nobody felt offended; they understood customers' needs had shifted. This created a culture where people kept contributing ideas courageously, knowing that even if priorities changed, their input was valued. The result was a team that could adapt without chaos, maintaining focus while embracing change. Self-reflection Question: How does your Product Owner communicate changes in direction? Is there a respectful, transparent mechanism for showing the team what's no longer needed — and why? The Bad Product Owner: The No-Feedback Product Owner 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: . "I was looking for those keywords — a change in priorities, a change in the roadmap. Those conversations were missing. And when I asked about the roadmap, I got crickets." - Bhavin Shukla Bhavin shares the story of a Product Owner who was brilliant at articulating value in the backlog — customer-centric stories, well-structured work. On the surface, everything looked great: goals were being met, the team was delivering. But something subtle was wrong. The roadmap never changed. Priorities never shifted. There were no conversations about customer feedback changing direction. When Bhavin got curious and asked to see the roadmap, he realized it was a static delivery plan, not a living document. The Product Owner wasn't collecting feedback from customers, so there was never a reason to adapt. The team was essentially building in a vacuum — shipping features nobody was validating. It's an anti-pattern that's easy to miss when the team is performing well on internal metrics but disconnected from real customer value. Self-reflection Question: Is your team's roadmap a living document that changes based on customer feedback, or has it become a static delivery plan? When was the last time a priority genuinely shifted based on what you learned from users? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Bhavin Shukla Bhavin joins us from Australia. Bhavin is driven by unlocking potential and helping people thrive in ambiguity through clarity, honesty, and discipline. He believes growth comes from truthful conversations, thoughtful experimentation, and learning from failure. Guided by ownership, confidence, kindness, and purpose, he focuses on what matters most to build meaningful progress for himself and others. You can link with . /episode/index/show/scrummastertoolbox/id/40558910

Why Scrum Master Success Means Confronting the Ugly Truth With Data | Bhavin Shukla 04/02/2026

Why Scrum Master Success Means Confronting the Ugly Truth With Data | Bhavin Shukla Bhavin Shukla: Why Scrum Master Success Means Confronting the Ugly Truth With Data 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: . "Success is not always good vibes, good environment for us as Scrum Masters. For me, it's about confronting the reality, the ugly truth, which takes the team to tougher conversations, more constructive challenges." - Bhavin Shukla Bhavin shares a pivotal moment in his career that redefined what success means for a Scrum Master. He was working with a fantastic team — great culture, people who believed in quality, knowledge sharing, strong bonds. But sprint goals weren't being met, and stakeholders were constantly chasing the Product Owner and Scrum Master for answers. Bhavin got his hands dirty with the data: lack of clarity on work, context switching, patterns emerging. When he presented the data to the team, he was met with silence — a confronting kind of silence. The team was essentially saying, "We were happy. Why would you do this to us?" Bhavin's response was direct: going for coffees and laughing together isn't the whole job. If he wasn't showing them reality, he couldn't look at himself in the mirror. The team eventually used that data to raise their own voice, pointing out systemic issues with external vendors and organizational constraints. The data gave them a platform to speak truth — not as blame, but as discovery. Self-reflection Question: What conversations did you avoid this week that could have unlocked progress for your team? Are you bringing data to those conversations, or relying on vibes? Featured Retrospective Format for the Week: Newspaper Headline Retrospective Bhavin shares an unconventional use of the newspaper headline technique — typically used for roadmaps and vision — as a retrospective format. The idea is simple but powerful: ask the team to write the newspaper headline they want to see about themselves. What would the story say when they succeed? By authoring their own headline, the team takes ownership of the narrative — they define what success looks like, what must go right, and what risks could derail them. "Putting them in that newspaper headline, they authored the story. They own the accountability to make it successful," Bhavin explains. He also shares a second technique for Kanban teams under pressure: a rolling two-column whiteboard — "Frustration of the Day" and "Success of the Day" — with no meetings required, just real-time data capture that becomes a continuous retrospective, reviewed every 2-3 weeks. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Bhavin Shukla Bhavin joins us from Australia. Bhavin is driven by unlocking potential and helping people thrive in ambiguity through clarity, honesty, and discipline. He believes growth comes from truthful conversations, thoughtful experimentation, and learning from failure. Guided by ownership, confidence, kindness, and purpose, he focuses on what matters most to build meaningful progress for himself and others. You can link with . /episode/index/show/scrummastertoolbox/id/40559155

De-Scaling an Agile Organization — Removing Bureaucracy Without Losing Consistency | Bhavin Shukla 04/01/2026

De-Scaling an Agile Organization — Removing Bureaucracy Without Losing Consistency | Bhavin Shukla Bhavin Shukla: De-Scaling an Agile Organization — Removing Bureaucracy Without Losing Consistency 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: . "Before people understand what needs to change, and how they need to adopt, what it means to them in their day-to-day work, and how it's going to help and add value — those conversations are missing." - Bhavin Shukla Bhavin brings a challenge many organizations face but few talk about openly: de-scaling. He's working with an organization that adopted a scaling framework for consistency — shared language, standardized tooling, uniform processes across business units. It worked for alignment, but it also created bureaucracy. Now leadership wants to become leaner and more nimble. The problem? The de-scaling itself is happening cookie-cutter style. Changes are being rolled out — new framework versions, new tools, flow metrics — without explaining the "why" to the people affected. The result is burnout and two parallel ecosystems running simultaneously: the old meeting structures people never abandoned, and the new Scrum events layered on top. Bhavin and his coaching peers ran a "Million Meeting Minutes" workshop, collecting data on how much time teams spend in meetings, what decisions get made (or don't), and who dominates conversations. The data revealed the overlap and waste. The experiment now is mapping those parallel systems and working with teams to understand which problems each structure actually solves — consolidating where possible while maintaining the consistency of language the organization genuinely needs. Self-reflection Question: In your organization, are there parallel meeting structures addressing the same problems? What would it take to map them and start a conversation about consolidation? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Bhavin Shukla Bhavin joins us from Australia. Bhavin is driven by unlocking potential and helping people thrive in ambiguity through clarity, honesty, and discipline. He believes growth comes from truthful conversations, thoughtful experimentation, and learning from failure. Guided by ownership, confidence, kindness, and purpose, he focuses on what matters most to build meaningful progress for himself and others. You can link with . /episode/index/show/scrummastertoolbox/id/40559390

The Hidden Cost of Always Saying Yes — How a Helpful Scrum Team Nearly Self-Destructed | Bhavin Shukla 03/31/2026

The Hidden Cost of Always Saying Yes — How a Helpful Scrum Team Nearly Self-Destructed | Bhavin Shukla Bhavin Shukla: The Hidden Cost of Always Saying Yes — How a Helpful Scrum Team Nearly Self-Destructed 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: . "It was sort of making me feel as a Scrum Master, like it's a slow self-destruction mode they are in. Good intentions, but it wasn't helping them, and that's something that they were not able to notice." - Bhavin Shukla Bhavin tells the story of a banking team that looked like every Scrum Master's dream on day one — humming, cracking jokes, in the zone. But underneath the positive energy, the data told a different story. Sprint commitments kept overflowing, tech debt was rising, P1 and P2 production issues were climbing, and decision latency was immense. The root cause? This team of genuinely helpful people couldn't say no. They wanted to help everyone who came to them, and that desire was slowly drowning them. No one was giving them feedback about the consequences — missed sprint goals were met with "that's okay, we'll do it next sprint." Bhavin introduced two simple tools: an anonymous happiness meter on the wall (rate 1-5, leave a note if below 3) and a gratitude wall. The data revealed the truth — the team was burning out, handling weekend incidents with no escalation path. Armed with this data, Bhavin coached the team on negotiation techniques: you don't have to be rude to say no, you can negotiate the yes, you can negotiate the no. In this segment, we talk about the importance of to surface hidden patterns, and the anti-pattern of teams operating without feedback on the consequences of their decisions. Self-reflection Question: Is your team's positive energy masking underlying problems? What data would help you discover whether good vibes are hiding unsustainable patterns? Featured Book of the Week: by Dominica DeGrandis Bhavin recommends Make Work Visible by Dominica DeGrandis because it goes beyond values and principles to put them into practice in a grounded, system-focused way. "One clear message I get from that book is it's not the people who are the problem, it's the system that we need to work on to improve ways of working," Bhavin shares. The book introduces concepts like the five thieves of time, visualizing work, dependencies, and bottlenecks — connecting lean thinking, Kanban principles, and behavioral patterns into a practical guide for any Scrum Master looking to understand the systems their teams operate in. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Bhavin Shukla Bhavin joins us from Australia. Bhavin is driven by unlocking potential and helping people thrive in ambiguity through clarity, honesty, and discipline. He believes growth comes from truthful conversations, thoughtful experimentation, and learning from failure. Guided by ownership, confidence, kindness, and purpose, he focuses on what matters most to build meaningful progress for himself and others. You can link with . /episode/index/show/scrummastertoolbox/id/40570675

When Protecting Your Agile Team Becomes the Barrier to Their Growth | Bhavin Shukla 03/30/2026

When Protecting Your Agile Team Becomes the Barrier to Their Growth | Bhavin Shukla Bhavin Shukla: When Protecting Your Agile Team Becomes the Barrier to Their Growth 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: . "The perception I had was safe space means insulation from creating that transparency. It was not about protecting the teams. It was actually about giving them the voice, giving them the platform." - Bhavin Shukla Bhavin shares a story from early in his Scrum Master journey, working with two teams building a BI and regulatory platform in Australia. When he arrived, team morale was low — people buried in their screens, going for coffee alone, no healthy debates happening. His natural instinct kicked in: protect the team, help them gel, get the best out of them. But his coach asked a question that changed everything: "What's the balance between protecting the team and creating visibility and transparency?" Bhavin realized he'd been shielding the team from stakeholders, keeping ceremonies closed and conversations siloed. When the team opened up their reviews to stakeholders with clear expectations, something shifted. The backlog started changing based on real feedback, healthy tension built up, and the team started humming. The lesson was profound — creating a safe space doesn't mean insulating the team from reality. Psychological safety isn't the absence of difficult emotions; it's the freedom to have them without destructive patterns. By isolating the team, Bhavin had actually been undermining their trust and growth. Self-reflection Question: Are you protecting your team in ways that might actually be preventing them from building the stakeholder relationships and transparency they need to grow? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Bhavin Shukla Bhavin joins us from Australia. Bhavin is driven by unlocking potential and helping people thrive in ambiguity through clarity, honesty, and discipline. He believes growth comes from truthful conversations, thoughtful experimentation, and learning from failure. Guided by ownership, confidence, kindness, and purpose, he focuses on what matters most to build meaningful progress for himself and others. You can link with . /episode/index/show/scrummastertoolbox/id/40570690

The Firewall Product Owner, Turning PO Anti-Patterns Into Opportunities for Growth | Iryna Stelmakh 03/27/2026

The Firewall Product Owner, Turning PO Anti-Patterns Into Opportunities for Growth | Iryna Stelmakh Iryna Stelmakh: The Firewall Product Owner, Turning PO Anti-Patterns Into Opportunities for Growth 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: . The Great Product Owner: Market-Oriented and Vision-Driven "Great product owners don't just manage backlog items — they own the product vision and make sure the team understands how their work creates real value." — Iryna Stelmakh Iryna describes the best product owners she's worked with through three qualities. First, they understand the market and the users deeply. Second, they can explain the business logic behind decisions — not just what to build, but why it matters. Third, they work closely with the team and treat them as partners in solving problems, not executors of tasks. The best PO Iryna worked with was responsible for sharing the business mindset, giving the team perspective and the possibility to contribute beyond the technical work. Everything was organized around a shared goal, and the team understood how their work created real value. As Vasco observes, when a PO just drops tasks without explaining why they matter, the team becomes "just a pair of hands." Great product owners create allegiance through understanding. Self-reflection Question: Does your product owner share enough business context that your team could independently suggest features or improvements — or are they only able to execute what they're told? The Bad Product Owner: The Firewall Who Blocks All Business Context "We were working without the product mindset, without the product vision." — Iryna Stelmakh Iryna shares the story of what she calls the Firewall Product Owner — a PO who constantly said "I need to go ask someone" for every decision, but never brought back answers. The result: backlog items lacked clarity, priorities changed frequently, and the team couldn't understand the real product direction. They were working without a product mindset or vision. As Vasco frames it, this PO wasn't just a proxy — they were a firewall, blocking the team from accessing any business context or market knowledge. The team couldn't reach the market representatives because they didn't even know who was on the other side. Iryna's approach to this kind of situation: escalate with suggestions, not just complaints. Turn problems into opportunities and extensions — propose bringing in a business analyst to support the PO, or suggest restructuring the communication between the business and technical sides. In her case, the client eventually recognized the problem and replaced the PO with someone who could actually bridge the gap. The new PO changed everything. In this episode, we also refer to the concept of turning problems into opportunities. Self-reflection Question: When your product owner is unable to provide timely answers, do you escalate with specific suggestions for improvement — or do you simply wait and hope things get better? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Iryna Stelmakh Iryna Stelmakh is a Project & Delivery Leader and Agile Coach who helps leaders turn complexity into clarity. With 10+ years across US, Nordic, and Eastern European environments, she works at the intersection of business transformation and human systems, building resilient organizations and high-performing teams in complex contexts. You can link with . /episode/index/show/scrummastertoolbox/id/40424510

The Almost Invisible Scrum Master, Why Team Independence Is the Ultimate Success Metric | Iryna Stelmakh 03/26/2026

The Almost Invisible Scrum Master, Why Team Independence Is the Ultimate Success Metric | Iryna Stelmakh Iryna Stelmakh: The Almost Invisible Scrum Master, Why Team Independence Is the Ultimate Success Metric 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: . "A successful Scrum Master is almost invisible — not because they don't contribute, but because the team is no longer dependent on them for every decision." — Iryna Stelmakh Iryna offers a powerful definition of success for Scrum Masters: becoming almost invisible. Not because the Scrum Master isn't contributing, but because the system works — with or without them. The team takes ownership of delivery, solves problems collaboratively, and continuously improves its own process. Each team member can propose, vote, and suggest changes because the environment has a high level of trust. When that happens, Iryna explains, the Scrum Master becomes more of a system observer and catalyst rather than a daily driver. As Vasco adds, this perspective is valuable because it looks beyond personal metrics — it examines behaviors across all the interactions the Scrum Master facilitates: between the team and the product owner, between the team and stakeholders during reviews, and within the team itself. The Scrum Master role sits at the nexus of many interactions, and success means those interactions work well even when you step back. Self-reflection Question: If you were absent for a full sprint, would your team maintain the same quality of collaboration, decision-making, and delivery — or would things fall apart without you? Featured Retrospective Format for the Week: The Energy Retrospective Iryna shares her favorite retrospective format — one she calls the Energy Retrospective. Instead of the standard "what went well / what didn't" framing, it asks three questions: What gave us energy this sprint? What drained our energy? And what should we start, stop, or continue doing to keep our energy at the right level? This approach shifts the conversation from purely technical task problems to real human dynamics. As Iryna explains, closing technical tasks and resolving issues is important, but so is the wellness of the team. The Energy Retrospective creates space for both. She also notes that retrospective format should match the team: for open, trusting teams, a straightforward format works fine. But for new teams or teams with high resistance — those still in the forming stage where the Scrum Master isn't yet a trusted figure — she uses metaphorical approaches, like asking team members to pick pictures that represent their feelings about the sprint. Even a happy, sad, or frustrated monkey picture can surface insights that direct questions might not. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Iryna Stelmakh Iryna Stelmakh is a Project & Delivery Leader and Agile Coach who helps leaders turn complexity into clarity. With 10+ years across US, Nordic, and Eastern European environments, she works at the intersection of business transformation and human systems, building resilient organizations and high-performing teams in complex contexts. You can link with . /episode/index/show/scrummastertoolbox/id/40424580

Fighting Agile Theater, When Organizations Adopt the Ceremonies But Not the Mindset | Iryna Stelmakh 03/25/2026

Fighting Agile Theater, When Organizations Adopt the Ceremonies But Not the Mindset | Iryna Stelmakh Iryna Stelmakh: Fighting Agile Theater, When Organizations Adopt the Ceremonies But Not the Mindset 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: . "Transparency can be uncomfortable, but without transparency, there is no real improvement." — Iryna Stelmakh Iryna brings a challenge she calls "Agile Theater" — organizations that implement all the visible parts of Agile (the ceremonies, the boards, the terminology) while the underlying mindset remains unchanged. Decisions stay centralized, transparency is avoided, and problems are hidden. As she puts it: "Teams go through the emotions of Agile without actually benefiting from it." But her real challenge goes deeper. Iryna shares a story about building trust with outsourcing clients. Five days into a new assignment on a project the company had worked on for over ten years, she received an email listing team members to be removed — with no explanation. It was a red flag: the absence of transparency signaled that the client relationship lacked the trust bridge needed for genuine collaboration. Iryna's response was characteristically direct. She organized a call with stakeholders and discovered the client operated on quarterly budget cycles — these cuts could happen every three months. Instead of accepting the loss, she shifted the cut team members to other projects within the same account, turning the problem into an opportunity. A QA engineer moved to another project that needed one. A developer and two others got upsold into a team extension. Nobody ended up on the bench. Then came the systemic fix: Iryna set up one-on-one meetings with each stakeholder across different divisions to stay informed in advance. Prevention over reaction — because, as she says, reactions cost more. Self-reflection Question: In your current engagement, do you have direct relationships with the people who make budget and staffing decisions — or would a surprise email catch you completely off guard? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Iryna Stelmakh Iryna Stelmakh is a Project & Delivery Leader and Agile Coach who helps leaders turn complexity into clarity. With 10+ years across US, Nordic, and Eastern European environments, she works at the intersection of business transformation and human systems, building resilient organizations and high-performing teams in complex contexts. You can link with . /episode/index/show/scrummastertoolbox/id/40424750

When Communication Clarity Matters More Than Technical Complexity, A Healthcare Project That Fell Apart | Iryna Stelmakh 03/24/2026

When Communication Clarity Matters More Than Technical Complexity, A Healthcare Project That Fell Apart | Iryna Stelmakh Iryna Stelmakh: When Communication Clarity Matters More Than Technical Complexity, A Healthcare Project That Fell Apart 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: . "Communication clarity is more important than technical complexity, because if you do not understand, it's pretty hard to execute." — Iryna Stelmakh Iryna shares one of her most painful career stories — a project in the healthcare domain focused on cancer treatment research data. When she joined, she was managing around 9 projects simultaneously and agreed to take this one on the condition that a strong technical lead would own the technical direction. The project began with a critical misunderstanding: sales had communicated that the client needed a database redesign, but the client actually needed a migration to a different database type. Similar words, fundamentally different work. For three months, the team worked through research and discovery phases, trying to understand the actual problem. But communication gaps — compounded by language barriers between the Ukrainian development team and the US-based client — prevented them from identifying the real need in time. Iryna trusted the technical lead's reports that everything was on track. She relied instead of checking. Eventually, the client lost confidence and left. It remains the only project in her career she considers a genuine failure. The lesson cuts deep: teams must have people who can ask the right questions early. As Vasco observes, the root cause was implicit assumptions that were never discovered or explored by the different people involved. In this episode, we also talk about the importance of the monitoring and controlling phase in project management. Self-reflection Question: When you trust a team member's assessment that "everything is fine," what verification steps do you take to confirm that understanding is truly shared across all stakeholders? Featured Book of the Week: Team Topologies by Matthew Skelton and Manuel Pais Iryna recommends by Matthew Skelton and Manuel Pais as a book that changed how she thinks about Agile leadership. "Great agile leadership is not only about frameworks, but it's about communication, influence, and the ability to align people around shared goals," she explains. The book helped her understand that Agile isn't just about team process — it's about organizational structure, team boundaries, and responsibilities. She also recommends by Chris Voss for Scrum Masters who want to sharpen their communication and influence tactics. As Iryna puts it, communication is one of the most important skills a Scrum Master must have. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Iryna Stelmakh Iryna Stelmakh is a Project & Delivery Leader and Agile Coach who helps leaders turn complexity into clarity. With 10+ years across US, Nordic, and Eastern European environments, she works at the intersection of business transformation and human systems, building resilient organizations and high-performing teams in complex contexts. You can link with . /episode/index/show/scrummastertoolbox/id/40425960

When "Agile" Becomes a License to Change Everything, The Cost of No Rules in Backlog Management | Iryna Stelmakh 03/23/2026

When "Agile" Becomes a License to Change Everything, The Cost of No Rules in Backlog Management | Iryna Stelmakh Iryna Stelmakh: When "Agile" Becomes a License to Change Everything, The Cost of No Rules in Backlog Management Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: . "For me, it was pretty hard to explain that Agile is about cost reduction, and not about cost increasing." — Iryna Stelmakh Iryna shares a story from one of her first projects as a Scrum Master, working with a client from Israel who saw Scrum as an open invitation to add anything to the backlog at any time. For this client, agility meant unlimited flexibility — the freedom to extend not just the product backlog but the sprint backlog, multiple times per sprint. As Vasco points out, this is a pattern many teams recognize: when there's no cost to disrupting a sprint, it becomes effortless to keep piling on work, destroying the very predictability that sprints are designed to create. Iryna struggled to push back. It was one of her first projects, and the client was confident in his approach. But the experience taught her a lasting lesson: the collaboration with external clients must start with an agreement about how the team works. That means explaining the methodology during the pre-sale phase, documenting it in the contract, and teaching the client the benefits of the process before the work begins. As she puts it, when she checked back with the sales and engagement teams, she realized nobody had set those expectations. She relied instead of checking — and paid the price. Once she held sessions with the client to explain how Scrum works and what it delivers, things shifted. New tasks went into the product backlog and were prioritized properly through refinement, not dumped into active sprints. Self-reflection Question: When was the last time you verified that your client or stakeholders truly understand how your team works — not just the label, but the actual rules and commitments? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Iryna Stelmakh Iryna Stelmakh is a Project & Delivery Leader and Agile Coach who helps leaders turn complexity into clarity. With 10+ years across US, Nordic, and Eastern European environments, she works at the intersection of business transformation and human systems, building resilient organizations and high-performing teams in complex contexts. You can link with . /episode/index/show/scrummastertoolbox/id/40429570

BONUS Why 98% of Innovation Fails Before It Reaches a Single Customer With Lorraine Marchand 03/21/2026

BONUS Why 98% of Innovation Fails Before It Reaches a Single Customer With Lorraine Marchand BONUS: Why 98% of Innovation Fails Before It Reaches a Single Customer Lorraine Marchand has spent three decades helping organizations innovate in environments where failure carries real consequences. In this episode, she shares the frameworks, stories, and hard-won lessons from her time at IBM Watson Health and beyond — starting with the summer her father handed her a stopwatch and a problem to solve at a diner. The Sugar Cube That Started It All "At the age of 12, I learned that problem solving was fun. It was really safe to experiment, and it turned out to be lucrative, because we earned some revenue and royalties from our sugar cube." Lorraine's innovation journey began with her father — a serial inventor who challenged his kids to identify and solve real problems. One summer, he took Lorraine and her brother to the Hot Shops Cafeteria in the Baltimore-Washington area with stopwatches, graph paper, and 3-color pens. Their assignment: figure out what was slowing down table turnover. After three days of observation and interviews with waitresses, busboys, and the manager, they discovered that sugar packets were the culprit — granules spilling over the table and floor during cleanup. Their solution, the Sugar Cube, was prototyped, sold to the manager, and eventually adopted across the chain — which later became the Marriott Corporation. The lesson stuck: innovation starts with observing problems close to the core, not chasing abstract ideas in a vacuum. Inside IBM Watson Health: Customer Co-Creation Over Engineering Brilliance "We have fallen in love with our solution. And we have not done our true problem-solving dissection and customer research to make sure that we're solving a problem that a customer wants to pay us to solve." At IBM Watson Health, Lorraine worked with 250 world-class engineers building solutions for the biggest names in life sciences — Johnson & Johnson, Pfizer, Sanofi, Medtronic. The process started with "garage sessions" where the team would tackle problems directly with a reference customer. But a recurring tension emerged: engineering would want to take what they learned from one customer, disappear into a room, build the perfect solution, and then hand it to marketing to sell. Lorraine had to repeatedly pull them back. A reference customer is an N of 1 — solving their problem doesn't guarantee a marketplace need. The discipline was to keep the customer in lockstep at every stage and continuously open the aperture, bringing in more customers and more feedback to validate that the solution would work at scale. The Innovation Mindset: Four Components That Matter "Thinking outside of the box means that you step outside of your box and you step into someone else's box." Lorraine identifies four components of the innovation mindset: problem solving, insatiable curiosity, embracing change, and welcoming diversity. The diversity piece is where most teams fall short. Homogenous groups become echo chambers — smart engineers designing from a technology perspective rather than a customer use perspective. The most innovative organizations Lorraine has worked with embrace cross-functional, multidisciplinary teams where engineering, marketing, and customer experience all have a seat at the table. No idea is a bad idea at the brainstorming stage — the down-selection comes later through structured evaluation. The Golden Ratio: Why 10% Drives 70% of Future Growth "Five years later, 70% of your growth will come from that 10% that you invested in innovation. So there's an inverse correlation to where you're investing and where that growth is going to come in the future." Lorraine points to the framework popularized by Sergey Brin at Google: invest 70% in core business, 20% in adjacencies and new markets, and 10% in net new, transformative ideas that might not work out. The data across companies over the last 15 years consistently shows that the 10% bet on innovation generates the majority of future growth. Companies that invest 100% in core and a little in adjacency stay stuck in single-digit growth. Making innovation a strategic imperative — with dedicated budget and dedicated talent — is what separates companies that break out from those that stagnate. Experimentation Done Right: Problem Statement First, Prototype Fast "You have to have a really solid problem statement. It has to be clear, measurable, significant, and actionable." Good experimentation follows the scientific method. It starts with problem deconstruction — using first principles, the series of whys, or reframing to break down the problem until the statement is sharp enough to act on. From there, brainstorm solutions, down-select to the most promising one based on customer input, and build a minimal viable product. Lorraine emphasizes minimal — test the smallest feature possible, get it in front of customers quickly, capture the feedback, and loop it back into the next iteration. The continuous loop of learning is where real progress happens. The Watson Health Pivot: When the Customer Changes Everything "Even for me, it wasn't until we got this in the customer's hands and we were able to see how it was going to function in real life that we had the aha moment." At IBM Watson Health, Lorraine's team was developing an algorithm for a large medical device company working on pain intervention. The software used a patient's mobile phone to detect mobility issues — how quickly they got up from a chair, how easily they opened a jar — and determine when to deliver pain relief through the device. The engineering was elegant, the reference customer loved it. But when they put the solution in the hands of actual physicians and patients in their homes, they discovered they were off track in how the tool would function in real life. The pivot was dramatic: instead of the medical device company, they partnered with a pharmaceutical company that used the algorithm to guide patients on when to take pain-related medication. The entire end customer changed — because they did the work of testing with real users. Reframing Failure as Learning "If failure's in your operating system, you're not going to try these experiments, and you're not going to be willing to get it wrong." Lorraine's book examines the strategic failure that holds companies back from innovating. One of the five C's in her framework is chance — the willingness to take calculated risks. The key is reframing experiments from "did we get it right or wrong?" to "what can we learn?" When teams set learning objectives for each experiment — what can I learn about this tool, about the customer, about how this works in practice — they remove the fear that prevents action and replace it with a process that compounds knowledge over time. About Lorraine Marchand Lorraine Marchand helps senior leaders innovate in high-cost-of-failure environments. An award-winning author, keynote speaker, and innovation advisor, she brings 30+ years of experience, including work at IBM Watson Health. Her book, , offers practical frameworks for learning and growth without undue risk. You can link with and find more of her work at . /episode/index/show/scrummastertoolbox/id/40412595

BONUS Why Every Organization Reinvents Silos—And What to Do About It With Roland Flemm 03/20/2026

BONUS Why Every Organization Reinvents Silos—And What to Do About It With Roland Flemm BONUS: Why Every Organization Reinvents Silos—And What to Do About It Today we speak with Roland Flemm, co-creator of Org Topologies and co-author of Roland has spent decades in the trenches—first as a developer, then in infrastructure, and finally as a Scrum Master, trainer, and organizational design consultant. In this episode, he explains why even teenagers with zero corporate experience instinctively create departmental silos, why making every team faster doesn't make the whole organization faster, and how leaders can use the Org Topologies map to see their organization as it actually is—not as the org chart says it should be. From Developer to Org Designer: Four Decades of Hitting the Same Wall "I felt many, many times the limitations of organizational structures stopping me from using my common sense to make people work together in a proper way." Roland's career spans over 40 years, starting as a developer in 1984. After a decade writing code and another decade in infrastructure, he moved into Scrum and agile coaching. But even as a highly effective Scrum Master, he kept hitting the same ceiling: local team improvements couldn't break through organizational boundaries. You could have wins with your team, but the moment you needed multiple teams to work together, someone higher up would shut it down. That frustration led him to Large-Scale Scrum (LeSS) by Bas Vodde and Craig Larman, which offered a more educated approach to multi-team collaboration—and eventually to co-creating Org Topologies as a way to help leaders see and change the structures that block real collaboration. The Hydrogen Car That Built Its Own Silos "If you don't think about your org design—the way that you want to collaborate—then something like this happens." One of the most striking stories in Roland's book comes from the Technical University of Delft, where student engineers were thrown together to build a hydrogen racing car. These were teenagers—no corporate experience, no boss who'd worked in a traditional company. And within weeks, they'd organized themselves into departmental silos, each sticking to their specialty. The mechanical engineers stayed on their turf, the electrical engineers on theirs. It was automatic. Roland traces this instinct deep: from school, where you choose a specialty; from the army and the church, where hierarchy is the default; from society itself, where "you're a plumber, so then we know what you are." The pattern of drawing boundaries and appointing leads when faced with complexity isn't corporate culture—it's human nature. And the problem isn't that it exists. The problem is that we don't know there are alternatives. The Ferrari Effect: Why Local Speed Creates Global Congestion "It's not that people choose to do fewer things. They just push more into the system because it can handle it. And that's where things go wrong." Roland uses a vivid analogy from the book: swapping every car on the road for a Ferrari doesn't fix traffic congestion. The same principle applies in organizations. Everyone feels faster individually—teams are delivering, sprints are moving—but the whole isn't getting better. The HealthCare.gov story makes the case dramatically: 55 vendor firms, $1.7 billion in spending, and on launch day, six people successfully enrolled. Then a ten-person cross-functional team fixed it in six weeks. Roland sees this pattern repeat in banks that adopt delivery-oriented structures like SAFe: they create value streams, but because they don't make hard choices about what not to do, the freed-up coordination capacity immediately fills with new demands. The congestion returns, just at a different level. In this segment, we talk about . Three Topologies: Resource, Delivery, and Adaptive "The third topology is interesting—that's where the hands and the heads are merged. They're no longer separated." Roland walks through , each suited to different contexts: Resource Topology — The "hands" are separated from the "heads." Coordinators design and direct; specialists execute narrow, deep tasks. This works in environments with low variability and deep technical expertise—think ASML's university-level hardware engineers, or a bank's core transaction processing team running COBOL. The focus is on utilization of expensive specialists. Delivery Topology — Still has coordination overhead, but teams are cross-functional and can handle more complex problems end to end. A team owns the customer page and does design, testing, and deployment. This model favors speed of delivery, but breaks down when new work doesn't fit neatly onto existing value streams—like needing a retention initiative when no retention team exists. Work falls through the cracks. Adaptive Topology — The hands and heads merge. People who coordinate can also do the work, and they self-organize around problems as they emerge. It's like a startup—"four guys and a dog in a garage"—but with hundreds of people. This model thrives in high-variability, high-learning environments where the investment in cross-training pays off because the challenges keep changing. The key insight: none of these is "better." It's about fit for purpose. A single organization—like a large bank—might need all three topologies operating simultaneously in different parts of the business. The MADE Loop: Map, Assess, Design, Elevate "First, we all agree that the system that we're looking at is really the system that we're looking at. And then we can start talking about how to improve." Rather than the typical transformation playbook—hire consultants, roll out a framework, hope for the best—Roland advocates for : Map the reality of how work actually flows (not what the org chart says), Assess whether that structure is fit for the strategic purpose, Design targeted improvements using the Org Topologies map, and Elevate through small experiments. Maybe two teams temporarily share members. Maybe one person switches team membership for a sprint. The changes are gradual, measurable, and reversible. Roland is emphatic about one principle from the book: "Own, Not Rent." Real structural change can't be outsourced to a consulting firm. Leaders have to see the system themselves—go to where the work happens, understand the flow, and make informed choices about what to change. AI Is About to Reshape the Map "As AI comes, you might want to get at least a part of that work transferred lower in the organization to more execution-oriented teams, because they can now use resources like AI to make proper decisions." Roland makes a forward-looking point about how AI will shift the boundaries between topologies. Work that required deep specialist silos—like legal review or compliance decisions—may soon be handleable by cross-functional teams using AI tools. This means the threshold for when an adaptive or delivery topology makes sense will shift. Organizations that understand their current topology will be better positioned to adapt; those that don't will find their structures obsolete without understanding why. About Roland Flemm Roland Flemm is co-creator of Org Topologies and co-author of — a framework and book about elevating organizational performance through people-centered, strategy-driven redesign. He works with leaders in scale-ups and enterprises across Europe, helping them see how their org structure shapes — or blocks — their ability to learn, adapt, and deliver. You can link with . Learn more about Roland’s work at and /episode/index/show/scrummastertoolbox/id/40380315

BONUS Toyota's Real Secret Isn't the Tools — It's the Attitude Towards Learning That Changes Everything With Katie Anderson 03/19/2026

BONUS Toyota's Real Secret Isn't the Tools — It's the Attitude Towards Learning That Changes Everything With Katie Anderson BONUS: Katie Anderson, Toyota's Real Secret Isn't the Tools — It's the Attitude Towards Learning That Changes Everything Katie Anderson joins us to explore the real engine behind Toyota's legendary success — and it's not what most people think. Drawing from her years living in Japan and her close relationship with 40-year Toyota veteran Isao Yoshino, Katie reveals why tools alone will never create lasting transformation. We explore the Doer Trap, the Telling Habit, and why hansei (deep reflection) is the most productive practice leaders keep skipping. The Only Secret to Toyota "The only secret to Toyota is its attitude towards learning. We don't even notice, and we take it for granted." Katie moved to Japan over 11 years ago as a continuous improvement practitioner and got to know Isao Yoshino, a Toyota leader with 40 years of experience. After repeatedly asking him what made Toyota so successful, he finally offered an almost offhand answer: "The only secret to Toyota is its attitude towards learning." The deeper insight? Even inside Toyota, they barely noticed it — it was so embedded in how they worked that they took it for granted. Katie explains that most organizations copy the visible tools — the kanban boards, the value streams, the process maps — but miss the invisible layer underneath: people development. Without that foundation of learning, tools lead to project-based improvements that never sustain. The secret sauce is the quality of how organizations develop people to learn, contribute, problem-solve, and innovate. That system of people development underlies the system of process improvement, and without it, organizations stay stuck in what Katie calls "constant whack-a-mole" — fixing the same problems year after year. The Doer Trap and the Five Archetypes "The doer trap is when we're stepping in and doing things, or owning things that aren't ours to own." Katie identifies five archetypes of the Doer Trap that leaders and change agents fall into. The Hero is the firefighter who jumps from crisis to crisis — it feels good to save the day. The Rescuer can't stand watching people struggle, so they give answers too early, robbing others of the chance to develop their own thinking. The Magician works behind the scenes, subtly shaping outcomes without others' input. The Pair of Hands just jumps in and gets it done because "it's faster." And the Surrogate Leader fills a leadership vacuum that isn't theirs to fill — so when they move on, everything fades away. Each archetype feels productive in the moment but prevents the organization from building real capability. The shift Katie advocates is from command-based leadership to influence-based leadership: still setting direction, but creating the conditions for others to find the way there. Break the Telling Habit "The telling habit is when we're giving our answer instead of holding space for someone else to develop their answer." Closely linked to the Doer Trap, the Telling Habit is about how leaders — and change agents — default to providing their own ideas, suggestions, and solutions instead of creating space for others to think. Katie sees this show up even in well-intentioned coaches and consultants. The antidote aligns with what David Marquet calls intent-based leadership: instead of telling people what to do, you validate their thinking and ask questions when you spot gaps. Katie frames good leadership through three responsibilities drawn from Mr. Yoshino's example: set the direction (what goal needs to be achieved), provide support (create the capability and conditions for people to succeed), and develop yourself (because if you can't see the system, you can't help others see it either). Learning as Sustainable Competitive Advantage "We need to set up experiments. And experiments are fundamentally based on an attitude towards learning." Katie argues that as complexity increases, no single leader can hold all the answers. Organizations need to harness what you might call the collective brain — the hive mind of the team — and that requires an experimental mindset. This connects directly to Jeffrey Liker's concept of organizations as : it's never just the technical processes that matter, but how people interact, influence each other, and navigate the formal and informal structures that actually get things done. Katie's advice to change leaders: develop your own systems thinking skills first. Help leaders see what's really driving behavior — reward structures, people development gaps, the difference between compliance and genuine capability. Everything starts with you. Hansei — Reflection as the Most Productive Practice "The study and adjust part of the cycle is where the learning happens. But we keep cutting it because the doing part feels more productive." Hansei — Japanese for deep self-reflection — goes far beyond the typical retrospective. Where most teams do a surface-level "what worked, what didn't, let's move on," hansei asks: what did we expect to happen? What were our assumptions? What behaviors drove the outcome? Katie points out that Toyota schedules reflection time deliberately — both large-scale and small-scale — and sticks to it. That discipline is part of their attitude towards learning. She advocates reframing the as Study-Adjust-Plan-Do, because the reflection should come first, not as an afterthought. At Toyota, PDCA operates at every level: micro-kaizen on the factory floor daily, A3 reports for structured problem-solving, and Hoshin Kanri for annual and five-year strategy deployment. The mindset of experimentation, paired with disciplined reflection, is what makes continuous improvement actually continuous. About Katie Anderson Katie Anderson is an internationally recognized keynote speaker, award-winning author, and leadership consultant who helps organizations achieve extraordinary results through continuous learning. She partners with executives and change leaders to build learning cultures, strengthen leadership capability, and drive sustainable success by aligning purpose, developing people, and fostering curiosity, courage, and meaningful transformation. You can link with and visit her website at . Listen to her podcast, . /episode/index/show/scrummastertoolbox/id/40380215

BONUS How to Build Teams That Think, Own, and Execute Without Burnout With Sid Jashnani 03/18/2026

BONUS How to Build Teams That Think, Own, and Execute Without Burnout With Sid Jashnani BONUS: How to Build Teams That Think, Own, and Execute Without Burnout What if the problem isn't your people—but how your leadership shows up? In this episode, Sid Jashnani unpacks how Agile thinking, , and his can help leaders build teams that truly own outcomes, execute without micromanagement, and grow the business—without burning out leaders or teams. The Breaking Point: When Smart People Don't Own Outcomes "I realized that I was the system, I was the bottleneck. And I was the one orchestrating everything. And if I were to step away for just going for dinner with my family, I would still get a call from someone." Around 2014, Sid was running a thriving systems integration company with great people—people he trusted and loved working with. But they weren't owning outcomes. They were busy, but not always productive. Every decision fell back on Sid, and when the calls kept coming during family dinners, he started responding with irritation and sarcasm—a leadership pattern he knew was unsustainable. That moment of self-awareness became the catalyst for change. Sid realized the problem wasn't his team's competence; it was his inability to get them aligned, accountable, and clear on expectations. That's when he discovered EOS—a business operating system created by Gino Wickman that orchestrates how you set priorities, run meetings, connect with your team, and track your numbers. Over the next few years, implementing EOS across his organization brought the clarity, accountability, and discipline his business needed. Where Agile and EOS Overlap: Trust Through Structure "The real overlap is trust through structure. If there's no structure, then I'm not accountable to you. I can do whatever." Sid sees deep parallels between Agile and EOS. Both are allergic to hero culture. Both push decisions as close to the work as possible. Both rely on cadence—sprints, weekly meetings, daily stand-ups—to create rhythm without micromanagement. And both use visibility, numbers, and scorecards to keep teams aligned. But the real overlap, as Sid frames it, is trust through structure. In EOS, teams are structured through an accountability chart: who owns what outcome, who reports to whom, and how success is defined for each role. Without that structure, accountability becomes optional, and without accountability, trust never forms. Sid connects this directly to Patrick Lencioni's —where trust sits at the base of the pyramid, enabling , commitment, accountability, and ultimately results. The key anti-pattern Sid warns about: people picking only the comfortable parts of a system and relaxing the parameters so much that it becomes "SOS—Sid's Operating System—which is just an emergency call for help." In this episode, we also refer to , a foundational book for Sid in his career. The DELTA Delegation Ladder: From Command-and-Control to Co-Founder Mode "Delegation fails because leaders skip levels." Sid introduces his DELTA Delegation Ladder—a five-level framework for understanding where your team members sit and how to delegate accordingly: D — Do as I say: Pure execution of instructions. Sid notes this level is increasingly being replaced by AI. E — Explore the possible solutions: Research and present options, but the leader still makes the decision. Also increasingly delegable to AI. L — Lead with a recommendation: The entry point for real human value. The person researches, forms a hypothesis, and recommends a path forward. Sid considers this the minimum hiring bar. T — Take action with oversight: The person takes decisions and acts, keeping the leader in the loop. Trust has been built through coaching and mentoring. A — Autonomous execution: Co-founder mode. The person owns the outcome end-to-end. Full trust, full ownership. Delegation fails when leaders skip levels—expecting someone at "D" to operate at "A." It also fails when leaders abdicate rather than delegate, throwing someone into a role without investing time in coaching, clarifying expectations, or showing them what "great" looks like. As Sid puts it: delegation only works if you spend time with the person you're delegating to. Remote Teams: Written Clarity Beats Verbal Alignment "Trust comes from predictability, not proximity. I can be 1,000 miles across the world from you and trust you, because I can predict what your actions are gonna be." For distributed and cross-timezone teams, Sid's non-negotiables are clear: get good at writing, and over-communicate. Written clarity beats verbal alignment every time, especially across cultures where tone and directness vary widely—from British politeness to Dutch directness. Over-communication isn't a flaw; it's the standard for remote teams. Without it, accountability vanishes and culture erodes. Sid points out that trust in remote settings comes from predictability—can you predict that someone will hit their milestones, complete their to-dos, and follow through?—not from physical proximity. Someone sitting next to you who consistently misses deadlines will never earn your trust, while someone across the world who reliably delivers will. Self-reflection Question: Where on the DELTA Delegation Ladder are the people you're currently delegating to—and are you investing the time and coaching they need to move up, or are you skipping levels and hoping for miracles? About Sid Jashnani Sid is a founder, operator, and growth advisor who scaled a systems integration firm into a portfolio of IT businesses. After struggling with delegation and predictability, EOS transformed how he led. Through Outgrow, Sid helps founders drive 15–30% predictable growth with disciplined execution and proactive customer communication. You can link with . You can also read his weekly newsletter, . /episode/index/show/scrummastertoolbox/id/40309845

BONUS Guardrails Over Processes—How to Scale Teams Without Killing Creativity With Prashanth Tondapu 03/17/2026

BONUS Guardrails Over Processes—How to Scale Teams Without Killing Creativity With Prashanth Tondapu BONUS: Guardrails Over Processes—How to Scale Teams Without Killing Creativity What actually slows down tech teams—lack of talent, or lack of ownership? In this episode, Prashanth Tondapu shares lessons from leading through global-scale failures, scaling from a small team to a 100-person company, and discovering why guardrails beat rigid processes when it comes to building teams that own outcomes and execute with discipline. Diffusion of Accountability: When Everyone Is Responsible, Nobody Is "Crisis is not the problem. Crisis is the one that uncovers the problem that has always existed." Early in his career, Prashanth witnessed a large-scale failure at a major technology company—not because the team lacked talent, but because accountability had become diffused. When too many people are responsible for something, it translates to nobody being responsible. The team was brilliant individually, but there was no clear demarcation of who owned what outcome. On good days, everything worked. But when things went wrong, there was no single person who could no longer delegate accountability to someone else. In this segment, we also refer to the concept from . Prashant argues for: outcome can only come with 100% emotional commitment to a particular problem, and when five people share that commitment, each carries only 20%. That's where breakdowns happen. The Leadership Design Problem: From Computers to People "I was a developer who imagined that humans are also going to be as predictable as computers. Until 6 or 7 people, it works well because you can be everywhere. But as soon as we increased above 7, I was not able to be everywhere." Prashanth's journey as a founder mirrors what many tech leaders experience at scale. Starting Innostax at 27 as a developer with no management experience, he initially treated people like predictable systems. Below seven people, it worked—he could be the hero founder, the catch-all. But beyond that threshold, he had to learn delegation, which meant learning to trust. First came the people-dependent phase, then the process-oriented phase with for everything—even how APIs should look. The SOPs made the team fast at execution, but their clients noticed something troubling: "Your guys do not even ask any questions." The rigid processes had suppressed the very creativity and critical thinking they needed. That feedback became the catalyst for the next evolution: becoming a people-first company. Guardrails vs. Processes: Freeing Creativity Within Structure "If something goes wrong, our guardrail is: we will just ask you one question—what was your intent behind doing this?" Prashanth draws a sharp distinction between processes and guardrails. Processes tell you exactly what to do and how to do it—they create predictable execution but kill creativity. Guardrails define the boundaries within which people have freedom to be creative and solve problems their own way. At Innostax, guardrails take practical forms: Time-on-task guardrails: If a task takes longer than expected, ask for help—don't rabbit-hole into it for three days Don't be a hero: When friction appears with a client or a problem, escalate early rather than trying to solve everything alone The intent review: When something goes wrong, instead of punishment, they ask three questions—was the intent right, was the approach right, and what was the outcome? If intent and approach were right but it still failed, that's the company's problem, not the individual's This framework creates psychological safety while maintaining accountability. People know they won't be penalized for honest mistakes made with good intent, which means they surface problems early rather than hiding them. Vision Elements and the People-First Company "The outcome is not just what is expected, but outcome also consists of what is not expected. People come out in so many creative, great ways that they end up surprising you." The shift to a people-first company meant replacing rigid SOPs with what Prashanth calls "vision elements"—broader directional guidance like "we are working for the client, we need to give the best for the client in the resources that we have." This gives teams a larger sandbox to work in while guardrails prevent them from going too far off course. The daily rhythm includes team leads reviewing work summaries—not to micromanage, but to catch misalignment early and offer support. Prashanth emphasizes that guardrails must be created with emotional intelligence and detachment. If you create guardrails assuming you're also part of the problem, they'll be biased and ineffective. That's why he considers emotional intelligence the prerequisite skill for any leader designing team structures. The Books That Changed Everything "Whenever I was reading through the fixed mindset guy, it was like it was describing me. And that actually changed everything." Prashanth recommends two foundational books for leaders building ownership-driven teams. First, —a book that cracked his own fixed mindset as a confident developer who thought he knew everything. Reading about the fixed mindset felt like reading his own biography, and that uncomfortable recognition opened him to listening more, seeking exposure to experts, and believing there were perspectives he hadn't encountered yet. Second, —because without mastering emotional intelligence, everything you hear feels personal, clouding your judgment and making you too close to the problem to design effective solutions for your team. Self-reflection Question: Are you building guardrails that give your team freedom to be creative within clear boundaries, or are you still writing processes that tell people exactly what to do—and in the process, suppressing the very thinking you hired them for? About Prashanth Tondapu Prashanth Tondapu is Founder and CEO of Innostax and a veteran technology leader. He's led teams through high-stakes global incidents at McAfee and scaled disciplined delivery organizations worldwide. His work focuses on ownership, accountability, and designing teams for predictable, sustainable execution as complexity grows. You can link with . /episode/index/show/scrummastertoolbox/id/40299855

BONUS Why the Spotify Model Didn't Work (Even at Spotify) With Marcus Hammarberg and Tore Fjaertoft 03/16/2026

BONUS Why the Spotify Model Didn't Work (Even at Spotify) With Marcus Hammarberg and Tore Fjaertoft BONUS: Why the Spotify Model Didn't Work (Even at Spotify) Imagine a company that spends a year building an iPad app—and on launch day the product owner says: "Now it'll be interesting to see IF anyone uses it." In this episode, Marcus Hammarberg and Tore Fjaertoft share why organizations keep installing frameworks like software, why it still doesn't work, and what they've learned from places like Spotify about treating your way of working as a product in itself. When Copying Without Adopting Becomes the Norm "It becomes more about following whatever this framework tells you to do, rather than to understand what the problem you're trying to solve is all about." Marcus and Tore met at a consultancy in Malmö and within 15 minutes realized they shared the same frustrations—despite coming from opposite directions. Marcus comes from the ground up as a software developer and coach, while Tore works top-down with leadership teams on product organization design. Both had worked at Spotify and both had seen organizations copy famous frameworks and models without adopting the underlying mindset. The telltale sign, as Tore describes it, is when people focus on compliance rather than being pragmatic—following the manual without questioning whether the way they're working is actually serving the organization. As Marcus frames it through , product development lives in a domain where best practices don't even exist—only that you discover by trying things out. Treat Your Process Like a Product "The easiest way for us to explain things has been: take the mindset you use for your product, and then use that same mindset when you're approaching how you set things up and how you work internally." The core idea Marcus and Tore keep returning to is deceptively simple: see the way you operate as a product in and of itself. Just as a digital product is never finished—you ship it, observe how customers use it, and evolve accordingly—your operating model should follow the same cycle. Tore explains that the "customers" of your process are your employees: they need less friction, more empowerment, and the ability to spend more time on work that actually moves the needle for users. Marcus connects this to the lean concept of —a shared direction that everyone understands, so that every experiment and process change moves the organization closer to what matters. He contrasts this with the three Agile transformations he participated in that all had the same misguided tagline: "get more out of our development organization." As Marcus points out, even the shows developers feeling more productive individually—but is individual productivity really the goal? The Factory Floor Story: Empowerment Needs Alignment "Everyone down here knows that anything we do needs to be the best in the world, in every step." Marcus shares a powerful story from a Swedish lorry factory where workers changed their workstation instructions several times a day—written on a whiteboard with a pen, not locked in a manual. When asked how they got everyone to engage in continuous improvement, the factory managers didn't understand the question. Every worker on the floor knew they were building the most expensive lorry in the world, and they wanted it to stay the best. That shared purpose drove improvement without mandates. But Marcus is quick to add the counterbalance: empowerment without alignment leads to local optimization. The factory combined local metrics with overarching flow metrics, so everyone could see how their station fit into the whole chain. Marcus and Tore distill this into three interconnected principles: empowerment to enable people to change how they work, alignment to steer toward shared outcomes, and collaboration to prevent teams from optimizing in isolation. From Static Frameworks to Dynamic Ways of Working "We realized that Spotify didn't use the Spotify model. They moved on, because they see the way they work as a continuously evolving approach." Tore reveals one of the most striking lessons from their Spotify experience: the company that accidentally created "the Spotify model" had already moved beyond it by the time the rest of the world started copying it. The reason? Spotify treated its way of working as something that continuously evolves—not a static blueprint to install and follow. Marcus adds a practical example from Spotify: on your first day, you got access to the company's key metrics. Everyone knew the —at the time, increasing monthly active users—and every process change, every experiment, every team decision was oriented toward that outcome. The contrast with organizations that "install" a framework and then wonder why it doesn't work couldn't be sharper. As Marcus puts it: "We tried process X, it didn't work. We tried process Y, the opposite, and that didn't work either. Why doesn't the process work?" The answer is that the "how" must emerge over time, guided by a clear "why." Always Know Why You're Doing What You're Doing "I don't want anyone to work on anything if you don't know why." Tore shares a policy from a product management colleague at Spotify: every single day, everyone on his team should be able to articulate not just what they're working on, but why—and the "why" could not be "because person XYZ told me to." It had to connect to the company's purpose and users. Marcus takes this even further, recounting how he once stopped productivity at an entire company by telling developers: don't work on anything unless you know why. Nobody could continue. The uncomfortable silence that followed became a powerful catalyst for change. With an 80% failure rate for product experiments being the industry standard, packaging that risk into year-long projects is a recipe for the iPad app scenario they opened with. The alternative is to build the organizational muscle for rapid experimentation—cheap hypotheses, fast feedback, and the humility to let outcomes guide the way forward. Self-reflection Question: When was the last time you asked your team—or yourself—"why are we doing this?" and got an answer that connected to a real business or user outcome rather than "because the framework says so"? About Marcus Hammarberg and Tore Fjaertoft Marcus Hammarberg is a product and software coach and consultant who has seen product organizations from the inside and from the trenches. He works at Humane, part of the ADRA consulting collective, and has experience from Spotify, Tradera, and multiple Agile transformations across banks and insurance companies. Tore Fjaertoft is a product organization advisor who works with leadership teams on how product thinking actually scales in large, complex companies. He works at Above, also part of the ADRA consulting collective, and has experience from Spotify and Volvo Cars. You can link with and /episode/index/show/scrummastertoolbox/id/40299770

BONUS The Human Architect Still Matters—AI-Assisted Coding for Production-Grade Software With Ran Aroussi 03/14/2026

BONUS The Human Architect Still Matters—AI-Assisted Coding for Production-Grade Software With Ran Aroussi BONUS: Why the Human Architect Still Matters—AI-Assisted Coding for Production-Grade Software How do you build mission-critical software with AI without losing control of the architecture? In this episode, Ran Aroussi returns to share his hands-on approach to AI-assisted coding, revealing why he never lets the AI be the architect, how he uses a mental model file to preserve institutional knowledge across sessions, and why the IDE as we know it may be on its way out. Vibe Coding vs AI-Assisted Coding: The Difference Shows Up When Things Break "The main difference really shows up later in the life cycle of the software. If something breaks, the vibe coder usually won't know where the problem comes from. And the AI-assisted coder will." Ran sees vibe coding as something primarily for people who aren't experienced programmers, going to a platform like Lovable and asking for a website without understanding the underlying components. AI-assisted coding, on the other hand, exists on a spectrum, but at every level, you understand what's going on in the code. You are the architect, you were there for the planning, you decided on the components and the data flow. The critical distinction isn't how the code gets written—it's whether you can diagnose and fix problems when they inevitably arise in production. The Human Must Own the Architecture "I'm heavily involved in the... not just involved, I'm the ultimate authority on everything regarding architecture and what I want the software to do. I spend a lot of time planning, breaking down into logical milestones." Ran's workflow starts long before any code is written. He creates detailed at multiple levels of granularity—first a high-level PRD to clarify his vision, then a more detailed version. From there, he breaks work into phases, ensuring building blocks are in place before expanding to features. Each phase gets its own smaller PRD and implementation plan, which the AI agent follows. For mission-critical code, Ran sits beside the AI and monitors it like a hawk. For lower-risk work like UI tweaks, he gives the agent more autonomy. The key insight: the human remains the lead architect and technical lead, with the AI acting as the implementer. The Alignment Check and Multi-Model Code Review "I'm asking it, what is the confidence level you have that we are 100% aligned with the goals and the implementation plan. Usually, it will respond with an apologetic, oh, we're only 58%." Once the AI has followed the implementation plan, Ran uses a clever technique: he asks the model to self-assess its alignment with the original goals. When it inevitably reports less than 100%, he asks it to keep iterating until alignment is achieved. After that, he switches to a different model for a fresh code review. His preferred workflow uses for iterative development—because it keeps you in the loop of what it's doing—and then switches to for a scrutinous code review. The feedback from Codex gets fed back to Opus for corrections. Finally, there's a code optimization phase to minimize redundancy and resource usage. The Mental Model File: Preserving Knowledge Across Sessions "I'm asking the AI to keep a file that's literally called mentalmodel.md that has everything related to the software—why decisions were made, if there's a non-obvious solution, why this solution was chosen." One of Ran's most practical innovations is the mentalmodel.md file. Instead of the AI blindly scanning the entire codebase when debugging or adding features, it can consult this file to understand the software's architecture, design decisions, and a knowledge graph of how components relate. The file is maintained automatically using hooks—every pre-commit, the agent updates the mental model with new learnings. This means the next AI session starts with institutional knowledge rather than from scratch. Ran also forces the use of inline comments and doc strings that reference the implementation plan, so both human reviewers and future AI agents can verify not just what the code does, but what it was supposed to do. Anti-Patterns: Less Is More with MCPs and Plan Mode "Context is the most precious resource that we have as AI users." Ran takes a minimalist approach that might surprise many developers: Only one MCP: He uses only , instructing the AI to use CLI tools for everything else (Stripe, GitHub, etc.) to preserve context window space No plan mode: He finds built-in plan mode limiting, designed more for vibe coding. Instead, he starts conversations with "I want to discuss this idea—do not start coding until we have everything planned out" Never outsource architecture: For production-grade, mission-critical software, he maintains the full mental model himself, refusing to let the AI make architectural decisions The Death of the IDE and What Comes Next "I think that we're probably going to see the death of the IDE." Ran predicts the traditional IDE is becoming obsolete. He still uses one, but purely as a file viewer—and for that, you don't need a full-fledged IDE. He points to tools like and as examples of what the future looks like: chat panes, work trees, file viewers, terminals, and integrated browsers replacing the traditional code editor. He also highlights as his favorite AI coding agent, noting its superior context management compared to other tools. Looking further ahead, Ran believes larger context windows (potentially 5 million tokens) will solve many current challenges, making much of the context management workaround unnecessary. About Ran Aroussi Ran Aroussi is the founder of MUXI, an open framework for production-ready AI agents, co-creator of yfinance, and author of the book . Ran has lived at the intersection of open source, finance, and AI systems that actually have to work under pressure—not demos, not prototypes, but real production environments. You can connect with , and link with . /episode/index/show/scrummastertoolbox/id/40298660

Product Owner Anti-Patterns, From Team Owner to Product Owner, And The PO Who Got It Right 03/13/2026

Product Owner Anti-Patterns, From Team Owner to Product Owner, And The PO Who Got It Right Junaid Shaikh: Product Owner Anti-Patterns, From Team Owner to Product Owner, And The PO Who Got It Right Junaid opens with a line that cuts straight to the most common PO anti-pattern: "You are the product owner, not the team owner." When he sees a PO slipping into command-and-control mode, he asks them one question: "What is your role?" They say "Product Owner." He says: "Exactly. You own the product, not the team. If you were meant to own the team, we'd call you a project manager." The worst case he witnessed: a PO who was so possessive of "his" team that he required approval on everything — processes, tools, even holiday requests. In sprint planning, he would assign stories to individual team members ("Mr. X, you take this one"). He'd estimate the work himself, and when developers pushed back, he'd override them: "I was a developer, I know how long this takes." For approaching PO anti-patterns, Junaid has a deliberate style: he doesn't confront upfront. He observes, takes notes, and starts by solving a smaller impediment to demonstrate he's there to help. Once trust is built, he brings in coaching tools — first teaching the basics ("this is what the PO role is in Scrum"), then gradually coaching on specific anti-patterns observed in practice. He targets 10-15% improvement at a time. Six months later, you've already achieved 30-40% improvement. The best PO Junaid has worked with had four qualities: clear, concise communication; an open mindset willing to be coached; courage to say "no" when needed; and the discipline to define the "what" and leave the "how" to the team. This PO started with five sources of truth — Excel tabs, whiteboards, JIRA, and other tools. When Junaid pointed out that five sources of truth is the opposite of transparency (one of Scrum's three pillars), the PO asked for help. Junaid's response: "I can't do the push-ups for you." Together, they consolidated everything into one tool. The team was happier, and the PO managed the backlog much better. The key lesson: great product owners trust their team, communicate clearly, prioritize ruthlessly, and have the courage to say no. And they don't try to own the team. You can link with Junaid Shaikh on . [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on . /episode/index/show/scrummastertoolbox/id/40349865

How Scrum Masters Can Measure Their Own Impact, Practical Self-Assessment Metrics 03/12/2026

How Scrum Masters Can Measure Their Own Impact, Practical Self-Assessment Metrics Junaid Shaikh: How Scrum Masters Can Measure Their Own Impact, Practical Self-Assessment Metrics Junaid's favorite retrospective format? The vanilla: what went well, what could have gone better, what to do better next. He's tried many formats — the Three L's (liked, learned, lacked), the Three Little Pigs, the sailboat — but the core principle is always the same. His practical advice: stick with a consistent format so the team gets better at the process itself rather than constantly adjusting to new concepts. One addition he insists on for any format: an appreciation component. In the rush to analyze processes and outcomes, teams often skip acknowledging how another team member, PO, or Scrum Master helped during the sprint. That appreciation builds trust, respect, and openness that feeds into subsequent sprints. On defining success as a Scrum Master, Junaid starts with a Peter Drucker quote: "You cannot improve something you cannot measure." He proposes several practical self-assessment metrics: First, the — a spider graph that shows where the team stands across multiple criteria, making gaps visible and actionable. Second, track retrospective action items. Create tiger teams for specific issues, run small iterative experiments, and measure in the next retrospective whether the trend is improving. Third, watch for shared sprint goals. Junaid once saw a team with nine sprint goals for a two-week sprint — those weren't goals, they were individual tasks. A real sprint goal should be something multiple team members work together to achieve. Fourth, self-organizing teams. If the team falls apart when the Scrum Master is absent for a sprint, there's a problem. Coach teams to self-organize, and their ability to function independently becomes a success metric. Fifth, communication patterns. Too many emails flying around can signal hidden conflicts or trust barriers. If communication happens through the right channels — dailies, direct interactions — you're likely in good shape. Sixth, Scrum event health. If events get canceled too frequently, the team may be reverting to traditional ways of working. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on . /episode/index/show/scrummastertoolbox/id/40349870

Managing Uncertainty As A Scrum Master, How Scrum's Rhythm Creates Stability In Unstable Times 03/11/2026

Managing Uncertainty As A Scrum Master, How Scrum's Rhythm Creates Stability In Unstable Times Junaid Shaikh: Managing Uncertainty As A Scrum Master, How Scrum's Rhythm Creates Stability In Unstable Times For this week's coaching conversation, Junaid brings a challenge that resonates well beyond any single team: dealing with uncertainty. He references the World Uncertainty Index report from February 2026, which showed the highest levels of global uncertainty ever recorded — surpassing both the COVID pandemic and the 2008 financial crisis. This uncertainty doesn't stay at the geopolitical level. It seeps into teams. People show up stressed, unsure about what the next month or three months will bring. As Scrum Masters, we need to be cognizant of where our team members are coming from. Vasco adds an important layer: uncertainty operates at multiple levels within organizations. A colleague you depend on might be out sick for two weeks. A supplier might not deliver on time. Every dependency is a source of uncertainty. The question becomes: what in our processes is designed to accept and adapt to that uncertainty? Junaid's answer is powerful in its simplicity: Scrum's rhythm. The sprint, the planning, the daily, the retrospective — these events at a defined cadence create internal predictability. "When you have a rhythm, when you have a known sequence of events in front of you, that takes away a lot of uncertainty." Vasco builds on this: Scrum creates a boundary — the sprint — that accepts uncertainty outside while reducing it inside. Internal versus external predictability. Inside the sprint, the team can fail in small ways without exposing every failure to the outside. Compare that with traditional project planning, where every task on the critical path has external visibility and impact. For practical tools, Junaid shares how he used the with a team to convert uncertainty into actionable priorities. They listed all activities from recent sprints, plotted them on the matrix, and found they could delegate or deprioritize 20-25% of their work. That freed them to focus with certainty on the remaining 75%. Combined with timeboxing as an uncertainty management mechanism, teams can create pockets of predictability even in turbulent times. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on . /episode/index/show/scrummastertoolbox/id/40349885

Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It 03/10/2026

Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It Junaid Shaikh: Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It Junaid's book recommendation is . As a Scrum Master working at companies like Ericsson and ABB — organizations that are a "United Nations" of cultures — understanding cultural tendencies has been essential. But Junaid goes further: you can customize the Culture Map framework even within a team of people from the same country, using the parameters to map different personalities. It's about how you use the tool, not just where people come from. He also recommends for practical advice on the servant leadership role, and regularly visits and for real-world insights from the community. On the topic of teams that self-destruct, Junaid paints a picture that many listeners will recognize. He picked up a team's retrospective history and cumulative flow diagrams and found problems at every level: managers who declared "from tomorrow we're going agile" without understanding what that meant, then started comparing velocity across teams. Product owners who took PO training but reverted to command-and-control project management. A previous Scrum Master doing what Junaid calls "zombie Scrum" — implementing the framework mechanically without understanding its purpose. The pattern underneath it all: people enveloping their traditional mindset under an agile umbrella. The ceremonies happen, the daily standups run, but nobody is questioning why they're doing any of it. As Vasco observes, this zombie pattern isn't limited to Scrum — it happens with code reviews, architecture reviews, any process that gets adopted without critical thinking about its purpose. Junaid's insight: if you don't understand the basics with the right mindset, every event feels like overhead. Teams complain about "too many meetings" because they're running agile ceremonies on top of their old informal processes. "If you don't get out of your previous shell, you cannot get into a new shell." [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on . /episode/index/show/scrummastertoolbox/id/40350500

The Eager Scrum Master Trap, Why Proposing Solutions Too Early Can Backfire 03/09/2026

The Eager Scrum Master Trap, Why Proposing Solutions Too Early Can Backfire Junaid Shaikh: The Eager Scrum Master Trap, Why Proposing Solutions Too Early Can Backfire In this episode, Junaid shares a story from his early days as a Scrum Master when enthusiasm got ahead of experience. Fresh from a CSM certification and full of ideas, he walked into teams and started proposing solutions — "No, this is not how you should do it." It felt obvious. It wasn't. The wake-up call came when he proposed working agreements to a team that had been collaborating well for two years. The pushback was immediate: "Why do we need this?" He realized he was bringing a tool he'd seen elsewhere without first understanding whether the team actually had the problem that tool was meant to solve. This led to a key shift in his approach: stop assuming. Instead of going in with answers, Junaid started creating small tiger teams with the affected people, facilitating sessions where they owned the solution. The result? Much higher acceptance and genuine continuous improvement. These days, Junaid tests his ideas before bringing them to the full team. He connects with individual team members first — his "closer allies" — to validate whether his analysis matches reality. Only when a few people confirm "yes, this is a real problem" does he bring the proposal to the group. As Vasco puts it: not all tools are appropriate at all times for all people. The same working agreements that were wrong for one team at one moment might be exactly right for a different team, or the same team at a different moment. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Junaid Shaikh Junaid Shaikh is an energetic Agile Coach with a natural flair for Agile and Scrum, shaped by recent experiences at software giants like Ericsson and hardware leaders ABB. In his work, he champions collaboration, curiosity, and continuous improvement. Beyond coaching, he brings the same passion to cricket, table tennis, carrom, and his newest sporting obsession — padel. You can link with Junaid Shaikh on . /episode/index/show/scrummastertoolbox/id/40350520

BONUS: Leadership Is Contextual With Daniel Harcek 03/08/2026

BONUS: Leadership Is Contextual With Daniel Harcek In this CTO Series episode, Daniel Harcek shares how leading engineering teams across radically different scales — from a 7-person fintech startup to a 2,000-person cybersecurity company — taught him that leadership isn't one-size-fits-all. We explore how he builds AI-first organizations, drives agile transformations, and why he believes every person in a company should think like a tech person. What Works at 10 People Breaks at 100 "Leadership is contextual, not absolute. What works with 10 people breaks at 50, at 100." Daniel's career spans from building a 30-person team for a German startup out of Žilina, Slovakia, to leading 70 engineers at Avast's mobile division within a 2,000-person organization, and now running a 7-person team at . Each scale demanded a fundamentally different approach. At smaller scales, you strip away operational overhead and push ownership directly to the people. At larger scales, you need guardrails, dedicated roles, and structured processes that the smaller team would find suffocating. The lesson: don't carry your playbook from one context to another — rebuild it for the reality you're in. End-to-End Ownership Replaces Specialized Roles "Each engineer owns quality for the task he delivers. And he owns the fact that it comes to production." At , Daniel runs without dedicated QA people — in a fintech company where quality can't be compromised. Instead, each developer owns quality end-to-end, from code to production. This isn't recklessness; it's intentional design. When teams are small, you set up the system so that it's safe to break things, then trust people with hard tasks. The result: people grow faster, move faster, and care more about what they ship. In larger organizations, you might need specialized DevOps, QA, and platform roles — but the principle of ownership stays the same. The Buddy System and Scaling Without Losing Alignment "The buddy system is one of the easiest things you can do. One buddy for a newcomer for the first 1, 3, 6 months — they often become friends." When scaling fast, Daniel focuses on three things: strong on-boarding guides, well-maintained documentation (now much easier with AI), and a buddy system that pairs every newcomer with a dedicated colleague. The buddy system works because it scales the human side of on-boarding — a tech lead or manager can do one-on-ones, but that's formal, and new people might be scared to speak up. The buddy creates a safe channel for questions, concerns, and cultural integration. Beyond people, scaling also means investing in automation and observability so that as you grow with customers, you grow with failures too — and your incident reporting doesn't burn out the team. Building an AI-First Organization "Every person uses AI. Every person has the capability to use AI. The company builds a second brain so AI can build on top of that." At , Daniel has implemented what he calls an AI-first organization, inspired by Spotify and other companies pioneering this approach. The concept is simple: before doing any task, ask whether AI can help you deliver the output faster or better. This applies across the entire company — not just engineering. Daniel looks for people in HR, accounting, and UX who understand automation tools like n8n or Make.com alongside AI. The key ingredients: Curate the data: Build a company "second brain" with clean, structured context for AI tools to work with Train the muscle: AI ability is like a muscle — people must use it daily because these skills didn't exist 2-3 years ago Share what works: Exponential AI adoption happened at WageNow once people started sharing their successes and failures with AI tools Respect the guardrails: Data privacy and regulation compliance remain non-negotiable The hidden productivity gains, Daniel argues, lie not in engineering (which gets all the attention) but in operations, accounting, HR, and every other area of the business. Selling Transformation: Financial Arguments for Leaders, Ownership for Teams "For the leaders, it's the financial thing and the cultural thing. For the people doing the work, it's personal development — having more control, having more ownership." At Ringier Axel Springer, Daniel proposed and led a company-wide agile transformation — a 1-2 year effort that required convincing the CEO, product teams, marketing, and sales to change how they operate. His approach: build a dual argument. For leadership, frame the change in financial and cultural terms — more revenue with the same people, better visibility into how work translates to business outcomes. For the people doing the work, emphasize personal growth, increased ownership, and transparency. The transformation breaks silos between engineering and product, creating a shared backlog agreed with all stakeholders. Daniel looks for people with high agency — those who can reinvent and change themselves from the inside, not just wait for a change agent from the outside. Balancing Experimentation with Operational Excellence "The SRE books helped me understand quality as a feature — because quality is basically how reliable you are for your customers." When asked about the books that most influenced his approach as a CTO, Daniel points to the — three books that frame quality as reliability, a feature your customers experience directly. Alongside those, he recommends because he believes all tech people should have a sense of business and customer understanding. Together, these books guide how to balance rapid experimentation with operational excellence as the organization scales. About Daniel Harcek Daniel is a technology executive with a proven record scaling engineering organizations across fintech, cybersecurity, and digital media. Builds AI-first teams, operating models, and delivery cultures aligned with product strategy. Led platforms serving 30M MAU, deployed fintech capital pilots, transformed agile delivery at internet scale, and mentors global tech communities and ecosystems worldwide actively. You can link with . /episode/index/show/scrummastertoolbox/id/40355570

Accountability Requires Ability—Why Powerless Product Owners Are Sacrificial Lambs | Nigel Baker 03/06/2026

Accountability Requires Ability—Why Powerless Product Owners Are Sacrificial Lambs | Nigel Baker Nigel Baker: Accountability Requires Ability—Why Powerless Product Owners Are Sacrificial Lambs 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: . In this episode, we refer to the importance of and in Scrum teams. The Great Product Owner: The Empirical PO Who Navigated Like a Slalom Skier "He had an idea of the outcomes he had to achieve, and the solution itself—though he had strong beliefs about it—he was incredibly open-minded to feedback from the engineering teams. Most of the innovation came from his engineering teams." - Nigel Baker The best Product Owner Nigel ever worked with operated with a startup mentality, even within a larger organization. This PO had a clear vision—not for a specific end solution, but for an end state of the world. He ran experiments, learned continuously, and had a remarkable ability to pivot smoothly during development. Nigel compares him to a slalom skier: smoothly navigating from post to post, making it look natural rather than effortless. What made him extraordinary was his openness to feedback from engineering teams—most of the product's innovation actually came from the engineers suggesting possibilities, and this PO would absorb those ideas and weave them into the direction. The engineering teams felt secure because they trusted his judgment. He didn't tell people to trust him—he demonstrated trustworthiness through consistent behavior. It was genuine servant leadership: not making a fuss about being in charge, but leading by showing new, cool, interesting behaviors that allowed everyone to follow naturally. Self-reflection Question: Does your Product Owner have a vision for the end state of the world they're trying to create, or are they locked into a specific solution? The Bad Product Owner: The Powerless PO Who Can't Say Yes or No "Accountability requires ability. If they want you to take responsibility for this work, you have to have the ability to see that through. Without that, you're a sacrificial lamb." - Nigel Baker Nigel has seen many PO anti-patterns, but the most damaging one is the powerless Product Owner—someone with all the skills of a business analyst but none of the authority to say yes or no. Commitments get made outside the team, direction can't be changed within sprints, and the whole experience gets crushed. Early in his career, POs were powerful but IT-ignorant business people—dangerous, but at least they had authority. Today's anti-pattern is far worse: people playing the PO role without the O—the ownership. Nigel's approach is direct: he uses the phrase "accountability requires ability" to help the PO understand their position, then traces up the organizational line to find the person who actually holds real power. He reveals to that person that they are, in fact, the Product Owner—and 9 times out of 10, they immediately delegate the authority officially to someone, which is exactly what was needed. That official delegation transforms a sacrificial lamb into a genuine Product Owner with the power to steer. Self-reflection Question: Does your Product Owner have genuine authority to make decisions, or are they a sacrificial lamb accountable for outcomes they can't control? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Nigel Baker Nigel Baker is a seasoned agile coach with a keen intellect, warm creativity, and thoughtful humour. With a career spanning software engineering, consultancy and global training, he inspires teams to thrive, not just perform. Outside work, he loves bold ideas, good conversation and a life well lived. You can link with . You can also find Nigel at . /episode/index/show/scrummastertoolbox/id/40183735

Why Scrum Masters Should Be Measured on Outcomes, Impacts, and Team Happiness | Nigel Baker 03/05/2026

Why Scrum Masters Should Be Measured on Outcomes, Impacts, and Team Happiness | Nigel Baker Nigel Baker: Why Scrum Masters Should Be Measured on Outcomes, Impacts, and Team Happiness 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: . "No customer's going to come to you and say, do you know why I bought your product? Your remarkable compliance with your internal development process. What they're interested in is outcomes and impacts." - Nigel Baker Nigel challenges the traditional ways of measuring Scrum Master success. He points to tools like the —which, he jokes, was neither a test nor invented by Nokia—as examples of process fidelity assessments that miss the point entirely. Compliance with a process tells you nothing about whether customers are satisfied or whether the team is delivering value. Instead, Nigel argues for measuring Scrum Masters on and impacts: customer satisfaction, revenue generation, and efficiencies—the same things a Product Owner gets judged on. But he adds a crucial dimension that POs often overlook: team happiness. Not as an end goal, but as a leading indicator. Happy teams don't leave. Happy teams do better work. Team contentness is a KPI that signals whether the deeper success factors are in place. When your team is deeply unhappy, no amount of velocity or story completion will save you from attrition and decline. Self-reflection Question: How are you currently measuring your success as a Scrum Master—on process compliance, or on the outcomes, impacts, and wellbeing your team actually delivers? Featured Retrospective Format for the Week: Keep It Fresh—A Different Format Every Sprint Nigel's answer to the "favorite retrospective format" question is deliberately controversial: he doesn't have one. His approach is to use a different format every single sprint. Retrospective formats, he argues, "age like milk"—by Sprint 12, asking "what should we do differently?" with the same structure produces diminishing returns. Novelty creates energy. He sometimes gets teams to invent their own formats, which produces some of the most forensic and intense retrospectives he's seen—teams building "superweapons" and then realizing they have to turn those weapons on themselves. But Nigel's most practical tip is using retrospective techniques inside the Sprint Review. The Review is a product retrospective, and stakeholders shouldn't sit "like Roman emperors in the Colosseum, watching the developers as gladiators." Instead, use facilitation methods to extract "sweet, juicy, honey-flavoured feedback" from stakeholders about what they'd change in the product. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Nigel Baker Nigel Baker is a seasoned agile coach with a keen intellect, warm creativity, and thoughtful humour. With a career spanning software engineering, consultancy and global training, he inspires teams to thrive, not just perform. Outside work, he loves bold ideas, good conversation and a life well lived. You can link with . You can also find Nigel at . /episode/index/show/scrummastertoolbox/id/40183765

The "Death of Agile" and Why It's Really the Death of Empowerment That Should Frighten Us | Nigel Baker 03/04/2026

The "Death of Agile" and Why It's Really the Death of Empowerment That Should Frighten Us | Nigel Baker Nigel Baker: The "Death of Agile" and Why It's Really the Death of Empowerment That Should Frighten Us 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: . "It's not so much the death of Agile that's killing me, or death of Scrum. It's the death of things like empowerment, the death of things like empiricism. Those are the things that frighten me in work." - Nigel Baker Nigel brings a challenge that resonates across the entire Agile community: the so-called "death of Agile." But he quickly reframes the conversation in a way that cuts much deeper. The real issue isn't whether teams call what they do Scrum or Agile—it's that the industry is decaying back past waterfall to what Nigel calls feudalism, where a single "great man" dictates and everyone else follows. He distinguishes between two kinds of popularity: the number of people saying they're doing Agile versus the number of people actually liking what they're doing—a gap he compares to Jira's massive subscriber base versus its actual user satisfaction. Through this lens, Nigel introduces his famous "Nigel Scale"—a joke he made on a Scrum Alliance forum 20 years ago that people took entirely seriously. The scale separates Scrum into three levels: core practices that break things if you skip them (like a surgeon disinfecting hands), contextual good practices that may or may not apply (like story points), and persistent anti-patterns that never work no matter how many times people try (like normalizing team measurements across teams). Vasco and Nigel converge on an experiment: treat Scrum adoption itself as a backlog of changes, introducing practices incrementally based on feedback—but always with a compelling vision of why the change matters. Self-reflection Question: When you hear "Agile is dead," are you defending a framework, or are you advocating for the underlying principles of empowerment and empiricism that teams genuinely need? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Nigel Baker Nigel Baker is a seasoned agile coach with a keen intellect, warm creativity, and thoughtful humour. With a career spanning software engineering, consultancy and global training, he inspires teams to thrive, not just perform. Outside work, he loves bold ideas, good conversation and a life well lived. You can link with . You can also find Nigel at . /episode/index/show/scrummastertoolbox/id/40183775

When Teams Slowly Decay by Anointing a Hidden Dictator | Nigel Baker 03/03/2026

When Teams Slowly Decay by Anointing a Hidden Dictator | Nigel Baker Nigel Baker: When Teams Slowly Decay by Anointing a Hidden Dictator 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: . "The world won't end with a bang, but with a whimper. My great fear is not teams exploding like a bomb—that shows they care. The big thing for me is teams that decay slowly." - Nigel Baker Nigel shares a pattern he has witnessed repeatedly: teams that self-destruct not through dramatic conflict, but through a slow, quiet decay. Referencing , he points to something even more insidious than inattention to results—teams that avoid taking responsibility for decision-making. When teams struggle with self-organization, they often try to "self-organize themselves out of self-organization" by anointing a hidden dictator: the big brain, the big mouth, the tech lead, or the project manager who everyone secretly defers to. Nigel offers two practical tools to counter this pattern. First, the "yes and" technique from —instead of taking ownership away from team members, you accept their idea and add to it, keeping the ownership where it belongs. Second, Socratic questioning, where instead of passing knowledge from you to them, you help them pass knowledge from themselves to themselves. But Nigel adds an important caution: the Agile community has swung too far into pure coaching mode. Sometimes people genuinely need help, not therapy—they need to know which server the files are on, not a deep coaching question about their feelings. In this segment, we talk about 's work on improv comedy in Agile, and the power of the for keeping ownership with teams. Self-reflection Question: Is your team quietly deferring all decisions to one person, and if so, what practical steps can you take to redistribute that ownership? Featured Book of the Week: Leading Self-Directed Work Teams by Kimball Fisher Nigel's book recommendations reflect his belief that the most inspiring ideas come from adjacent fields rather than Agile literature itself. stands out because it explores similar principles to the Scrum Master role but without any Agile jargon—showing how a completely different industry arrived at the same insights about empowered teams. Nigel also recommends the , including Business Model Generation and Testing Business Ideas, for the business thinking that coaches need but rarely pick up at work. remains his go-to foundational text for new Scrum Masters. And the book he waited 4.5 years for—until Amazon cancelled the pre-order—is the latest edition of , a deeply practical reference guide that gives real people real tools for real situations. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Nigel Baker Nigel Baker is a seasoned agile coach with a keen intellect, warm creativity, and thoughtful humour. With a career spanning software engineering, consultancy and global training, he inspires teams to thrive, not just perform. Outside work, he loves bold ideas, good conversation and a life well lived. You can link with . You can also find Nigel at . /episode/index/show/scrummastertoolbox/id/40183800

The Scrum Master Mistake of Copy-Pasting Success Instead of Recreating the Journey | Nigel Baker 03/02/2026

The Scrum Master Mistake of Copy-Pasting Success Instead of Recreating the Journey | Nigel Baker Nigel Baker: The Scrum Master Mistake of Copy-Pasting Success Instead of Recreating the Journey Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: . "I was trying to recreate the results of our team, not recreate the journey. And that is what killed me to begin with." - Nigel Baker Nigel fell into Scrum Mastery almost by accident. Working at British Telecom in 2002—before most people had even heard of Scrum—his team adopted it not to speed up, but to add rigor to an already fast-moving tactical unit full of "pirates" who could get stuff done but needed guardrails. His first Scrum Master, , got promoted and moved on, leaving a vacancy. Nigel was the third person asked—and the first to say yes. He loved the role, but his earliest mistake became his most enduring lesson. On his very first daily Scrum, Nigel brought a big leather book and wrote down what every team member was doing, acting like a proto-project manager collecting status reports. The team already had all this information in their system—he was unconsciously positioning himself as the authority figure, having people report to him rather than to each other. As Nigel evolved into an Agile Coach, the bigger failure emerged: trying to copy-paste the process that worked with his first team onto other teams, recreating the results rather than the journey that got them there. Each team needs to evolve its own process—there are no shortcuts to that growth. In this episode, we refer to the importance of and in the Scrum Master role. Self-reflection Question: Are you trying to replicate a successful process from a previous team, or are you investing in helping your current team discover their own path to effectiveness? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Nigel Baker Nigel Baker is a seasoned agile coach with a keen intellect, warm creativity, and thoughtful humour. With a career spanning software engineering, consultancy and global training, he inspires teams to thrive, not just perform. Outside work, he loves bold ideas, good conversation and a life well lived. You can link with . You can also find Nigel at . /episode/index/show/scrummastertoolbox/id/40183815

The Explicit and Implicit Layers of Unclear Decision Rights | Lai-Ling Su 02/27/2026

The Explicit and Implicit Layers of Unclear Decision Rights | Lai-Ling Su Lai-Ling Su: The Explicit and Implicit Layers of Unclear Decision Rights 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: . The Great Product Owner: Building Impactful Relationships That Get Things Done "What made her great was the fact that she focused not just on her technical prowess, but on the people, politics, and the performance side of product. And she used that to turn ambition into reality, and she used that to move strategy to execution." - Lai-Ling Su Lai-Ling describes a phenomenal product owner she worked with about 12 months ago. This woman wasn't just technically strong—she was a leader whose team of 10 loved her because she mentored them to be as strong or stronger than herself. The business loved her because she was exceptionally commercial, thinking about customer value, revenues, expenses, profit models, and marketing long before anything was built. She held everyone true to doing the right thing even when pressure mounted. The executive team loved her because her greatest strength was building solid, impactful relationships that transcended boundaries. She removed the us-versus-them mentality, broke down departmental silos, handled politically charged scenarios, negotiated with difficult personalities across technology, legal, compliance, sales, and operations. She removed impediments responsively and got stuff done when others couldn't. Her secret was focusing on people, politics, and performance—not just technical prowess. In this episode, we refer to , which describes how value in knowledge organizations is created through ongoing conversations—not just meetings, but emails, wiki pages, and corridor conversations that steward decisions over time. Self-reflection Question: How deliberately are you investing in building relationships that transcend your immediate team and department? The Bad Product Owner: Unclear Decision Rights "Does your head of product know that he has the rights and the authority to make the types of decisions that you want him to?" - Lai-Ling Su The anti-pattern Lai-Ling encounters most persistently is unclear decision rights. She illustrates this with a story about a GM in a multinational who effectively worked as a chief product officer. His biggest complaint was that his head of product kept coming to him for decisions that should have been made independently—even though he'd been given $10 million a year to run his teams. When Lai-Ling asked one simple question—"Does your head of product know he has the authority to make these decisions?"—the GM sat in shocked silence for a full minute. But the pattern runs deeper: there's the assumption that people know their decision rights, there's knowing your rights but not knowing how to make those decisions, and there's knowing your rights but getting trumped every time you try, leading to learned helplessness. Some product owners have never learned to make decisions because they always defer to someone who seems better at it. There are both explicit and implicit unclear decision rights—you might tell someone they have authority while implicitly sabotaging their decisions. Self-reflection Question: Have you explicitly confirmed with your stakeholders what decisions you have the authority to make—and are those decisions being respected in practice? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. [The Scrum Master Toolbox Podcast Recommends] About Lai-Ling Su Lai-Ling fixes the gap between operating model design and real-world delivery through her interim executive, consulting, capability building, and executive coaching work. She also equips product and transformation leaders with the capability everyone expects but no one teaches - how to navigate the people, politics, and performance expectations that come with their jobs. You can link with . /episode/index/show/scrummastertoolbox/id/40121945

Scrum Master Toolbox Podcast: Agile storytelling from the trenches

TOPICS