Podcasts about agile coach

Wasim Osman: The Agile Product Owner Who Runs Two Quarters Ahead of the Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Absolute User Who Works Two Quarters Ahead 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 Product Owner needs to be the absolute user of the software—the user's journey so well defined in their mind that every engineer's question already has an answer, with context." - Wasim Osman   Wasim's best Product Owner works ahead of the team without doing the team's work. Their product roadmap is well-defined at least two quarters ahead of the development cycle, so nobody is panicking against tomorrow's deadline. Designers and product people work on concepts months before development starts, which gives them room to show early ideas to engineers and gather feedback while there's still time to change course. Crucially, this PO is the absolute user of the software—so completely inside the user's journey that when an engineer asks "how does this connect to that module?", the answer is ready, with context. Wasim connects this to how his team uses AI today: the PO can run ahead, spin up prototypes, and iterate on the ideas without burdening the team with building throwaway work—while staying the voice of the customer.   Self-reflection Question: How far ahead of your team is your Product Owner really working—and could they answer an engineer's design question today without going back to the drawing board? The Bad Product Owner: When Optimism Overrides the 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: http://bit.ly/SMTP_ShowNotes.   "They were optimistic without any data. We had the data—they were just being wishful." - Wasim Osman   The worst anti-pattern Wasim has seen is the Product Owner whose optimism overrides the evidence. In one company, a customer asked for a delivery estimate, and the product team promised an aggressive date—"optimistic without any data," even though the data existed. When the engineering team sat down with the numbers, it was obvious the date was impossible, but that gap never reached the customer. The product team stayed disconnected from both the engineers and the customer, so expectations kept drifting from reality. Wasim, who held the data, finally bridged the two and told the product team the real timeline was several months later. They "lost their minds"—but by then it was too late to renegotiate gracefully. The deeper anti-pattern: features handed down without enough depth, so the moment engineering hits real questions mid-development, the PO panics and rushes back to the drawing board while development is already in motion. As Wasim says, "optimism just took over too much."   Self-reflection Question: When was the last time optimism—not evidence—set a delivery date on your team, and who had the data that should have been in the room?   [The Scrum Master Toolbox Podcast Recommends]

Wasim Osman: The Scrum Master as a Router, Redefining Success Through Efficient Communication Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "A big part of the Scrum Master role is to work as a router—handling a lot of conversations with a lot of different devices, even though the internet is coming in through one cable." - Wasim Osman   For Wasim, success as a Scrum Master looks like a router in a house: many conversations, many stakeholders, all flowing through one point that has to prioritize, schedule, and stay on time. If the router slows down, everything downstream stalls—and the Scrum Master becomes the blocker. Early in his career he was overwhelmed juggling three or four engineering teams, so he built himself a personal Kanban board and ran his own quick standup every morning and again at the end of the day, just to see what moved, what stalled, and why. Getting organized with himself is when the work started to feel satisfying, because he stopped being the bottleneck. But he's honest about the hardest part: people rarely tell you to your face when you're slowing them down. The feedback is already there—you're just not hearing it. So you have to ask for it, react well when you get it (or people stop offering), and sometimes name the awkward truth first: "Our meetings used to be better—what happened?" That opening gives everyone permission to be honest.   Self-reflection Question: If you're the "router" for your teams, where are you quietly becoming the bottleneck—and who would tell you if you were? Featured Retrospective Format for the Week: What Went Well / What Went Wrong / Outliers + Open Discussion Wasim's go-to retrospective is deliberately bare-bones: what went well, what went wrong, and—the part that makes it his own—what were the outliers, followed by open discussion. He added the "outliers" question years ago after noticing that team members kept raising points that weren't clearly good or bad, but were still significant enough to discuss. Outliers give people "a bucket for sharing information that has no polarity"—an early signal about the future, a quiet concern, something that doesn't fit the other two columns but matters. He sometimes pairs it with lightweight metrics: sprint completion rate, or tickets that sat too long in review or QA, surfacing patterns the team wouldn't otherwise notice.   Self-reflection Question: What "outlier" signal has your team been sitting on—neither a win nor a problem yet—that deserves an open conversation before it becomes one?   [The Scrum Master Toolbox Podcast Recommends]

Wasim Osman: How Agile Teams Can Start Adopting AI in Software Development Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "It's like my own software has a voice now. It's telling me—okay, you're going to build me like this? Have you considered this?" - Wasim Osman   Wasim's biggest current challenge is one nearly every team shares: how AI is reshaping software development. He sees a clear split—developers rapidly adopting AI-driven development, and others "not downright rejecting it, but still taking their time." His warning is blunt: even when AI hallucinates and generates garbage code, it lets you deliver an order of magnitude faster, and the quality is only going to improve. The early adopters are heading somewhere the late adopters won't be able to reach. In practice, the resistance shows up as questions no one can answer: if I used to get every requirement nailed down before writing code by hand, what do I do with AI—just ask it for a one-liner and hope? Leadership often can't help, because they lack AI experience themselves. At Orkestra SCS, the head of engineering did holistic research into how companies (like AWS, with its AI-Driven Development Lifecycle) are reshaping the process, documented it, and shared it with every team. Feedback sessions and hands-on experiments followed, until they built a tailored version that fit how they actually work. The mindset shift that unlocked it: treat AI as a partner. Wasim describes his software "having a voice"—asking him questions he'd never think of, the way a pair-programming partner would, so the team explores the solution space instead of guessing at it.   Self-reflection Question: Is your team treating AI as a threat to write around, or as a pair-programming partner that surfaces the blind spots you'd never find alone?   [The Scrum Master Toolbox Podcast Recommends]

Wasim Osman: When a Scrum Team's Silence Becomes a Self-Fulfilling Prophecy 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 team is interested in deliberately destroying their outcome or their team. Nobody does that on purpose." - Wasim Osman   Wasim's team was building a SaaS product with real potential. They followed Scrum, shipped features fast—and quietly let the bugs pile up. When customers finally pushed back ("you built five features, four of them have bugs"), the team made a confident bet: one quarter for new features, then one month to fix everything. It didn't work. The bug-bashing month revealed deeper, structural problems that demanded refactoring, and the roadmap was already packed. Then the fixes got handed to a single team, who felt demoted from the "prestigious" work of building features. Resentment grew between the teams. At the height of that tension, the company was acquired by a waterfall-driven parent company. The head of engineering left, the chief architect and two senior engineers followed, and it became chaos. Wasim's hardest lesson wasn't about the acquisition—it was about voice. The engineers assumed waterfall was being forced on them and stopped pushing back; leadership assumed the engineers were fine with it. Nobody said what they actually thought, and the fear became reality. As Wasim puts it, there was "no captain on the ship."   In this segment, we talk about how even conversations need to be iterative, and how a Scrum Master has to balance speaking up (so the team isn't rudderless) without speaking so much that the team stops voicing their own opinions.   Self-reflection Question: Where on your team is an unspoken assumption quietly hardening into reality, and what would it take for you to name it out loud first? Featured Book of the Week: Difficult Conversations by Douglas Stone, Bruce Patton, and Sheila Heen Wasim's most-recommended book is Difficult Conversations: How to Discuss What Matters Most. What stuck with him is a deceptively simple model: every hard conversation is really made of three conversations—the "what happened" conversation (the content), the feelings conversation, and the identity conversation (what the situation says about whether you're competent, good, or lovable). "When I first read it, I thought there can't be only three types of conversations," Wasim admits. "But once you've gone through the book, you can put any conversation into one of those funnels." He found it especially powerful in retrospectives: when the same issue keeps resurfacing, the real conversation is often about feelings, not action items—someone was never okay with an earlier decision, and that's why the follow-ups never happened.   Self-reflection Question: In your last tense retrospective, which of the three conversations—content, feelings, or identity—was really driving the room?   [The Scrum Master Toolbox Podcast Recommends]

Wasim Osman: From Finance to Scrum Master, a Deliberate Career Pivot 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 homework should start a lot earlier than that. The person looking for a particular role should already be moving in that direction before they even start the journey." - Wasim Osman   Wasim never planned to become a Scrum Master. He trained in finance and stock markets in the UK, but the pull toward software—and even 3D animation—had been there since he was young. When he realized the finance world wasn't for him, he made a move that looked like a detour and turned out to be a runway: he joined the people team at a tech company in Bangladesh, a branch of a New York-based firm. He didn't have the leverage to be picky, so he took the opportunity, learned how the engineering teams actually worked, and made himself useful. When the company started shifting from waterfall to agile and hosting Scrum certification events, Wasim was in the room organizing them. One day the head of engineering asked a "random question"—would he consider becoming a Scrum Master? For Wasim, it was an easy yes, because it was the direction he'd quietly been aiming at all along. He shadowed a senior engineer for a quarter, then took over a team of senior-most engineers who were patient with his mistakes. That patience built his confidence, and his willingness to keep his prior curiosity alive made the transition feel organic rather than forced.   Self-reflection Question: What direction are you quietly moving toward right now, and what "homework" could you start today so the next opportunity feels organic instead of accidental?   [The Scrum Master Toolbox Podcast Recommends]

This year's Agile 2026 theme was “shaping the future with agility,” and that is exactly where Kate Megaw and Anu Smalley found the industry: mid-shift, still deciding what comes next. Back from the conference, they sit down with Ryan Smith for an honest field report. The partnership between PMI and the Agile Alliance has solidified, so the room was no longer split into project managers on one side and Scrum Masters on the other.  AI, meanwhile, has stopped being the shiny new thing bolted onto every session title and settled into the operating system of how we work, though “don't forget the human” is still treated as a footnote.  Kate and Anu wrestle with an industry in flux where no one has put a finger on what is broken yet, the Scrum Master role morphing into a dozen job titles, and Anu's growing conviction that the psychology of AI is the work that matters.  The phrase that stuck with Kate from one of the sessions says it all: we are in the age of perpetual transformation.

You schedule the meeting, you ask for input, and the room goes quiet. Then the real conversation happens in the hallway afterward. Kate Megaw and Ryan Smith dig into why people stay silent, and what facilitators can actually do about it. Silence is rarely about a disengaged team. It is fear of looking foolish, internal processors who need time to think, a leader who anchors the room before anyone speaks, and big talkers who cannot sit with a pause. Remote meetings can quietly make all of it worse.The cost is real. Silence erodes trust, hides risks that surface mid sprint when it is too late, shrinks innovation, and hands the decision to the loudest voice in the room. Kate and Ryan share the practical moves they use to turn it around, from waiting out the silence and asking sharper questions, to silent writing, round robins, breakout pairs, stacking, and priming the pump before the meeting even starts. The throughline is simple. Facilitation is not just a soft skill, it is a design tool. Good meetings are designed, not winged, because as our friend Anu likes to say, “winging it is not a plan”!

The Scrum Master role has quietly evolved, and the industry has not caught up. Kate Megaw and Ryan Smith unpack how the role calcified into a person who runs the events and works through a checklist, when the real job was always to be a change agent and an organizational catalyst. Look at the job market and you see the shift already happening. Scrum Master, Project Manager, Technical Project Manager, Delivery Manager, and Program Manager are being used interchangeably, because the title never fit cleanly on an org chart and the Scrum Guide 2020 move from roles to accountabilities went largely unnoticed.Kate and Ryan wrestle with a hard question. If the title confuses more than it clarifies, is it time to let it go? The word master implies telling rather than facilitating, and the name says nothing about what the person actually delivers. They also push back on the idea that agility is dying, making the case that it is becoming the DNA of healthy organizations instead. The takeaway is simple and a little uncomfortable. Stop defending the label and start demonstrating the impact a person in this role can have.

Alf Dobbert-Baums: The Too-Technical PO and the One Who Was Willing to Experiment In this episode, we refer to Shift: From Product to People and the value of keeping the PO–developer conversation at the goal level. The Great Product Owner: The PO Who Was Willing to Drop the Spec and Trust the Developers 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.   "Let's ditch the technical part, and let's see what happens." - Alf Dobbert-Baums   The Great PO, in Alf's experience, is willing to experiment with letting go. She stopped writing detailed technical specifications and started writing plain user stories. Then — and this is the harder move — she stopped throwing them over the fence and walked into the developers' space to have the conversation. Alf had coached her toward it, and he watched the trust compound. Because she trusted the developers on the how, she had less work to do (the developers were closer to the system anyway) and the developers had room to make real decisions. The conversation stayed where it belonged: on the goal. Alf names the pattern this great PO embodied — open to experiments, willing to say "let's see what happens," and quietly resisting the seductive pull of getting technical because it feels safer. The Scrum Master's job is partly to make that letting-go feel safe enough to try.   Self-reflection Question: Where is your PO still writing the "how" — and what would it take for them to trust the developers enough to write only the "why" and the "what"? The Bad Product Owner: The PO Who Thinks They Know More Than the Developers Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "He said: 'developers can retrieve the information from the archive database.' The developer said: 'the information is not in the archive database.'" - Alf Dobbert-Baums   The anti-pattern is the PO who is too technical — the one who writes specs full of implementation detail and treats the developers as executors. Alf calls him John. John wrote a user story that told the developers exactly where to fetch the data from: the archive database. Then he tried to hand the story to Alf to present, the way a memo gets handed across a desk. Alf refused. He insisted John present it to the developers himself. John did. The first developer to speak said the information wasn't in the archive database. Alf hopes that moment humbled John a little. The point isn't whether John was right about the database — the point is the dynamic. When the PO writes the technical answer into the story, the developers stop being collaborators and become receivers. The translation work that creates real value — between user goal and technical option — never happens. The PO ends up with more work, less ownership from the team, and worse outcomes.   In this segment, we refer to Shift: From Product to People and the idea that great POs facilitate the conversation between user goal and team, rather than dictating it.   Self-reflection Question: When was the last time your PO wrote a technical detail into a story and the developers had to walk it back — and what would change if the PO trusted them to design the "how"?   [The Scrum Master Toolbox Podcast Recommends]

Alf Dobbert-Baums: Success Is When the Team Gets Closer to the User 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.   "Getting closer to the user — it's always very good to get the feedback from the user." - Alf Dobbert-Baums   For Alf, success as a Scrum Master is measurable in proximity: how close did you get the team to the actual user? He tells a small story that makes the point bigger than it sounds. In a sprint review, a user mentioned an annoying detail — clicking an item in a long list opened a popup, and when you closed the popup, the focus jumped back to the top of the list. Four hours later, the team had fixed it. A small JavaScript change saved a whole customer-center team from scrolling back to find their place dozens of times a day. The shift Alf coaches is treating the review as a working meeting, not a demo. Users don't clap and leave — they discover. They surface the thing the PO doesn't see, because the PO has perspective and the user has the actual workflow (often with three other apps open at the same time). Alf credits a usability test he once ran for opening his eyes: "Why are you clicking there? Nope, she wouldn't click on there." When the developer sees a real person use the software, the product changes. The guessing stops.   In this segment, we refer to Shift: From Product to People by Michael Dougherty and Pete Oliver-Kruger and their Usability Theater technique — getting users to use the product while the team watches, the way you'd watch a play.   Self-reflection Question: When did your team last watch a real user use the product — and if it's been a while, what's stopping you from inviting one to your next review? Featured Retrospective Format for the Week: The Classic Four — Prime Directive + Good / Learned / Change / Puzzles Alf's favorite retro is one of the very first. Open with the Prime Directive, then walk the team through four questions: what was good, what did we learn, what should we change, and what still puzzles us. Alf likes it because it celebrates successes, shares knowledge, and — through the "puzzles" question — gives space for the unresolved things people carry in their heads. But he wants to stress one thing most teams skip: revisit the agreed improvements in the next retro. Did you do them? Are they still relevant? Did the world change? Even improvements that didn't work give you information — about who to involve next time, what was missing, what was too much. Without revisiting, every retro starts from scratch.   [The Scrum Master Toolbox Podcast Recommends]

Alf Dobbert-Baums: When Management Writes a Book — AI, Strict Process, and the Missing Court System Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "They don't really know — do I need to follow these rules, or are they at my goodwill?" - Alf Dobbert-Baums   The developers and AI are on good terms. Then management decided to extend AI into product management — and the way to do that, of course, was stricter process. Same JIRA boards. Same columns. Same quality gates. Across every product. Management wrote a book and called it "how we develop." Then, in the next breath, said: "but it's not meant to be that strict — you have flexibility." Two messages, opposite directions. The result, Alf describes, is confusion and psychological-safety problems. The teams don't know whether they're playing by the rules or breaking them. They experiment with how far they can bend the book. They fall back on "common sense" and quietly skip what makes no sense. They've collected feedback — structured, organized — but feel they aren't heard. In the conversation, Vasco's framing of the legal system (every set of rules needs a court system to interpret them) led Alf to a real experiment: take the negative rules and reframe them as positive goals. Not "fewer meetings" — "meaningful meetings." Then match feedback to the goal, not the rule. It's an idea Alf came up with mid-conversation, and it's the kind of small frame-shift that can crack open a stuck dialogue with management.   Self-reflection Question: Where in your organization is management asking people to follow rules they haven't defined the goal for — and what would change if you reframed those rules as goals?   [The Scrum Master Toolbox Podcast Recommends]

Alf Dobbert-Baums: The Team That Decided Sprint Goals Were Optional 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.   "Everything was a golden route. It was kind of like a little feature factory." - Alf Dobbert-Baums   Alf coached three teams. None of them cared about THE sprint goal. Most sprints had five or six "goals" — which is to say, none. The Product Owner was a proxy PO, no authority to say no, so anything that landed in the inbox got pulled into the sprint. The team had several applications to support on top of feature work. Missing a sprint goal had no consequences, so the question stopped being asked. When Alf pushed for a single, focused goal — concrete or abstract, didn't matter — the team would shrug and add three more stories to the cluster. Asked which item mattered most, they answered: "all of them." Alf names the dynamic precisely: short-term personal urgency replaced the team goal, and "all of them" became the death of focus. The cost wasn't just the missed goals — it was the missed collaboration. With a sprint goal, the team works together on one thing. Without one, they cooperate on parallel tracks and call it a sprint. There's a difference. Sprint goals create focus, predictability, and the rare feeling of finishing something together.   In this segment, we talk about the difference between cooperation and collaboration and why sprint goals are the lever that turns one into the other.   Self-reflection Question: If you asked your team this sprint "what's the most important thing we'll finish?" — and they answered "all of them" — what would you do next? Featured Book of the Week: Humble Consulting by Edgar Schein and Don't Just Do Something, Stand There by Marvin R. Weisbord Alf gives two recommendations. The first is Humble Consulting by Edgar Schein — "It teaches you that you don't know anything, and even if you ask, you still will not fully understand what the other person is in… But the good thing is that when you ask questions, it might help the other person to get on a different track." The second is Don't Just Do Something, Stand There by Marvin R. Weisbord. Alf tells a story to explain why it matters: he prepared a polished 90-minute workshop. Within 5 minutes of starting, the team's real topic surfaced — and it had nothing to do with his agenda. His head screamed "no, my workshop!" but the book gave him permission to ditch the plan, name what he was seeing, and let the team choose. They chose the new topic. He moderated. It became one of the most important sessions he ever ran. The lesson: don't just do something — stand there, and let what's really happening become visible.   [The Scrum Master Toolbox Podcast Recommends]

Alf Dobbert-Baums: The Two-Country Scrum Team and the Rapport That Never Showed Up 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 did not quite go as planned. I was really humbled." - Alf Dobbert-Baums   Alf was new in the company. His boss walked over with a setup that already sounded like a warning: two development teams in two countries, two locations in Germany, a "difficult" Product Owner — and a quick "do you want to take it?" Alf said sure. Everything happened on video chat. Every meeting, every conversation, every attempt to read the room — through a window that closed the moment the call ended. The rapport never built. The PO stayed difficult. Alf eventually got pulled from the team. Looking back, he saw what the video chat had hidden: the crossed arms, the eyes drifting to email, the small in-between moments that turn coworkers into colleagues. The fix wasn't a tool — it was a flight. Visit the other location. Run a workshop with a real goal ("how do we want to work together?", "what's hard about our setup?"). Build a positive anchor before anything goes wrong, not after. And when you do go, don't lead with the failures — lead with what could be possible together.   In this episode, we refer to the practice of building team working agreements as a way to create rapport without putting people on the defensive.   Self-reflection Question: When was the last time you saw the people you work with face-to-face — and what conversations are you still postponing because they only happen well in person?   [The Scrum Master Toolbox Podcast Recommends]

Zukunftsmut: Menschlichkeit im KI-ZeitalterIn der heutigen Folge spricht Martin Giesswein mit der erfahrenen Innovatorin, Agile Coach und Mentaltrainerin Martina Schmerold-Tagunoff. Angesichts des aktuellen „KI-Wahnsinns“ und der spürbaren Überforderung in vielen Unternehmen beleuchten die beiden, wie wir als Menschen resilient, adaptiv und kooperativ bleiben können.Martina teilt wertvolle Insights aus ihrer 10-jährigen Erfahrung als Innovationsmanagerin beim ÖAMTC, wo sie unter anderem ein bahnbrechendes Drohnen-Projekt initiiert und das Team erfolgreich in die Selbstorganisation geführt hat.Der KI-Hype und die Realität: Warum Tools alleine keine Transformationsprobleme lösen und warum Weiterbildung und psychologische Sicherheit oft auf der Strecke bleiben.Erfolgsstory ÖAMTC-Drohnenprojekt: Wie man mit einer Guerilla-Taktik, interner Vernetzung und dem richtigen Support innovative Projekte gegen Widerstände durchsetzt.Experiment Selbstorganisation: Martinas Reise mit einem hierarchiefreien Team beim ÖAMTC – von Gehaltstransparenz bis hin zur Verteilung von Führungskompetenzen.Psychogramm der Zukunft: Welche Kompetenzen Menschen brauchen, um gut mit KI umzugehen, und warum regelmäßige „KI-freie Tage“ die Reszilienz stärken.Zukunftsmut statt Angst: Wie Martina Unternehmen dabei unterstützt, Veränderungen nicht als Bedrohung, sondern als gestaltbare Zukunftskraft zu sehen.„Je mehr KI, desto menschlicher wird es.“ – Ein flammendes Plädoyer für Empathie, sozialen Austausch und echte Verbindung in einer digitalisierten Welt.LinkedIn: Verbinde dich hier mit Martina Schmerold-TagunoffHat dir diese Folge gefallen? Dann abonniere den Podcast, hinterlasse uns eine Bewertung und teile die Folge mit Kolleginnen und Kollegen, die heute ein Stück Zukunftsmut gebrauchen können!

Kate and Ryan come at agility from opposite ends of the org chart. Kate arrived through training, operations, and project management on the leadership side. Ryan started as a front-end developer who built a Kanban board before he knew it had a name.  In this episode they trace Ryan's path from coder to Scrum Master, and dig into the questions every agile practitioner eventually asks.  Does a Scrum Master need to be technical?  What does the role really protect?  Why do so many transformations stall without a dedicated Scrum Master?Ryan makes the case that Scrum is agnostic to the work itself, that the Scrum Master creates the air the team breathes, and that the most important job is enforcing the pact between the team and the business so developers can do their best work without interruption.  He closes with practical advice for anyone growing into the role: go back to the Scrum Guide, get certified, and strip away the barnacles you have collected from role to role.

Jedes Team trifft Entscheidungen. Aber wie viele davon sind wirklich gut? Und wie viele entstehen einfach, weil irgendwann alle müde waren? Michel Eggebrecht ist Wirtschaftspsychologe, systemischer Organisationsberater und Autor. In dieser Folge reden wir darüber, was Gruppenentscheidungen so schwierig macht und warum der Wunsch nach Konsens oft mehr schadet als nützt. Wir schauen auf drei klassische Fallen: Konformität, pluralistische Ignoranz und Verantwortungsdiffusion. Michel erklärt, wann es Sinn macht, Entscheidungen ins Team zu geben und wann nicht. Und wir reden über konkrete Methoden, die den Prozess schneller und ehrlicher machen.

Maria Skvortsova: The Yes-Man Product Owner and the Scrum Master Who Became a Proxy for the Proxy In this episode, we refer to User Story Mapping and the MoSCoW prioritization method. The Great Product Owner: Structure Over Gut Feeling — When a Well-Shaped Backlog Speaks for Itself 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 indicator of a good product owner is a well-shaped backlog — with priorities, with values, with efforts. You definitely know that you pull from the top, and it is the most valuable thing you should work on." — Maria Skvortsova   For Maria, the best product owners she's worked with share one trait: they bring structure. Not rigidity — structure. They use techniques like user story mapping to make priorities visual for everyone. They use value-effort matrices instead of gut feelings. They apply methods like MoSCoW to give the backlog a clear, unambiguous order. The result? A developer never has to ask "what should I work on next?" — the answer is always at the top of the backlog. Maria, drawing on her decade as a C++ developer, knows firsthand how frustrating it is to chase down a BA or PO just to figure out what to build next. A well-ordered backlog doesn't just help the team move faster — it also makes it easier for the product owner to communicate with the business, because every decision has data behind it, not just intuition.   Self-reflection Question: Could a new team member look at your product backlog right now and immediately know what to work on next — and why that item is the most valuable? The Bad Product Owner: The Yes-Man Who Sank the Ship — When Saying Yes to Everything Means Delivering Nothing Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "He was always saying yes. And this led to the scope that grew and grew, until we realized we were not capable of delivering what we committed to." — Maria Skvortsova   Maria returns to her SAP migration experience for this anti-pattern. The team had a team lead acting as product owner — someone technical who saw everything as important. Every new requirement got a "yes." The scope ballooned while the iron triangle held firm: fixed cost, fixed time, no room to breathe. The team reached a breaking point where they had to admit, to each other and to the client, that delivery was impossible. Maria stepped in as what Vasco called "a proxy for the proxy" — she helped the team lead build a user story map on Miro, then facilitated a workshop with the business. Her question was disarmingly simple: "If we don't deliver this by go-live, will your product still function? If yes, it goes to release two." That reframing — not "no" but "yes, later" — gave the client clarity without triggering defensiveness. The team lead learned that business stakeholders aren't the enemy; they just need someone to help them make honest trade-offs. And saying "not now" is infinitely more useful than saying "yes" to everything and delivering nothing on time.   Self-reflection Question: When was the last time you or your product owner said "not now" to a stakeholder — and did it feel like a failure or a strategic decision?   [The Scrum Master Toolbox Podcast Recommends]

Maria Skvortsova: If Your People Feel Safe, You Succeed — Measuring What Matters as a Scrum Master Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If your people feel safe and comfortable in the environment you built, then you succeed. If not, that's something you should change in your ways of working." — Maria Skvortsova   For Maria, success as a Scrum Master has nothing to do with green reports or velocity charts. She's seen green dashboards masking miserable teams and sky-high velocity hiding terrible quality. Instead, her definition of success centers on one thing: can a developer honestly tell the product owner that a story isn't ready — and not be punished for it? That's psychological safety in action. Maria measures this through healthy conflict — the team's ability to disagree constructively, to challenge each other without fear. She uses the Vacation, Shopper, Prisoner, Explorer retrospective as a gauge: are people showing up as engaged shoppers and explorers, or as reluctant prisoners? She also emphasizes a practice that many Scrum Masters overlook — having regular one-on-ones with every team member. Not just for task alignment, but to understand their cultural background and personal context. Maria works with people from many different cultures and has learned that what feels like disengagement in one culture might be deep respect in another. Her tip: before assuming you understand someone's behavior, invest in learning where they come from. The cultural awareness you build through those conversations will make you a better Scrum Master than any framework ever could.   Self-reflection Question: How do you know whether the people on your team feel safe enough to say "no" or "this isn't ready"? When was the last time you checked? Featured Retrospective Format for the Week: Stinky Fish Maria's favorite retrospective format is the Stinky Fish. The metaphor is simple and vivid: a stinky fish represents the things a team is trying to hide, the elephants in the room that everyone avoids. The longer you hide the fish, the worse it stinks. The exercise asks team members to put their "stinky fish" on the table and admit that something smells. Maria doesn't use this format every sprint — she saves it for when she senses there's something the team is avoiding. She also structures all her retrospectives using the Derby-Larsen model: opening, objective data (burn-downs, defect counts), subjective data, insights, decisions, and closing with a ROTI (Return on Time Invested) vote. For large teams, she uses breakout rooms in pairs — because when you're in a pair, it's impossible not to talk. She also uses Mentimeter for interactive slides, letting people grab their phones, relax, and contribute without the pressure of speaking up in front of 17 people.   [The Scrum Master Toolbox Podcast Recommends]

Maria Skvortsova: Breaking the Factory Mindset — When a 17-Person Scrum Team Treats Development Like an Assembly Line Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "They wait for the story to be pushed to them, then they hand it to QAs and say 'it's not my business anymore.' We have not a Scrum team, but a factory." — Maria Skvortsova   Maria's current challenge is one that many Scrum Masters will recognize: a large distributed team — 17 people, cameras always off, only four months together — that operates like a factory instead of a collaborative unit. In refinement sessions, only the Tech Lead, BAs, and QA speak. Everyone else stays silent. When the sprint starts, developers wait for the Tech Lead to assign stories, work on them in isolation, then toss them over the wall to QA with a "not my problem" attitude. Maria and Vasco explored this challenge through a coaching conversation, identifying information loss as the core issue. Every handoff between developer and tester destroys knowledge and slows the process. Maria had already introduced desk testing — pairing a developer with a QA before deployment to walk through the code on the developer's machine. It worked well in previous teams, but this team keeps forgetting, and in a recent retrospective they even proposed creating a "handover to QA" subtask — the exact opposite of what Maria is trying to build. The experiment that emerged: find a few early adopters willing to try a deeper collaboration model where developers participate in testing and testers participate in design — starting small, measuring what changes, and letting results speak louder than process mandates.   Self-reflection Question: Where are the biggest information loss points in your team's development process, and what experiment could you run this sprint to reduce them?   [The Scrum Master Toolbox Podcast Recommends]

Maria Skvortsova: The Team That Gave Up — When Green Reports Mask a Sinking Ship Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "They said, 'Yeah, we know, but no one will listen to us.' And they just gave up — waiting for the ship to sink so they could swim away." — Maria Skvortsova   Maria walked into a 20-person migration team where the PowerPoint reports glowed green but the reality on the ground was covered in red flags. Developers were building features against requirements that had already changed — nobody had told them. The scope was impossibly large, and when Maria asked the team why they hadn't raised a red flag, the answer shook her: "No one will listen to us." The team had given up. They were waiting for the project to fail so they could leave. Maria's first instinct was to observe — spend weeks understanding the dynamics, the communication patterns, the culture. But she learned the hard way that when a team is already drowning, there's no time for a slow ramp-up. She needed to act immediately. Her breakthrough came from a simple technique: replacing some daily standups with an async RAG (Red-Amber-Green) status system in Jira. Team members just chose a color for each story — no explanation needed. It gave them psychological safety to signal problems without speaking up in a 20-person meeting. From there, Maria broke the team into smaller cross-functional groups — one QA, one developer, one consultant — so they could actually discuss features instead of hiding behind silence.   In this episode, we refer to Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem. Also check out the episode with Barry and Christiaan, authors of the book, on the podcast.   Self-reflection Question: When you join a new team and sense that something is deeply wrong, how long do you wait before acting — and is that waiting period serving the team or just your own comfort? Featured Book of the Week: Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem Maria chose Zombie Scrum Survival Guide because, as she puts it, "Most Scrum Masters learn by the happy path. We all know how it should be. But we rarely think about how it should not be." The book focuses on detecting anti-patterns early — before they become entrenched behaviors that are much harder to break. Maria finds it especially valuable because it provides concrete experiments you can try with your team to shake off the zombie symptoms. Her advice: start here, because understanding what bad looks like is just as important as knowing the ideal.   [The Scrum Master Toolbox Podcast Recommends]

Maria Skvortsova: When Agile Labels Hide Waterfall Reality — A Scrum Master's Wake-Up Call in SAP Migration 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 realized that even if I like Scrum and Agile, and I think they are really good ways of thinking, some areas cannot adapt them because they are completely different from the mindset and ways of working." — Maria Skvortsova   Maria came to Agile with the fire of a true believer. After a decade as a C++ developer, she'd found something that matched how she thought and felt about building software — something that went beyond controlling budgets and roadmaps. When a boutique SAP consulting company hired her as an Agile coach to transform their entire organization, she was all in. She built what she describes as a "really good" training for senior management, designed to sell them on Agile ways of working. But when she stepped out of the PMO role and into a real SAP migration project as delivery manager, the ground shifted beneath her. The iron triangle — fixed cost, fixed scope, fixed time — ruled everything. Teams ran "sprints" that were really just boxed iterations with no feedback loops, no value delivery, just a march toward a go-live date. Maria realized she was putting Agile labels on a fundamentally waterfall process. The hardest part wasn't the discovery — it was accepting that she needed to redirect her energy to environments where Agile could genuinely take root, rather than forcing it where the mindset simply didn't exist. Her advice: recognize when labels don't match reality as quickly as possible, and have the courage to choose environments that align with how you want to work.   Self-reflection Question: Are you putting Agile labels on processes that are fundamentally waterfall? How quickly would you recognize the mismatch — and what would you do about it?   [The Scrum Master Toolbox Podcast Recommends]

Christian Thordal: The Jazz Duo Effect and The Absent PO — Two Sides of Agile Product Ownership The Great Product Owner: Clarity, Accountability, and a Partnership That Fills in the Blanks 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 kind of filled in the blanks for each other, and it felt very natural — it's grown organically into this partnership where we're extremely aligned on how we see and do things." - Christian Thordal   Christian describes his best Product Owner as someone he currently works with — a person who combines deep product clarity with genuine leadership. This PO is fully accountable for the backlog, sets clear expectations toward the teams, and isn't afraid to push them. What makes this PO stand out is how they use reporting as a communication tool: alongside the backlog, they proactively communicate to the product leader whether things are within or outside scope, always with a plan ready. Christian and this PO hold weekly follow-ups to discuss the team, the backlog, and the product direction. Over time, their alignment has become so strong that during facilitation sessions they naturally fill in blanks for each other — one picks up where the other leaves off. Vasco compared it to a jazz duo, where each musician picks up on the other's leads in real time. This kind of organic partnership in leadership direction reflects positively on the entire team, creating a sense of coherence and momentum that everyone can feel.   Self-reflection Question: How aligned are you with your Product Owner on leadership direction, and what would it take to build the kind of partnership where you naturally fill in the blanks for each other? The Bad Product Owner: When the PO Disappears and the Scrum Master Becomes the Glue Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "You can inspire, you can motivate, but you can't really do the work for them." - Christian Thordal   Christian shares an experience from a larger logistics company in Denmark where the Product Owner was a great, likable person — but didn't understand the role. The backlog was high-level, consisting primarily of Epics with no acceptance criteria. Then the warning signs started: the PO became increasingly hard to get a hold of, started canceling refinement meetings (sometimes on the same day), began working more from home, and became physically more distant from the team. Christian and the team were left to navigate on their own, breaking down epics into stories and tasks without knowing if they were building the right product. Christian tried setting up weekly one-hour sessions to help the PO work through the backlog, but the fundamental problem remained — you cannot do the PO's work for them. Eventually, Christian found himself filling in for the PO, which is itself an anti-pattern: the Scrum Master becoming the glue that holds the product together. The symptoms to watch for are clear: a PO who starts missing meetings, backlog items that remain unrefined, a PO who becomes physically or remotely distant, and — the biggest red flag — a Scrum Master who feels compelled to step in and do the PO's job.   Self-reflection Question: Are there signs that your Product Owner is drifting away from the team, and have you caught yourself filling in gaps that aren't yours to fill?   [The Scrum Master Toolbox Podcast Recommends]

Christian Thordal: Structure Creates Freedom, How an Agile Coach Measures Success by Becoming Less Needed 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 less I shine and the more the team shines, the better I perform." - Christian Thordal   Christian shares how his definition of success has fundamentally shifted over the years. Early in his career, the question was "How can I shine?" Today, it is the opposite — success means becoming invisible. For Christian, a high-performing Scrum Master builds teams that no longer depend on them, much like raising a child to become a functional adult by eighteen. They can always call dad for coaching or to borrow money, but they can stand on their own. He illustrates this with a team he moved from what he calls "cowboy loose Kanban" to an adapted Scrum framework. The structure gave the team freedom: he can now miss dailies and planning sessions, and the team still produces a solid plan, sprint backlog, and sprint goal. He drops by to give pointers and encourage good behaviors. Christian also highlights the importance of the Scrum Master and Product Owner partnership — "the mom and dad of the team" — and how building predictability and flow matters more than heroics. A key tactical insight: he created a one-pager roadmap for his domain leader showing issues, plans, milestones, and metrics. This simple artifact gave leadership the comfort that things were under control, buying Christian the autonomy to do his best work. This proved critical when his team was decimated by departures in late 2025 — he hired new people, stabilized the group, and got them delivering again.   Self-reflection Question: What would it look like if your team could run a full sprint cycle without you present — and what is stopping that from happening today? Featured Retrospective Format for the Week: The Four-Box Retrospective Christian shares a retrospective format he calls the Four-Box Retrospective — a structured, pragmatic approach that resonates especially well with engineer-minded teams. The session begins with a team check-in to get the vibe in the room. Next, the team reviews last week's agreements: who was accountable, and are those items still alive or handled? Anything still alive moves forward automatically, ensuring nothing falls through the cracks. Then comes the core mechanic: topic creation divided into four boxes — Tech (tools and tech stacks), Team (issues within the team), Outside (external dependencies and blockers), and Parking Lot (everything else). Presenters explain their topics briefly to give context, and the group uses dot voting to surface the most pressing issues. Discussion follows, with clear accountability assignments and action items written down. The pre-grouping into four boxes saves significant time by giving topics a natural home before discussion begins. Named owners for every action item create real progress between retrospectives. Christian values this format because it is grounded in actual operational problems — people can see the direct application of every conversation, which keeps engagement high and outcomes tangible.   [The Scrum Master Toolbox Podcast Recommends]

Christian Thordal: Managing Cross-Team Dependencies in Scaled Agile, From Planning to Real-Time Coordination Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "When one team's plan failed, the rest collapsed — deliveries and outcomes were delayed across the entire domain." - Christian Thordal   In this episode, Christian Thordal shares the biggest challenge he faced as an Agile Coach working within a large Danish broadcast company's technology division, where 32 teams operate across multiple domains. Within his domain of 10 teams, they plan in three-month cycles using OKRs, but a critical blind spot kept undermining their results: nobody had a clear grasp of the dependencies between teams and sister domains. When one team's delivery slipped in a previous cycle, it triggered a cascade of failures across the organization. Christian and the agile coaching community escalated the issue to the portfolio and delivery department, pushing to synchronize cycle timing across domains. He introduced a "big room planning" approach within his domain to map out which teams they impact and who impacts them, structured around a three-week cadence: define OKRs, align, then commit. A key coaching insight reshaped his thinking: dependencies are not facts — they are decisions. By naming the specific people involved (the person who needs resolution and the person who provides it), teams can manage dependencies in real-time rather than waiting for a program management layer that only addresses problems after escalation. Christian now plans to establish dedicated coordination days during each cycle where teams actively collaborate and resolve dependency issues together.   Self-reflection Question: When dependencies between your teams cause delivery failures, do you treat them as coordination problems to solve in real-time, or do you wait for escalation through a management layer?   [The Scrum Master Toolbox Podcast Recommends]

Christian Thordal: How "Fake Kanban" Fooled the Metrics, And What This Agile Coach Did to Fix It Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The team was like birds in a nest waiting to get fed — completely dependent on the PO for every piece of work." - Christian Thordal   Christian tells us about a team that always appeared busy but was hiding serious dysfunction behind a single healthy metric. When he rated the system across his domain, he found the team scored low in process maturity, effectiveness, and learning — yet their cycle time looked good. The team claimed to practice Kanban, but in reality it meant "we can do whatever we want." Daily standups had become social check-ins. The backlog held over 100 items to do and 50+ in progress, most of them just headlines with no descriptions. Real work assignments happened through 30-minute Slack huddles between the PO and individual developers — pure push, no prioritization. Despite having OKRs, the team could only plan a week ahead. Christian's fix was radical: he restarted the backlog entirely, cutting 150 items down to roughly 30, established WIP limits to create a pull-based system, and brought the team into the process as active participants rather than passive recipients.   In this segment, we refer to Kanban and OKRs.   Self-reflection Question: When was the last time you looked beyond a single "green" metric to understand what was really happening in your team's workflow? Featured Book of the Week: Turn the Ship Around by David Marquet Christian recommends Turn the Ship Around by David Marquet, a former U.S. Navy submarine commander who transformed his crew's performance by replacing permission-seeking with intent-based leadership. Instead of waiting for orders, crew members were expected to say "I intend to..." — transferring ownership and making people accountable for their decisions. Christian says this deeply resonated with his own military background in the Danish Army, where leadership operated on similar principles. The book's core message — stop creating dependency and start building leaders at every level — connects directly to the team story in this episode, where passive dependency on the PO was the root of the dysfunction. You can also listen to previous episodes with David Marquet and explore more on intent-based leadership.   [The Scrum Master Toolbox Podcast Recommends]

Christian Thordal: When Applying Scrum By The Book Fails, Understanding Context Before Changing The System Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I treated Scrum like a military SOP — follow the book, execute the steps. But I failed to see that the context was really the tipping point. What looked like a problem was actually their solution." - Christian Thordal   Christian shares a hard-won lesson from his time coaching three RPA teams at one of Denmark's largest banks during the pandemic. He inherited teams running six-week sprints with half-hour planning sessions that amounted to little more than putting items on a calendar. As a former Danish Army officer, Christian's instinct was to fix the obvious deviation from the Scrum Guide — the sprint length. He advocated for shorter feedback loops and eventually convinced the Product Owner, who also served as the director, to try two-week sprints. The first planning session was a disaster. There was yelling and scolding, and it became clear that the real problem had nothing to do with sprint length. The teams had no proper backlog. The six-week sprints actually worked because they gave teams enough time to go out to the business, discover work, and deliver it within a single cycle. Christian realized he had been applying Scrum mechanically without understanding how work entered the system. He started attending business analyst and PO meetings, uncovered the backlog gap, and helped the teams build a proper one. His key insight: what looks like a symptom can actually be a pragmatic solution to real constraints. Understand the system before you change it.   In this episode, we refer to the book Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland.   Self-reflection Question: When was the last time you assumed a team's practice was wrong, only to discover it was a reasonable adaptation to their context? How might you investigate the "why" behind existing processes before proposing changes?   [The Scrum Master Toolbox Podcast Recommends]

Peter Merel: AI Alignment Is the Agile Coach's Next Frontier — Using Throughput Accounting and Pull-Based Transformation to Prove Value 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.   "Our jobs ARE about alignment. Alignment is how do we get all of the people and all of the tools to work together for mutual benefit." - Peter Merel   Peter Merel brings a provocative perspective on the biggest challenge facing agile professionals today: AI and agile alignment. With AI rapidly advancing, Peter observes that everyone in the agile community is afraid for their jobs — but argues this fear is misplaced. The real challenge isn't replacement; it's alignment. How do we get biological and electronic entities to work together for mutual benefit? Peter's answer begins with pull-based transformation — building a thin steel thread from business through to DevOps, proving it works with a small group, then growing it. He connects this to Goldratt's throughput accounting, arguing that throughput (operating expense plus net profit) is the only metric immune to Goodhart's Law. From throughput, Peter derives three flows: value flow (throughput itself), workflow (the first derivative — what increases value flow), and learning flow (the second derivative — what improves workflow). He then introduces the pirate metrics (AARRR) — acquisition, activation, retention, referral, and revenue — as market constraints that can be analyzed through Theory of Constraints. Peter's frustration is that 25 years after Agile began, most business stakeholders still can't identify their market bottleneck. Without that knowledge, he argues, priorities are meaningless. The path forward for agile coaches? Bring scientific rigor to transformation, measure what matters, and prove value before scaling.   In this episode, we refer to FAST Agile, Joe Justice's work with Tesla and WikiSpeed, and the connection between throughput accounting and agile transformation metrics.   Self-reflection Question: Can you identify the single biggest market constraint limiting your organization's throughput right now — and if not, how confident are you that your current priorities are the right ones?   [The Scrum Master Toolbox Podcast Recommends]

BONUS: Why Your Agile Transformation Keeps Snapping Back — And What Systems Thinking Says About It Natalia Curusi co-authored a book that doesn't tell you what agile should look like — it tells you what actually happens when you try to transform an organization. Friday-night deployments, zombie teams going through the motions, transformations that met a wall of silence. In this episode, we unpack the real lessons from the front lines: how personal values drive the shift to agile, why some teams have all the ceremonies but none of the substance, and what systems thinking reveals about why transformations fail — or snap back. When Your Values Don't Match Your Ways of Working "I felt like there is a mismatch in my values, my moral values and principles, and customer-centric orientation. So when I found out about Agile around 2010, I understood — okay, this is the answer. Now I have the answer how I can map my moral values and principles with software delivery."   Natalia's journey to agile didn't start with a methodology — it started with a gut feeling that something was wrong. Working in large corporations in the early 2000s with fixed-scope contracts, late deployments, and scripts running directly in production, she sensed a disconnect between how work was done and how it should be done. When she moved to a smaller company around 2010 and experienced transparency, collaboration, and the freedom to ask any question without fear, she realized this was the agile mindset — even before she knew the term. The key insight: agile isn't something you adopt, it's something that aligns with values you may already hold. That alignment between personal principles and ways of working is what makes the difference between going through the motions and genuinely transforming how a team operates. Don't Be an Agile Zombie "The first thing I observe — if I go to some of the ceremonies and I see that stand-up becomes like a status meeting, and everybody is reporting to somebody. People are afraid to say some of the things, afraid to escalate risks or assumptions."   One of the strongest chapters in the book is titled "Don't Be an Agile Zombie." Natalia describes teams that have all the boards, all the roles, all the right meeting cadences — but nothing is actually changing. The Scrum Master becomes a secretary. The Product Owner is a proxy afraid to make decisions. The tell-tale signs? Fear and formality. When people report upward instead of collaborating sideways, when risks go unspoken because the environment punishes transparency, that's a watermelon project — green on the outside, red on the inside. Natalia's approach starts with observing the tone and dynamics in ceremonies. If the stand-up feels like a status report and not a coordination meeting, something deeper is broken. And her advice is direct: if an organization is delivering waterfall and happy with the predictability and value, that's fine — just call it what it is. Don't put lipstick on a pig. As Rebecca Homkes discussed on this podcast, the key is to communicate the truth with care, but communicate it nonetheless. Task-Driven vs. Value-Driven: The Real Spectrum "It's not right to say that you are agile if you are not. Just name the things how they are — name the things using the right word."   Rather than the old waterfall-vs-agile binary, a more useful lens is the spectrum between task-driven and value-driven product development. On the task-driven side, somebody creates the list of tasks — requirements, architecture document, design document — and a project manager distributes them. Teams execute but aren't asked to be creative or adaptable. On the value-driven side, what matters is the impact of what teams build. Value is discovered through the dynamic interaction of functionality with customers — it can't be predetermined. Most organizations sit somewhere on this spectrum, and many are slowly moving toward the value-driven end even if they don't call it agile. The practical takeaway: transformation should be tailored to where an organization actually is, not where a framework says it should be. The book argues for a pragmatic, hybrid approach rather than evangelical purity. Systems Thinking: Why Transformations Snap Back "We did a big agile transformation — five years of real transformation. Then the company was bought, merged with a bigger payment provider. And now they are working with SAFe. And that's the end of the story."   In the later part of the book, Natalia and her co-author move into systems thinking — Cynefin, the Iceberg Model, causal loop diagrams. Many agile practitioners stop before they get here because it feels academic. But Natalia argues it's essential, and she illustrates why with a real example: a payment company that went through five years of successful agile transformation using LeSS, only to be acquired by a larger organization that pushed SAFe — and the transformation snapped back. This is the basin of attraction concept: a system has to pass through a point of genuine disruption before it can settle into a new stable state. Without that, it returns to where it was. For practitioners looking to get started with systems thinking, Natalia recommends The Fifth Discipline by Peter Senge and learning to build causal loop diagrams — a practical tool that creates productive conversations about how organizational dynamics actually work. The Post-Agile Era: Beyond Labels "It's like comparing apples and orchestras. You cannot compare agile and AI — they are completely different things. Agile is not enough, but it's also not dead."   Natalia addresses the "Agile is dead" debate head-on. Her argument: comparing agile to AI is a category error. An apple cannot play an orchestra, and an orchestra cannot replace an apple — they serve entirely different purposes. AI can handle a significant portion of day-to-day tasks, but it lacks common sense, empathy, and the ability to read a room. Rather than declaring agile dead, Natalia sees a post-agile era — not one where agile disappears, but where we move beyond the label wars. The trends that matter aren't about whether agile is popular; they're about collaboration, adaptability, and understanding how teams and organizations actually work. We can finally talk about what matters in our industry without being pressured to label it. About Natalia Curusi Natalia Curusi is an Agile Coach at Endava with over 20 years in software delivery, specializing in agile transformations, delivery optimization, and systems thinking. She leads Asia Pacific initiatives driving business agility. She is co-author of From Resistance to Resilience: Practical Agile Lessons for Transformation.   You can link with Natalia Curusi on LinkedIn and visit her website at nataliacurusi.com. You can also join the Agile Continuum community on LinkedIn.

Efe Gümüs: The People-Pleasing Product Owner and the PO Who Understood User Value — Two Sides of Product Ownership In this episode, we refer to the SPIDR slicing method. The Great Product Owner: The PO Who Understood User Value Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If your product owner can phrase what the user wants to do — not what the button should look like — it is going to be a night and day difference." - Efe Gümüs   Efe describes the great product owner as someone who creates focus and a clear product vision, so the team knows what they're building and why. The foundation is simple but powerful: describe what the user will be able to do, not what the interface should look like. Instead of specifying a red subscribe button with exact text in three languages, say "as a user, I want to subscribe to my favorite channel." That shift unlocks the team's ability to contribute design insights, architecture decisions, and user journey thinking — the kind of expertise no product owner could anticipate alone. Efe highlights the SPIDR slicing method as one of his favorite tools for breaking product backlog items into consumable pieces — by interface (iOS, Android, web), by data, by rules. When the PO frames work around user value and slices it effectively, the team delivers visible value in iterations, and sprint goals become meaningful. Without this, the team becomes a ticket delivery machine.   Self-reflection Question: When you look at your product backlog right now, are items described in terms of what users can do — or in terms of what the interface should look like? The Bad Product Owner: The People-Pleasing PO Who Says Yes to Everything Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If you are doing everything your customer says, then you are not managing your product. That's the foundation." - Efe Gümüs   Efe names people-pleasing as the worst product owner anti-pattern — the "customer is always right" mentality applied to product management. When a PO says yes to every request, the consequences cascade quickly: multiple priorities competing simultaneously, everything marked urgent, no meaningful sprint goal, constant context switching, and new items injected mid-sprint. The team loses focus entirely. Efe has seen this in startups where the CEO walks in with urgent customer requests, and in larger organizations where multiple customers each demand customizations. In both cases, the PO becomes a pass-through instead of a decision-maker. The customer might be happy today, but will they be satisfied in six months when nothing is coherent? As Vasco notes, when you're serving multiple customers and saying yes to one, you're saying no to all the others — you just haven't told them yet. The result is chaos: steering blindfolded without navigational tools, trying to go everywhere at the same time. A product owner's most important skill is coherent, aligned decision-making — and that means learning to say no.   Self-reflection Question: How often does your product owner say no to stakeholder requests — and when they do say yes, is it because the request aligns with the product vision or because they want to avoid conflict?   [The Scrum Master Toolbox Podcast Recommends]

Efe Gümüs: Success as a Scrum Master Means People Feel Safe Enough to Speak Up Before It's Too Late 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 healthier your collaboration with other roles — developers, product owners, managers — the more successful as a Scrum Master you are." - Efe Gümüs   Efe defines Scrum Master success not through team velocity or timely deliveries, but through the health of relationships. A successful Scrum Master actively contributes to organizational matters, increases transparency on both problems and solutions, and bridges the gap between roles. At the team level, the signal is clear: if people feel safe enough to approach you with their problems, if they speak freely in team events without fear of blame, if they can raise risks before the last day of the sprint — that's success. But Efe is honest about how hard this is to maintain. Relationships with stakeholders have constant ups and downs, and the work of understanding people never stops. His advice starts with empathy — not just reading the room in the moment, but understanding that every colleague carries a different career history, different coping mechanisms, and different experiences that shape how they react to change. For younger Scrum Masters especially, Efe emphasizes that what worked for you won't work for everyone. Speak the common language, understand their perspective, give them assurance through visible, outcome-focused progress. The health of those relationships is the measure of your impact.   Self-reflection Question: Beyond metrics and deliverables, how would you describe the health of your relationship with the key stakeholders around your team — and what's one thing you could do this week to strengthen the weakest one? Featured Retrospective Format for the Week: The Diamond Retrospective "When you have diverse perspectives, a growth zone, converged thinking, and then action points — that diamond — people actually own the actions." - Efe Gümüs   Efe doesn't name a single retrospective format as his favorite — instead, he describes the structure that makes any retrospective effective: the diamond. Start by opening up diverse perspectives (diverge), create space for exploration and growth (the growth zone), then converge the thinking toward clear action points. This diamond pattern — diverge, explore, converge, act — ensures that the team moves from broad reflection to specific, owned commitments. The key word is "owned": when people arrive at actions through this structured exploration rather than being told what to improve, they commit to the follow-through. Efe connects this directly to his broader philosophy: the best systems don't depend on any single person, and the best retrospectives produce actions that the team drives forward without needing the Scrum Master to push.   [The Scrum Master Toolbox Podcast Recommends]

Most Agile coaches build their careers inside large organizations — but what happens when a new opportunity calls from an unexpected direction? Scrum.org CEO, Dave West, sits down with Marina Alex, an AI & modern management expert and Founder of The SWAY Academy, who answered that call. After the enterprise market shifted in 2022, Marina pivoted her practice toward small and medium-sized businesses in Knoxville, Tennessee — and discovered what she describes as a blue ocean: many companies that have never heard of a Sprint, but are ready for one.Along the way, Marina found that AI has become a natural entry point into these conversations. With most small businesses neither tech-heavy nor equipped with an IT department, the excitement and anxiety around AI opens the door to deeper work around team culture, structure, and customer focus. Rather than leading with frameworks, she leads with outcomes — helping business owners understand that strong teams and clear processes are what make any new technology actually stick.Marina walks Dave through the mindset shifts, networking strategies, and practical adaptations — from one-week Sprints to sticky-note Retrospectives — that have allowed her to build a thriving practice doing work she loves, serving the local business communities that need her most.Free Guide from Sway Systems with tips to find new clientsConnect with Marina

Efe Gümüs: Why Enforcing a Framework on Your Organization Will Never Be a Real Agile Transformation 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.   "Honor the wisdom of the group — they are more wise than any management, than any agile coach, because they are in the whole process themselves." - Efe Gümüs   Efe brings a challenge he's seen repeated across every company he's worked with: transformation itself. Organizations adopt the Spotify model or launch Agile DevOps transformations expecting that applying a structure will produce results. But as Efe puts it, bringing developers and operations together does not make DevOps for you. The real question most organizations skip is: what makes sense for our business, our products, our clients, our architecture? The transformation that works is the one you co-create with the people doing the work, not the one imposed from above. Efe points out that traditional management needs numbers and progress reports — and when transformations can't deliver those in familiar formats, managers feel uneasy. His approach: include managers in the transformation activities so they see the small gears of execution firsthand. When they experience the complexity directly, they stop expecting a webinar to change behavior. The key insight is the difference between telling people and people realizing it themselves — self-discovery always generates higher buy-in than directives. Set the direction, let people own the path, and build a system that functions without single-person dependencies.   In this episode, we refer to the Spotify model.   Self-reflection Question: In the last transformation you were part of, was it designed as something done with the organization or to the organization — and what would you change if you could do it again?   [The Scrum Master Toolbox Podcast Recommends]

The Evolving Role Of The Agile Coach Being an Agile Coach is no longer about staying buried in frameworks or cheerleading teams. It's about getting out of the team room, talking to the business, and understanding what people are measured on, what they fear, and what they need to move faster and create value. Why It Matters When we build regular conversations with the business, we stay closer to real priorities, spot changes sooner, and become more useful to the organization. You also make your value visible, which matters when most people still don't fully understand what an Agile Coach does. What To Do Now See your job as helping connect technology to outcomes that show up in the business, not just in process metrics. That means networking, asking better questions, joining strategy discussions, and looking for low-risk experiments that improve speed, revenue, or customer results. In a world where technology is no longer the bottleneck, the Agile Coach who stays curious, visible, and aligned with the business is the one who stays relevant. If You Liked This Epsiode you may also like: Episode 231 – What A Great Coach Does Outcomes, Not Outputs – How To Resurrect Agile FORGE GENESIS IS HEREAll the skills you need to stop relying on job postings and start enjoying the freedom of an Agile career on YOUR terms. Next cohort starts in Q2 2026https://learning.fusechamber.com/forge-genesis THE ALL NEW FORGE LIGHTNING12 Weeks to elite leadership!https://learning.fusechamber.com/forge-lightning JOIN MY BETA COMMUNITY FOR AGILE ENTREPRENEURS AND INTRAPRENEURSThe latest wave in professional Agile careers. Get the support you need to Forge Your Freedom! Join for FREE here:https://learning.fusechamber.com/offers/Sa3udEgz GET THE BUSINESS OUTCOMES PARTNER PLAYBOOKLearn how to deliver undeniable ROI that saves your job and accelerates your futurehttps://learning.fusechamber.com/outcomes-partner-playbook CHECK OUT ALL MY PRODUCTS AND SERVICES HERE:https://learning.fusechamber.com ELEVATE YOUR PROFESSIONAL STORYTELLING – Now Live!The most coveted communications skill – now at your fingertips!https://learning.fusechamber.com/storytelling JOIN THE FORGE*New cohorts for Fall 2025!  Email for more information:contact@badassagile.com We’re also on YouTube! Follow the podcast, enjoy some panel/guest commentary, and get some quick tips and guidance from me:https://www.youtube.com/c/BadassAgile Follow The LinkedIn Page:https://www.linkedin.com/showcase/badass-agile Our mission is to create an elite tribe of leaders who focus on who they need to become in order to lead and inspire, and to be the best agile podcast and resource for effective mindset and leadership game. Contact us (contact@badassagile.com) for elite-level performance and agile coaching, speaking engagements, team-level and executive mindset/agile training, and licensing options for modern, high-impact, bite-sized learning and educational content.

Efe Gümüs: When Daily Stand-ups Become Status Updates — The Warning Signs of a Team Falling 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: http://bit.ly/SMTP_ShowNotes.   "When people start creating their own bubble inside the team, it's because they either don't feel safe, or they don't feel relevant to what the rest of the team is doing." - Efe Gümüs   Efe shares the story of an integration team — back-end and front-end developers working across legacy components, a monolithic environment, and a microservices transformation all at once. With so many different workstreams, team members ended up with their own individual projects. The daily stand-up became a status update: people shared what they were doing, but nobody was listening because nobody else's work affected them. The daily grew from 15 minutes to 30, sometimes an hour, morphing into an unplanned refinement session. Participation dropped — some stopped showing up, others attended but went silent. The team that had once been interactive and collaborative splintered into silos. Informal conversations disappeared entirely, and that was when Efe knew it was too late to make small fixes. Without trust, without a common goal, they were no longer a team — just a group of people sitting together. Then COVID hit, and remote work removed the last chance for accidental collaboration. The daily meeting, Efe realized, is your best radar for team health: pay attention to the energy, the interaction, the engagement — and you'll see the deeper dynamics before they become irreversible.   Self-reflection Question: How engaged is your team during the daily stand-up right now — and does the level of interaction tell you something about how connected they feel to each other's work? Featured Book of the Week: Psycho-Cybernetics by Maxwell Maltz "The book is all about building success mechanisms inside your own mind. If you can set your life goal, then it's way easier for you to set your career goal, your team goal, your sprint goal." - Efe Gümüs   Efe's most influential book isn't about Agile at all — it's Psycho-Cybernetics by Maxwell Maltz, a psychology book about building success mechanisms in your mind. Recommended by a fellow agile coach, the book helped Efe see the parallels between personal goal-setting and the iterative progress at the heart of Scrum. When you feel lost or stagnating, the exercises in the book help you create small pieces of progress — not quick wins, but genuine forward movement that builds momentum. Efe connects this directly to Agile: every event, every sprint, every review is a small achievement toward the next one. If you can set a clear life goal, setting a sprint goal becomes natural. The clarity of purpose unlocks action — and that's as true for individuals as it is for teams.   [The Scrum Master Toolbox Podcast Recommends]

Efe Gümüs: The Hidden Cost of Splitting the Scrum Master Role — And Why Stance Changes Make or Break Your Impact Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The biggest problem when I reflect on it now is the stance changes, because as Scrum Masters, we have to establish our impartiality when we are facilitating and when we are coaching." - Efe Gümüs   Efe started his career as a network operation automation engineer, fresh out of an electrical and electronics engineering degree. When his manager asked him to take on a part-time Scrum Master role alongside his developer duties, the challenge of switching between those two stances became immediately real. As a developer, your mind focuses on solving problems. As a Scrum Master, your job is to help teams own the solution — not solve it yourself. That split led Efe to a bigger realization about scope and boundaries. When he stepped too far into the Scrum Master role, he created an unintended authority dynamic. When he stepped too far back, he became invisible. The turning point came when he stopped an alignment call that wasn't working — the information was flowing one way, and the Scrum Masters didn't feel like peers. By naming the problem and co-creating the session format, he found the middle ground: describe your expectations, get agreement, and let people tell you where they need help. One small action from you can move a problem forward in two or three steps — but only if you know about it.   Self-reflection Question: When was the last time you paused a meeting that wasn't working and explicitly renegotiated how the group would interact — and what held you back from doing it sooner?   [The Scrum Master Toolbox Podcast Recommends]

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

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

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

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: http://bit.ly/SMTP_ShowNotes.   "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 Team Topologies 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 Never Split the Difference 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]  

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

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 LinkedIn. [The Scrum Master Toolbox Podcast Recommends]

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 Agile Team Maturity Index — 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]

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 Eisenhower matrix 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]

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 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]

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]

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 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 self-awareness and servant leadership 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]

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

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

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

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