Scrum Master Toolbox Podcast

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 10X Org — Powered by Org Topologies. 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 anoth

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 learn

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, EOS (the Entrepreneurial Operating System), and his DELTA Delegation Ladder 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

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 thi

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 s

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 ev

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 solv

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: Fir

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 tha

Junaid Shaikh: Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It Junaid's book recommendation is The Culture Map by Erin Meyer. 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 Scrum Mastery: From Good to Great Servant Leadership by Geoff Watts for practical advice on the servant leadership role, and regularly visits Scrum Alliance and Scrum.org 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 a

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

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 WageNow. 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

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: http://bit.ly/SMTP_ShowNotes.   In this episode, we refer to the importance of product ownership and empowerment 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

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: http://bit.ly/SMTP_ShowNotes.   "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 Nokia test—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 outcomes and impacts: customer satisfaction, revenue generation, and efficiencies—the same things

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: http://bit.ly/SMTP_ShowNotes.   "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 n

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: http://bit.ly/SMTP_ShowNotes.   "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 The Five Dysfunctions of a Team by Patrick Lencioni, 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 secre

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: http://bit.ly/SMTP_ShowNotes.   "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, Geoff Watts, 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

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: http://bit.ly/SMTP_ShowNotes. 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 bui

Lai-Ling Su: What Scrum Masters Must Do More of in 2026—Think Like a Business 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: http://bit.ly/SMTP_ShowNotes.   "Success is so contextual. And I think the definitions and measurements of success also change over time. So, only you can definitively say what success is at any given time and how to appropriately measure it for your situation." - Lai-Ling Su   Lai-Ling frames success for Scrum Masters around what she'd love to see more of in 2026: smart, strategic, and commercial decision-making. She observes a distinct gap in the business landscape—too few people are making decisions that balance customer value, revenues, expenses, and long-term sustainability.  This could mean reducing SKUs to enhance operational flow and reduce burnout, investing in change management from day one of a transformation, or cutting unused software licenses to save a c

Lai-Ling Su: When Leadership Changes—Supporting Teams Through the Uncertainty Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "We have a once in a generational or once in a lifetime type of opportunity to fundamentally work with these leaders to shift the workplace environments and the workplace dynamics in the way that we've been trying to craft in the world of product and agile for the last few decades." - Lai-Ling Su   Lai-Ling brings a systems-level challenge that has profound implications for Scrum Masters everywhere. Australia is on the brink of its largest intergenerational wealth transfer in history—$3.5 trillion over the next couple of decades—with 70% of private and family businesses planning to sell or succeed as part of this generational change.  This creates leadership vacuums as business leaders transition out and new ones step in. Some are family memb