Podcast appearances and mentions of will angela

Havva Sevay: AI vs. Real People—Helping Teams Avoid Information Overload 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 still a tool. It can make mistakes, it can hallucinate. People don't really question it—and that's the danger." - Havva Sevay   This week's coaching conversation tackles a challenge Havva—and many Scrum Masters—are living right now: AI vs. real people. For some, AI is a useful tool; for others, it's a magic oracle that solves everything and makes people replaceable. Havva sees the real risk in teams that accept AI's confident answers without double-checking, and in leaders who use AI to generate massive documents and dump them on teams as finished decisions. Vasco pushes the conversation into the practical: when a flood of AI-generated information, requirements, and tool changes lands on a busy team, how do you help them cope? Havva's answer is to step back and ask the human questions first—what is the epic? what does the stakeholder actually want? what do we really need right now? Then she pulls out a deliberately low-tech move: forget AI for one second. Her team uses the Eisenhower matrix manually to separate what's important now from what can wait. AI is a great tool—but the filtering of what matters is still human work.   Self-reflection Question: When AI floods your team with information and options, what is your practice for helping them separate what matters now from the noise?   [The Scrum Master Toolbox Podcast Recommends]

Havva Sevay: The Car Configuration Team That Spiraled Into Silence—and the Workshop That Saved 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.   "First they tell you their opinion. Then they start shouting, getting emotional. And the third one is silence—and resignation. That's the worst part." - Havva Sevay   Havva remembers a highly motivated development team working on a car configuration system so complex it began to wear them down. They asked for training. The Product Owner waved it off—they've had enough training, they should understand it. What followed was a three-stage spiral Havva now recognizes anywhere: first the team shares opinions and solutions, then frustration turns to emotion and shouting, and finally comes silence and resignation. The team even kicked the Product Owner out of their daily—a low point Havva calls the worst she has seen in her career. The turning point was a LEGO Serious Play workshop. By getting both sides to build how they wanted to work together, the Product Owner did active listening for the first time, recognized the team needed an experienced developer to guide them, and the relationship transformed. The lesson: Scrum Masters are the facilitators of those moments of coming together—and there need to be many, at every level.   Self-reflection Question: Is a team you support moving through opinion → emotion → silence right now? What moment of coming-together could you facilitate before they reach resignation?   [The Scrum Master Toolbox Podcast Recommends]

Havva Sevay: When Doing Your Best Isn't Enough—The Scrum Master Lesson That Changed 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.   "I didn't really acknowledge that the team is important, or what a team needs. I thought I was only focusing on getting the job done." - Havva Sevay   When Havva took her first Scrum Master job, she knew the framework cold and she was highly motivated. So she did exactly what the framework told her to do—and failed. Frustrated, she kept asking herself the same question: why did I fail? I really did my best. The turning point came from a mentor who asked her something she hadn't considered: did you ever think about what the team needed? In this episode, Havva walks us through the slow, honest work of realizing she had been judging instead of listening, pushing instead of stepping back. Her mentor introduced her to active listening—writing down what people actually said, not her interpretation of it—and to the discipline of silence. Becoming a better Scrum Master, she learned, is an everyday process that takes its time. We also explore how she stayed grounded: taking courses outside her bubble, networking, and learning from other people's experience.   Self-reflection Question: When you face a team problem, are you observing what is actually happening, or are you already judging and rushing to the next step?   [The Scrum Master Toolbox Podcast Recommends]

Danil Chernyshev: The MIA Product Owner vs. The One Who Owned the Outcome 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: Communicating Value, Inviting the Right People 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 basic Scrum—but it's not basic." - Danil Chernyshev   The best Product Owner Danil ever worked with was Jamie Spence, on a Master Data Management re-architecture at Canadian Tire. The goal wasn't only to upgrade a system—it was to rethink how a major retailer with many different banners should work across all of them. Jamie didn't write user stories; the BAs did that. What he did was communicate, in a super-clear way, the value expected at every step. He didn't attend every daily Scrum, but he was there whenever the team wanted him, allocating his time on demand. He cared about user experience and lived for the feedback loop—"this sprint I want to deliver this part and see how it goes." And he invited the proper stakeholders to each sprint review: a small, deliberately varied group chosen by what had been delivered and whose feedback the team actually needed. As Danil and Vasco agree, it sounds obvious—and that's exactly why it's worth celebrating. Obvious and common are not the same thing.   Self-reflection Question: Does your Product Owner communicate expected value at every step—or just hand over user stories and disappear? The Bad Product Owner: Present on Paper, Missing in Action 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.   "On paper, you have a Product Owner. But you don't have a Product Owner." - Danil Chernyshev   The most common—and worst—anti-pattern Danil sees is the MIA, or "missing in action," Product Owner: a person with the title who doesn't actually own the product. Sometimes it's a BA or a tech lead wearing the label; sometimes it's someone who simply can't make decisions, or doesn't understand what they're responsible for because they're busy doing another job. The fix starts with clarity: first understand what the product even is, then put in place a Product Owner who makes decisions, owns the end-user experience, and maximizes value. Danil also flags a structural trap—one Product Owner per product, not one per team. He stretches the idea with vivid examples: an Agile coach leading a transformation is effectively the Product Owner of the process, with Scrum Masters as the developers; and Steve Jobs was the Product Owner of the iPhone while also being a customer for other Product Owners building pieces of it. Ownership is about maximizing value for the customer—not about who writes the user stories.   In this segment, we refer to the great Product Owner pattern Danil shares above, and how the Scrum Master's job is to help the Product Owner grow into real ownership.   Self-reflection Question: Is your Product Owner empowered to make decisions and own outcomes—or just a title on an org chart?   [The Scrum Master Toolbox Podcast Recommends]

Danil Chernyshev: Success Is Synergy—When the Team and the Product Both Win Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Success is when team members say thank you, and praise others for delivering a successful product." - Danil Chernyshev   For Danil, success as a Scrum Master is never one thing—it's a combination. It's the moment team members thank each other and credit the whole group for a product that actually landed with customers. As he reminds us, Scrum Masters, Product Owners, and developers are all there for the same reason: to deliver a product and solve real problems for the end user. A healthy team that has fun together but ships nothing has only spent time and money. A team that delivers but burns everyone out, until no one wants to see each other again, isn't a success either. Real success is the synergy of both: a productive team, happy customers and stakeholders, and people who still have the energy to keep going. Danil also turns the lens inward—success means understanding where you are in your own journey. And it grows from action: when teams get stuck overthinking, he guides them back to what's inside their control, helps them find the smallest valuable step, and gets them experimenting. Start where you are, do what you can, then learn from it.   Self-reflection Question: Are you optimizing for a happy team, a delivered product, or the synergy of both—and how would you know the difference? Featured Retrospective Format for the Week: Lean Coffee (paired with 1-2-4-All and 5 Whys) Danil doesn't lock himself into a single retrospective format—he chooses based on the sprint, guided by "common sense in Scrum." His default is to keep a running list of topics gathered throughout the sprint, then open the retrospective with a Lean Coffee session to democratically decide what to discuss. From there, a light topic gets a quick Lean Coffee conversation, while a deeper one moves into 1-2-4-All from Liberating Structures or a 5 Whys. The non-negotiable for Danil: every retrospective must end with actionable action items. A retro that produces only conversation and no change, he says, was a waste of time—maybe fun, but still a missed opportunity to reflect, learn, and adapt.   [The Scrum Master Toolbox Podcast Recommends]

Danil Chernyshev: Coaching the Outsider In—Helping a Distrustful Team Through 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.   "Developers and QAs know each other very well, but they don't trust anybody else." - Danil Chernyshev   This week's coaching conversation starts with a hard situation. A subcontractor's developers—people who had always worked isolated from the business, with no plans and no communication—were brought back inside the "mother firm" as part of a digital transformation. Overnight they faced new teams, Scrum, SDLC, CI/CD, and full transparency. The developers and QAs trusted each other completely and trusted no one else: not the Scrum Master, not the Product Owner, not the BAs. Forced to estimate with story points, every story came back as a 3 or a 5, with no conversation. When Danil asked why, the answer was always "we'll discuss internally and tell you tomorrow"—he suspected a second, hidden daily Scrum without him. As he and Vasco unpack it, the real issue is transparency itself: a team used to hiding now feels exposed and doesn't know the consequences of being open. Vasco offers an experiment—build a "trio" of the Product Owner, the Scrum Master, and one friendly insider from the team to prepare refinements together. The Product Owner is always the outsider; pairing them with a trusted insider lets ideas and experiments spread faster. Before you can improve the Scrum, you first have to bring the outsiders in.   Self-reflection Question: Where on your team is trust the real bottleneck—and who is the "insider" who could help an outsider earn it?   [The Scrum Master Toolbox Podcast Recommends]

Danil Chernyshev: Why Teams Always Adapt—And How Bad Rules Push Them Into Zombie Scrum Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Teams always adapt. You only get to decide what they adapt to." - Danil Chernyshev   Most dysfunction doesn't start with the team—it starts with the structure around them. Danil shares the story of a classic metrics-driven organization where Scrum Masters reported to a dedicated manager who measured their success by team velocity. That manager tracked retrospectives in a separate log, and would show up at the daily Scrum to confirm everyone answered the three questions. The result was predictable: the retrospective became a clock to survive, the daily became a checkbox with no real conversation, and velocity turned into theater—stories closed as "done," then reopened as "part two" in the next sprint. There was never a real done increment. Danil refuses to blame the team. They were doing exactly what teams always do—adapting to survive the rules and boundaries handed to them. As he and Vasco explore, the only real choice a leader has is not whether a team adapts, but what they adapt to. Dictate bureaucracy, and they'll adapt to surviving it. That's how productive, enjoyable work quietly turns into zombie Scrum. Servant leadership exists precisely so someone helps the team adapt toward value—not toward compliance.   In this segment, we talk about User Story Mapping by Jeff Patton and Peter Economy, and you can hear Jeff Patton on the podcast.   Self-reflection Question: Look at a behavior on your team you find frustrating—what rule or structure might that team be adapting to in order to survive? Featured Book of the Week: Actionable Agile Metrics for Predictability by Daniel Vacanti Danil calls this book eye-opening. It changed how he thinks about metrics—not as a reporting tool for executives, but as something teams can use for themselves to understand what to do next and how to improve. As he puts it, "after that book, you will probably know that a lot of cumulative flow diagrams that you saw in your past, they doesn't work well, and need to be rebuilt." The book makes flow metrics serve the team first, while still giving leadership the transparency they need. You can also hear Daniel Vacanti on the podcast, and get the book here: Actionable Agile Metrics for Predictability by Daniel Vacanti.   [The Scrum Master Toolbox Podcast Recommends]

Danil Chernyshev: Forged in the Fire—Why the Scrum Master Role Tests Even Experienced Leaders 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.   "From my story, you can probably say that I was forged in the fire." - Danil Chernyshev   Danil had already climbed the ladder. He started with Scrum in 2010 as a developer, grew into a development manager, and reached executive level, running a department of 70 developers in his home country. Then he immigrated to Canada and had to start his career fresh. Certified by Scrum.org as both Scrum Master and Product Owner, the first role he landed was Scrum Master—and that's where the trouble began. He knew SDLC inside out, he knew how developers think, he knew Scrum from the trenches. What he didn't know was how to be a servant leader: how to balance serving and leading, how to measure his own success, how to even notice the small wins. After years at the top, he was suddenly the person who knew the least. In this episode, Danil shares why he stayed in the role instead of walking away—he loves building processes that help teams evolve, and he couldn't resist a real challenge. His advice to anyone at that same crossroads: be patient, reflect, build a feedback loop, and never stop learning. A certification proves you understand the base theory. Everything that matters comes after.   In this episode, we refer to the Tuckman model of team development, and how the storming phase tests every team—and every newcomer.   Self-reflection Question: When was the last time you were the person on the team who "knew the least"—and what did that teach you about your own growth?   [The Scrum Master Toolbox Podcast Recommends]

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]

Mirco Gerling: The Hydra Product Owner and the PO Who Made Trust Possible 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: Precision That Builds Team Trust 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 always had an answer, or if he didn't have the answer, he tried to ask the clients, the users, the stakeholders." - Mirco Gerling   In pharmaceutical software, the wrong dose can kill someone. So when Mirco worked with a PO in that domain, precision wasn't a virtue — it was a survival requirement. The PO wrote meticulous user stories in classic "As a user, I want… so that…" format with very good acceptance criteria. The developers always knew what done meant. And when, mid-sprint, the team spotted a gap — "Is 80% tolerance of 100% or 80% of all?" — the PO was there, asking the right people, refining or splitting the story, never letting ambiguity ship. Even when half the team was out sick in winter, the remaining developers could deliver because the user stories were clear enough to stand on their own. Stories linked to automated tests. Each acceptance criterion traceable to the test that proved it. The result: a team that trusted their PO. As Mirco puts it, that trust came from one thing — the PO had already done the work needed to help the team understand what to do and how they'd know it was done.   Self-reflection Question: What's the level of precision in your team's user stories signaling to your developers about how much you trust them — and how much you've prepared for them? The Bad Product Owner: The Hydra PO with Seven Heads 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 the developers had questions, the people said: 'it's not my ticket, it's not my story.'" - Mirco Gerling   Five Scrum teams. One Product Owner. Seven requirements engineers writing user stories alongside. Eight people doing the work of product ownership — and nobody owning any of it. Developers learned quickly that asking a question meant being bounced from one requirements engineer to another. "It's not my ticket." The eight-person PO group split into two sub-teams who, when they spoke about each other, used "you" and "they" instead of "we." Decisions made in week one collided with decisions made in week three. Mirco's intervention: treat the PO group like a Scrum team. Eight people is a team-sized group. Run retrospectives with them. Get them communicating as a unit instead of as parallel individuals. The one anchor that kept things from completely falling apart was the single PO at the top, who could still say "this feature we need at the end of the year, the other can wait." Without unified prioritization, the hydra has no direction — just seven heads pulling in seven ways.   Self-reflection Question: Where in your product organization are decision-makers proliferating without a shared mandate — and what's the cost in clarity for the teams downstream?   [The Scrum Master Toolbox Podcast Recommends]

Mirco Gerling: The Silence Test — How to Know Your Team Doesn't Need You Anymore 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.   "Don't talk too much. And only talk if it's necessary." - Mirco Gerling   For Mirco, success as a Scrum Master starts with a simple rule he had to fight for: don't try to be someone else. Early in his career, when people kept saying "Mirco, you decide, you're the Scrum Master," he had to do the hard work of pushing back — "no, we decide together." That instinct shapes his whole definition of success. Be authentic. Wait before you speak. Ask before you instruct. And when a discussion stalls, sit with the silence — because in most cases, someone in the team has a better idea than you do. The cleanest test of whether a team is truly self-managing? Disappear. When Mirco took two months of parental leave, his team kept running every Scrum event without him. That's the signal. If you stop sending the sprint review invite, stop preparing the retrospective, stop nudging — and the team picks it up because they own it — your work is showing.   Self-reflection Question: What's one thing you currently do for your team that you suspect they would do themselves if you simply stopped doing it? Featured Retrospective Format for the Week: 1-2-4-All from Liberating Structures Mirco's universal tool is Liberating Structures, and within that toolbox, 1-2-4-All is his go-to. The pitch: "involve everybody, especially in large groups. And there's nearly no preparation needed." His proof point — facilitating a retrospective for 60 people at the Agile by Nature bar camp in just 20 minutes. The format scales from a team of five to a room of sixty without changing its shape: one minute alone, two minutes in pairs, four minutes in small groups, then a share-back with the whole group. During a 30°C COVID summer in Hamburg, Mirco even ran retros walking outdoors with his team — station to station, down to the lake for ice cream, then back. "It was a very good and constructive retrospective." The lesson: the right structure makes you portable.   [The Scrum Master Toolbox Podcast Recommends]

Mirco Gerling: Two Teams, One Sprint Cadence — The Hidden Cost of Synchronization Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The teams need to understand the advantage of the synchronization — but will they?" - Mirco Gerling   Two of Mirco's teams just got merged into one — and the brand-new, fused team is now part of a 10+ team organization trying to move from loose-coupled chaos to a standard process. Different sprint lengths. Different estimation methods. Different ticketing tools. The plan: align everyone to 4-week sprints, hold a global planning week every three months, and synchronize start and end dates across all teams. Mirco voted for 2-week sprints. The majority went with 4. And then the side effects started. Sprint reviews stack up on the same days, making it impossible for Scrum Masters to facilitate them all. Teams synchronize on paper, but interact organically across the four weeks anyway, so the cadence advantage doesn't materialize. And the merged team itself? Pushed back through Tuckman's stages by the merge — the Tuckman model reminded Mirco that "adjourning" is real, and a high-performing team starts over when its membership changes. Mirco's experiment: let faster-moving teams run two 2-week sprints inside the 4-week window, keeping organizational sync while restoring their own learning rhythm.   Self-reflection Question: Where in your organization is process standardization being mistaken for actual alignment — and what would it cost you to separate the two?   [The Scrum Master Toolbox Podcast Recommends]

Mirco Gerling: The Supermarket Team That Self-Destructed Trying to Help Everyone 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 tried to help, and finally, it... it self-destructed the team." - Mirco Gerling   The team was the supermarket of the organization. Cloud systems, versioning, developer machines, hardware — if another team needed infrastructure, this team built it. And when other teams asked, the answer was always the same: "We will try, we will try." Mirco watched what happened next play out in slow motion. The team escalated their overload to management. Management responded the way management often responds — sent in temporary help. The reinforcements solved problems quickly and left. But every system they built became permanent maintenance work for the original team. The pile grew. The team shrank. People left for other teams, or left the organization entirely. The escalation that was supposed to save them became the signal that broke them. As Mirco puts it: running to the higher level "sends a signal that self-organization or self-management does not work." Sometimes the help is the harm.   In this segment, we refer to the dynamic of team self-organization and how it can break down under pressure.   Self-reflection Question: When your team is overwhelmed, what does the act of escalating tell management about your ability to self-manage — and is that the signal you want to send? Featured Book of the Week: The Kanban Maturity Model In this episode, Mirco also recommends two books that shaped his thinking on process and estimation. The first is #NoEstimates by Vasco Duarte, which inspired Mirco to drop story-point estimation in some teams and simply count completed tickets per sprint. The second is the Kanban Maturity Model — a book Mirco uses to run workshops where teams discover their current level of process maturity. "The highest level says that you have a standardized process, and the result is always the same for the same type of work," he explains. Most teams start at level zero, but that's the point: knowing where you stand is the precondition for knowing where to go next.   [The Scrum Master Toolbox Podcast Recommends]

Mirco Gerling: When the Scrum Guide Isn't the Rulebook — A Scrum Master's First Conflict with 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.   "I had to learn that the organization didn't know the Scrum Guide very exactly." - Mirco Gerling   In his first Scrum Master role — running hybrid as both developer and Scrum Master — Mirco walked in believing the Scrum Guide was the rulebook everyone played by. The team thought so too: they were self-managing now, so they would decide. Management hadn't read the same memo. When Mirco called time on a meeting, a manager said "It's my decision when the meeting is over." When Mirco asked the team if they were happy in a retrospective, the manager saw the flip chart afterward — and from that day on, Mirco started destroying anything from retrospectives that could attract attention. The conflict wasn't about Scrum. It was about who gets to decide what. Without an explicit conversation about the limits of self-management, the team and management each assumed authority the other thought was theirs. Mirco eventually found Management 3.0's Delegation Poker — a tool that makes those invisible boundaries visible and gives teams and managers a structured way to negotiate them. The lesson: raise the topic with management before the conflict, not after.   In this episode, we refer to the Delegation Poker practice from Management 3.0.   Self-reflection Question: Where in your team's work are the limits of self-management still unspoken — and what would change if you put them on the table this week?   [The Scrum Master Toolbox Podcast Recommends]

Aliu Adewale: The Over-Communicator vs. The Over-Ambitious—Two Patterns Every Scrum Master Should Recognize 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 Over-Communicator Who Negotiated Every Scope Change Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "This is a guy who over-communicates everything." - Aliu Adewale   The best Product Owner Aliu ever worked with did something simple that almost no PO does. Before each refinement, he'd pull up the Jira board, record himself walking through every user story, explaining acceptance criteria, talking through the end goal one ticket at a time—and post the video to the team a day or two ahead. This was before Loom existed. The result: refinement felt less like discovery and more like "walking it back"—the team arrived already prepared, with real questions, ready to engage. He still attended every refinement and never missed a comment in Jira. But the second skill Aliu names matters even more: negotiation. This PO never let scope creep into a sprint mid-stride without consulting the team first. "If we add these two requests from leadership, what's the impact? Do we need to take something out?" And if the team said no, he didn't force it. He went back to leadership and named the consequence: "If we add this, here's what happens. Are you okay with that?" Over-communication and negotiation—two skills that protect the team and the product at the same time.   Self-reflection Question: When was the last time your PO asked the team's permission before adding work mid-sprint? The Bad Product Owner: The Over-Ambitious PO Who Never Said No Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Every yes to something unimportant is a no to what matters." - Aliu Adewale   The Product Owner Aliu names as the anti-pattern is the over-ambitious PO—the one who never says no. Never to stakeholders, never to the business, never to a new feature request. He never considered the size of the team or the capacity of the team. He was blind to it. Underneath the behavior, Aliu sees a pattern: POs who want to keep their job by saying yes, stakeholders who keep asking because they think they have to, and a team on probation that doesn't feel safe pushing back. The damage compounds—more features delivered, less value per feature, and eventually the team itself starts to break. Aliu's framing is sharp: "More features don't equal more value. Sometimes more is just less." The job of the Scrum Master here is to coach the PO on when to say no, when to say yes, and how to recognize that on the phone in front of you right now, 90% of the features in that app you're staring at—you never use them. Built. Shipped. Ignored.   In this segment, we refer to Product Owner anti-patterns and the courage required to challenge stakeholder demands.   Self-reflection Question: Is your PO measuring success by features shipped, or by features used?   [The Scrum Master Toolbox Podcast Recommends]

Aliu Adewale: Success Is Living the Five Scrum Values—And Asking the Team If You Are Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Trust is the foundation of empowerment. When you trust your team, they will deliver beyond your expectation." - Aliu Adewale   For Aliu, success as a Scrum Master is concrete: the team is living the five Scrum values—commitment, focus, openness, respect, and courage—and the organization is getting real value from their work. Commitment shows up in how the team holds itself to a Sprint goal. Focus shows up in how they protect that goal from noise. Openness reduces conflict because nothing festers in the dark. Respect, Aliu reframes powerfully: respect for someone's background comes before respect for their skill set—because in a team where people come from different countries, religions, and skill sets, that's the foundation everything else sits on. And courage shows up when a team can tell a Product Owner or a stakeholder that no, this can't be done in this Sprint, and we need to talk about it. But the values alone aren't success—the test is whether the team is delivering value frequently to the organization. The way Aliu keeps himself honest is uncomfortable but simple: he sends a survey to his team and asks them to tell him how he's doing on communication, on risk mitigation, on empowering them to reach stakeholders directly. He starts the assessment cycle the moment he joins—asking the organization what success looks like in this role in the next three months—and he refuses to "get carried away" and stop asking.   Self-reflection Question: Have you ever sent your team a survey asking them to rate you—and acted on what they said? Featured Retrospective Format for the Week: Start, Stop, Continue Aliu's go-to retrospective is the classic Start, Stop, Continue. Three questions—What should we start doing? What should we stop doing? What should we continue doing?—and the team has the structure they need to pinpoint their own shortcomings and decide what to do about them. The reason it works so well, Aliu argues, is the psychological safety the simplicity creates. There's no jargon, no clever framework, no facilitator gimmick to hide behind. Experienced and self-organizing teams especially thrive with it because they can name what's not working without you having to call it out for them. As a Scrum Master, when your team starts pointing at their own gaps without your prompt, that's the moment you should applaud yourself—you coached them into the space where they can do it.   [The Scrum Master Toolbox Podcast Recommends]

Aliu Adewale: When Everything Is a "Must-Have," Nothing Is—Prioritization for Real-World Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Every yes to something unimportant is a no to what matters." - Aliu Adewale   Aliu's current challenge isn't from his day job—it's from a volunteer project for his local Parent-Teacher Association. The group wants to build a centralized app for school announcements, PTA updates, volunteer coordination, event reminders. The first meeting produced 250 ideas, all of them framed as must-haves, all of them needed before school resumes. The window: three months. Vasco names two traps that most Scrum Masters fall into. First, MoSCoW and similar frameworks aren't prioritization—they're categorization. The moment everything ends up in the "must" bucket, you're still stuck. Second, prioritizing a feature list assumes features are independent. They almost never are: a login blocks a dozen things downstream; front-end depends on back-end; dependencies decide the order more than desirability does. Aliu's experiment with the PTA group is a focusing constraint: stop asking "what do we need this year?" and start asking "what do we need in the first three months when school resumes?" The 50-item must-have list collapsed to five or six features. Vasco pushes it further with his own favorite question: "What's preventing us from releasing tomorrow?" That's the question that exposes what really matters—and it almost never returns a list of features.   Self-reflection Question: If your team had to release tomorrow, which of your "must-haves" would you actually need?   [The Scrum Master Toolbox Podcast Recommends]

Aliu Adewale: The Counterintuitive Fix—How Collapsing the Jira Board Sparked Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Collaboration is the foundation of a successful Scrum team." - Aliu Adewale   Aliu walked into a team where the daily standup was theater. Developers delivered their tickets and forgot about them. QA picked up "their" column. Front-end, back-end, senior architect, junior developer—everyone was a champion of their own silo. Nobody engaged during refinement. Nobody called anything out. The board had close to ten columns, one per specialty, and it was working exactly as designed: as a handoff system. Aliu's diagnosis is sharp—the foundation of the team's problem wasn't the people; it was the tool. The Jira board was visualizing silos and the team was living up to it. The fix was counterintuitive: he collapsed the board from nine columns to three—To Do, In Progress, Done. Once "In Progress" was the only place where work lived, nobody could hide. A QA needing to know when a ticket would be ready had to talk to the developer. A stakeholder asking for status meant everyone on the ticket had to communicate. The team had no choice but to collaborate. As Vasco frames it in the episode: by creating the smaller problem of "hiding status," Aliu solved the bigger problem of "no collaboration." Sometimes you have to make things a little worse so they can get much better.   In this segment, we refer to the Agile value individuals and interactions over processes and tools, and to the recognition that the tools we choose shape the behaviors we get.   Self-reflection Question: Is your Jira board designed to enable collaboration, or to enable handoffs? Featured Book of the Week: Surrounded by Idiots by Thomas Erikson For Aliu, the book that most inspired him as a Scrum Master is Surrounded by Idiots by Thomas Erikson—a book he discovered through a recommendation on this very podcast. The provocative title pulled him in; the content gave him something he could use every day. As a Scrum Master, you work with people from different backgrounds, different communication styles, different ways of seeing the world. The book maps four personality patterns and, as Aliu puts it, "it might not be a hundred over a hundred, but at least ninety over a hundred about personality and human relation." For someone already working on his emotional intelligence, it became a tool for understanding why a message that landed clearly with one team member completely missed another—and what to do about it.   [The Scrum Master Toolbox Podcast Recommends]

Aliu Adewale: The New Scrum Master Trap—Being In Everyone's Business to Look Busy Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Sometimes the best architecture and design comes from a self-organizing team." - Aliu Adewale   When Aliu first became a Scrum Master, he wanted to be everywhere. New to the role, new to the organization, with a new team relying on him to deliver, he scheduled extra check-ins, sat in on everything, and made sure his manager could see him working. The result wasn't visibility—it was suffocation. The team felt he was in their business, and the deliveries he was trying to protect got worse, not better. Aliu's wake-up call came from his coach, who told him a sentence he still carries: "Stepping back gives your team the space to take ownership and unlock their true potential." The hardest thing a new Scrum Master can do is let things roll on their own for a Sprint or two and adjust through the retrospective. But once Aliu did it, the team started self-organizing, owning their day-to-day, and delivering beyond his expectations. The lesson he names is Agile principle number 5: build projects around motivated individuals, give them the support they need, and trust them to get the job done. The deeper insight from Vasco in this episode: when we want to be in our team's business, it's usually because we don't trust ourselves to know enough—so we try to know everything.   In this episode, we refer to Turn the Ship Around! by David Marquet, which Vasco recommends for any Scrum Master learning to step back, and to the Agile Manifesto.   Self-reflection Question: What are you doing this week to "be visible" that the team would actually be better off without?   [The Scrum Master Toolbox Podcast Recommends]

Gunnar Fischer: From Staying in Your Line to The Connected Product Owner—Two Patterns Every Scrum Master Should Recognize The Great Product Owner: The Connected PO Who Makes Information Flow 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.   "This Product Owner didn't need to be the smartest person in the room, but everybody knew, okay, this is a really smart guy." - Gunnar Fischer   The best Product Owner Gunnar ever worked with was what he calls the connected PO. This person had a deep professional network—inside the company and with the customer—and could talk to anyone: a colleague, the client, a brand-new team member they were onboarding. They were socially sharp without being shallow. They could disagree clearly, even harshly, and then turn around and say, "now let's talk about something else," with kindness. When this PO said no, it was a no people respected; when they said yes, it was a yes people trusted, because everyone knew the PO could push back. The praise behind their back matched the praise in the room. They had a private life, too—not married to the job, which made them a more well-rounded human. But the specifically Product Owner skill Gunnar names is this: they could look at the product across different time horizons—what does it need to do in one month, three months, one year—and they kept juggling functionality, contracts, customer situation, and economic reality at the same time. Their technical background helped, but they understood the line: "It's not my job to be the technically most savvy guy, but I'm willing to share my knowledge with everybody." As Gunnar puts it, the difference between a subject matter expert and a Product Owner is that the Product Owner makes the information flow.   Self-reflection Question: Does your Product Owner make information flow across the team, the customer, and management—or are they hoarding context as the "expert"? The Bad Product Owner: The Stay-in-Your-Line, Accept-Your-Fate PO 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 manage the backlog, you do the customer calls, you write the user stories—but you were not involved in any of the bigger decisions." - Gunnar Fischer   The anti-pattern Gunnar sees most often isn't malice—it's resignation. Most Product Owners aren't given the access or the permissions they need to be successful, and so they accept their fate. They manage the backlog, take the customer calls, write the user stories, sometimes talk to management—but they aren't part of the bigger decisions: ROI on a feature, whether to build it at all, the product vision a year out. Management keeps those decisions to itself, and the accept-your-fate PO doesn't challenge that arrangement. They stay in their line. They don't push back when sales drops in an urgent request that ruins the plan. They don't challenge the developers when an estimate feels wrong. They become very protective of the things they can control—their privileges, their processes, the artifacts—and when the bad times come, they get thrown under the bus. Gunnar's diagnosis is direct: the role of a great PO is to have constructive, respectful disagreements at every level—with the client, with management, with the team—and to be okay disappointing people. "Once you see that people go down to the mechanics, then it's a really bad smell, I would say." Saying yes to everything doesn't make you safe; it makes you replaceable.   In this segment, we refer to Geoff Watts' Scrum Mastery and its line about the great Scrum Master being dispensable and wanted—a frame that applies to Product Owners just as well.   Self-reflection Question: Where in the past month did your Product Owner say "yes" when the right answer was a respectful "no, not yet"?   [The Scrum Master Toolbox Podcast Recommends]

Gunnar Fischer: Healthy Flow of Value in a Healthy Work Environment—The Ecosystem Definition of Success Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "A successful Scrum Master is healthy flow of value in a healthy work environment." - Gunnar Fischer   Gunnar's definition of success comes in one phrase that hides a lot of work: healthy flow of value in a healthy work environment. The work environment, he says, is an ecosystem—it doesn't have tigers, but it has plenty of layers and forces that can throw the balance off. You start at the team: are we reaching our goals most of the time? (If always, you might be playing too safe.) Then you move outward to the customer: who are we doing this work for, and are they succeeding? Then to the company: what's good for the customer might still be bad for the financials. And finally back to the individual: a team can be hitting its goals, the customer can be happy, the company can be making money, and a person on the team can still be quietly under-challenged and ready to leave. Gunnar measures the flow side with the four Kanban guide metrics—cycle time, throughput, work item age, and work in progress—but he keeps reminding himself that finishing isn't the same as getting feedback. Did the customer use what we built? He's been demotivated more than once by seeing a "very important" piece of work go untouched after delivery. And then there's the social side: the level of healthy, constructive disagreement, and reading the room when colleagues from a culture that doesn't say "no" go silent.   In this episode, we refer to Kanban flow metrics (cycle time, throughput, work item age, WIP) and the importance of treating the backlog as options, not promises.   Self-reflection Question: When was the last time you measured not whether the team finished something, but whether the customer actually used it? Featured Retrospective Format for the Week: What, So What, Now What? Gunnar's favorite retrospective format is What, So What, Now What?, one of the Liberating Structures (and free to read up on online). He used it after a tense production deployment that succeeded but left the team rattled. Instead of jumping to "we need to do exactly this," he forced the team to split their thinking: what are the facts we can describe, so what is our interpretation of those facts, and now what are the possible options going forward. Sounds simple. But the brain hates incomplete pictures—it auto-completes them with speculation. That instinct kept our ancestors alive when they couldn't see the full tiger behind the bushes; it ruins our reasoning at work. By making the team distinguish hard between fact and interpretation, the format produced three concrete ideas. Within three months, the team had implemented all three, and things improved. Gunnar's broader takeaway about retrospectives: don't run them right after the event ("get a coffee, step away from your desk for fifteen minutes"), don't wait two months either, and—above all—"people need to look like winners when they're going into a difficult retrospective." Then honor their time by following up. If nobody else does the follow-up, the Scrum Master has to be the reminder.   [The Scrum Master Toolbox Podcast Recommends]

Gunnar Fischer: Three Transformations at Once—How to Build Momentum When Everyone Is Exhausted 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're not only writing for the leadership—you're always writing for the gallery." - Gunnar Fischer   Gunnar brought a juicy challenge to Wednesday: his company is running three transformations in parallel, at three different levels, all at different stages and degrees of success. People are exhausted. The word "change" triggers an allergic reaction. And yet, in the same breath, those same people will tell you the organization needs to change. So how do you create momentum in a climate worn down by theater and abandoned initiatives, when the managers who launched them have moved on? Gunnar's first insight is that the human species is built for change—the problem isn't appetite, it's the feeling of not being heard. Even hinting "I think I know your situation, and I took a note from our last conversation" opens people up. Vasco pushes the analysis further: when three transformation teams each visit the same Scrum team with different topics, the team ends up spending all its time discussing transformation instead of doing the work. Gunnar's counter is simple math—be realistic that 90% of capacity is work and 10% is learning, plan accordingly, and start small with a single pilot team. He recalls one successful turnaround driven by a "wall of concerns" where leaders read out anonymous worries and answered them publicly. The response didn't need to be perfect; it just needed to exist. And the hidden lever, he says, is what Vasco calls "writing for the gallery"—when you ask a good question in a town hall, you're not really aiming at leadership; you're showing hundreds of colleagues "you're not the only one." That's where systemic change actually starts.   In this episode, we refer to Liberating Structures, which Gunnar uses heavily in his change work, and the importance of linking transformation work to bottom-line financials or capability metrics so it survives the next urgent customer request.   Self-reflection Question: In your current change initiative, what visible evidence do people have that leadership is actually listening—not just communicating?   [The Scrum Master Toolbox Podcast Recommends]

Gunnar Fischer: The Anti-Pattern Bingo Team—When Success Is a Zero-Sum Game 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.   "This was neither Scrum, nor a team. It was more like the anti-pattern bingo team." - Gunnar Fischer   When Gunnar took his first job abroad, he walked straight into what he calls the "anti-pattern bingo team"—a supposed Scrum team that was neither Scrum nor a team. The company was in trouble, the team had a bad reputation and was used as a punching bag, the manager-of-manager treated them like a stepchild, and the new manager didn't seem to know what he had signed up for. The team members themselves didn't really want to work together. The goals slipped. Decisions were made in back rooms, outside the official meetings. And underneath it all sat the most corrosive belief Gunnar names: that success is a zero-sum game—if you win, I lose. With that mindset, there is no team, just individuals defending turf. One pattern stuck with him so clearly he gave it a name: sandcastle planning. The team would finish a Sprint planning, agree on a goal, and the manager would walk in right after the meeting and overturn the whole thing with his own priorities. Over time, the team stopped putting effort into planning. Why build the castle if someone will trample it? Even worse, when an escalation finally surfaced, Gunnar—an immigrant—was told that as a German, he must be "very authoritarian." A label, served up as analysis. That was the moment he knew the team would never have safe disagreements, never reach the right level of challenge, never recover.   In this segment, we talk about scrum master anti-patterns, the corrosive effect of treating people as labels, and how the absence of an explicit reason for the team's existence makes everything else collapse.   Self-reflection Question: Does your team have a clear, explicit reason for existing—or are you just a group that shares a technology, a building, or a reporting line? Featured Book of the Week: Scrum Mastery (2nd Edition) by Geoff Watts For Gunnar, the book that shaped him most as a Scrum Master is Scrum Mastery (2nd Edition) by Geoff Watts—what he calls "the noble knight of Scrum books." He first read it just after a Scrum course and thought, "What should I even do with this kind of wisdom?" Years later he came back to it and understood. A few years after that, he became modest about it: these are truths, but it's about making them true—and watching for when they aren't. The book is full of phrases like "a good Scrum Master is indispensable; a great Scrum Master is dispensable and wanted." That last line captured it perfectly for him: success isn't being unneeded, it's being chosen. As Gunnar puts it: "In times when everybody is challenged and people are making fun of agile practitioners, this brings back all of the ideals of what a Scrum Master is really about." You can also listen to our previous episodes with Geoff Watts on the podcast.   [The Scrum Master Toolbox Podcast Recommends]

Gunnar Fischer: Accepting Not Being Accepted—The People-Pleasing Trap That Broke a Scrum Master Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I accepted not being accepted, and that was a big failure." - Gunnar Fischer   Gunnar's biggest failure wasn't a single bad decision—it was an attitude he carried into work for far too long. As an Agile coach and Scrum Master, he watched a new high-ranking manager arrive who didn't like the team, didn't respect them, never even officially introduced herself. And Gunnar did the worst possible thing: he played along. He did the people-pleasing dance without ever getting feedback, recognition, or even a basic conversation. He formed ideas as a team, did the work, asked for nothing back—and accepted that nobody looked at the work. In hindsight, the Scrum value of respect was the missing piece. "The members of a Scrum team respect each other to be capable, independent people, and are also respected as such by the others." Gunnar respected others. He did not demand that respect for himself. The wake-up came in Ecuador—swimming with sharks in the open sea, he realized he felt safer there than in his own office. So he updated his CV, took an internal switch, and finally stepped out of victim mode. His real insight is uncomfortable: if you read about something good—getting time for your own development, being heard, being respected—and you instinctively deflect it or make excuses for why you can't have it, that's a very clear indicator you've internalized being small.   In this episode, we refer to The Coach's Casebook by Geoff Watts, specifically the chapter on people-pleasing.   Self-reflection Question: When was the last time someone described a healthy professional environment to you, and you found yourself making excuses for why you couldn't have it?   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: The PO Who Doesn't Care vs the PO Who Always Has the Answer Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   In this episode, we refer to a recurring theme in past podcast episodes—the proxy product owner who can't make decisions because they're not theirs to make. The Great Product Owner: Always Available, Always Decisive, Always Has the Context 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.   "There was nothing you tell, any questions you have about a particular feature that this guy doesn't have an answer to. And that really moved the team so fast." - Olaitan Fashanu   The best PO Olaitan ever worked with was the mirror opposite of every anti-pattern he'd seen. Deeply involved in refinement. Took backlog management seriously. Always brought the context. Always available to the team. And—maybe most importantly—always ready to make a decision when devs surfaced trade-offs. The team could ask any question about any feature, and the answer was right there. Not "let me check," not "I'll get back to you," not "what do you think?"—a decision. That single quality, Olaitan says, was what moved the team faster than anything else. As a Scrum Master, when you see a great PO at work, you also see the amplifying waves of impact: motivation rises, quality rises, ownership grows. Olaitan's takeaway is sharp: the success of our job depends on how well the product owner does theirs.   Self-reflection Question: When was the last time your PO made a real-time decision that unblocked the team in a single conversation—and what's preventing that from being the norm? The Bad Product Owner: Doesn't Care About Impact, Can't Make Decisions 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 cares about delivery. We just need to release to the customer. That is something I don't like." - Olaitan Fashanu   Olaitan describes two anti-patterns wrapped into one bad-PO type. The first: the PO who doesn't care about the impact of their work on the team. Tickets dropped without context. No refinement. No problem framing. Just "ship by end of month." The data shows up in Jira if you're paying attention—patterns of churn, quality issues, customer complaints, slow market response. Beyond the numbers, the team loses motivation, frustration creeps in, and eventually you lose the team entirely. The second anti-pattern, layered on top: the PO who can't make decisions. Developers come back with two options and the trade-offs—and the PO can't pick one. Vasco connects it to the proxy PO pattern explored in past episodes—a PO whose decisions aren't actually theirs to make. The cost is the same either way: the team stalls, ownership erodes, and stakeholder conflict grows.   In this segment, we refer to the proxy PO anti-pattern explored in earlier episodes of the podcast.   Self-reflection Question: Is your PO unable to decide—or unable to be allowed to decide? The difference changes which conversation you need to have, and with whom.   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: I Love Data—Why Success for a Scrum Master Means Doing the Hard Measurement 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.   "You don't get better by not trying to be better." - Vasco Duarte (channeling Olaitan's own discipline)   For Olaitan, success as a Scrum Master comes down to two things—team effectiveness and team health—and he refuses to guess at either. Twice a year, in what he calls his winter and summer cycles, he runs a structured team health check survey to capture how confident people feel, whether they hold each other accountable, and whether psychological safety is real or theatrical. Between those checkpoints, he runs constant one-on-ones—and not just with developers. QAs, designers, the PO. Everyone gets the conversation. He pulls outside-in feedback from customers and partner teams too, because effectiveness measured only from the inside is fiction. "I love data. Maybe it's my background in mathematics. I love looking at patterns, comparing things." The work is real, the load is real—but for Olaitan, refusing to do it is the same as refusing to grow.   Self-reflection Question: If you had to prove to yourself today that your team is genuinely effective and healthy, what data would you actually have—and what would you only be guessing at? Featured Retrospective Format for the Week: Start / Stop / Continue (and a twist Vasco offers Olaitan) Olaitan's go-to is the simple Start / Stop / Continue format—the easiest way he's found to get even quiet developers to engage, especially at the start of a new iteration. Vasco offers him a twist mid-episode: what if you only used one of the three? When the team is overwhelmed, run a Stop-only retro. When a release just shipped and energy is high, run a Start-only retro. Breaking the format pattern creates a small spark of "wait, why is this different today?"—which is often exactly the energy a tired team needs. Olaitan also shares a second favorite: the Friction vs. Drivers (or Fuel) format—mapping what's slowing the team down on one side and what's actively energizing them on the other. The two sides of the same coin, made visible.   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: Three Teams, Three Backlogs, One Feature—Can You Make Them See Each Other? Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "How do we ensure that these teams actually work together to show the same data?" - Olaitan Fashanu   Olaitan brings a problem most Scrum Masters in scaled environments will recognize. Three teams. Three separate backlogs. One product, accessed across app, web, and support channels. Leadership made a top-down team topologies decision: split the work to move faster. Predictable result—each team optimizes for their own backlog, blind to what the others are building, sometimes shipping the same feature twice with different behaviors. The product owners know there's overlap. The teams love the idea of linking tickets across backlogs. They just won't maintain the habit. Olaitan and Vasco walk through experiments together: a sync between POs, joint refinement sessions, linking tickets, putting "this is also being built by Team B" notes at the top of stories. The deeper insight: the Scrum Master's job is to keep surfacing information until a habit forms. As Vasco's old lifting coach put it—you find the imbalance, you get rid of the imbalance, one by one. That's how you get stronger.   In this episode, we refer to team topologies and the practice of surfacing information across team boundaries.   Self-reflection Question: Where in your organization are teams unknowingly building the same thing twice—and what's the smallest experiment you could run this week to make that visible?   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: When the New PO Stops Refining—and the Team Starts Self-Destructing 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 we're actually doing the job of refining this ticket properly, then we will not be creating this tension in the team." - Olaitan Fashanu   The team was working well. They had a strong PO who came to refinement with the problem clearly framed: this is what we want to solve, here's the context, here's the user story, here are the acceptance criteria. The team picked it up, refined it, ran with it. Then change came. A new PO joined—and the routine collapsed. The new PO cared about one thing: hitting the delivery date. Tickets dropped into Jira with no context, no problem statement, no acceptance criteria. Just "this needs to ship by end of month." Within weeks, Olaitan saw the symptoms cascade through the team. Developers asked designers what tickets even meant. QA struggled to maintain quality. Tension built. The diagnosis was clear: refinement had broken. His fix? Bring back the Definition of Ready as a non-negotiable shared standard, and introduce a product trio—business viability, technical feasibility, and design usability collaborating on every story before it reaches the rest of the team.   In this segment, we talk about the Definition of Ready and the product trio collaboration model.   Self-reflection Question: What's the symptom you're seeing in your team right now—and could the real source be how stories are getting refined, not how they're getting built? Featured Book of the Week: The Secrets of Facilitation by Michael Wilkinson Olaitan calls out The Secrets of Facilitation by Michael Wilkinson as the book that shaped how he handles difficult moments. The book teaches the power of asking the right question at the right time—clarifying questions, probing questions, the questions that drive a stuck group forward. "You will understand how, when to ask clarifying questions, ask really powerful questions that will help you drive or probably help you reach your goal in any session you find yourself." For Olaitan, the biggest payoff was learning to manage group dynamics in real time—what to do when something said in a meeting lands badly, when a comment threatens to derail the room. As a Scrum Master, you live in those moments. This book hands you a toolkit for them.   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: The Scrum Master Who Tried to Force His Way In—and Got Schooled 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 you want to make things work, you need to find a way to carry people along. Lead, not by forcing your way on the team, because you're working with smart people, you're working with professionals." - Olaitan Fashanu   When Olaitan transitioned from project management into the Scrum Master role, he carried his old habits with him: enforce, push, drive. Then he walked into a team of senior developers. In one retrospective, a team member casually suggested that someone could help set up Jira properly. Olaitan took it personally—wasn't that his job? The next day in the daily standup, he called it out publicly. The reaction told him everything. The team member shut down. The PO pulled him aside afterward to say, "We could have had a better discussion around this." That moment, Olaitan realized that having no formal authority isn't a weakness to compensate for with force—it's the whole point. The job is to influence, to nudge, to coach—even when the conversations are hard. Especially when they are hard.   Self-reflection Question: When was the last time you raised a difficult topic in a way that closed the conversation instead of opening it—and what would it have cost you to bring it up differently?   [The Scrum Master Toolbox Podcast Recommends]

Aimé Flemm: Output Owners vs Activators — Two Product Owners Who Defined Aimé's Career Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   In this episode, Aimé reflects on two Product Owners — one who showed him what greatness looks like, and one who taught him the cost of structural malpractice. The contrast is structural as much as personal. The Great Product Owner: The PO As Activator "Our product owner was really able to persuade the larger group of 60 people and activate them." - Aimé Flemm   When Aimé's company moved to LeSS, they collapsed seven Product Owners down to four — and effectively one head PO who had to step up. "All of a sudden had this one product owner who needed to step up his game — to become this leader who's visionary, who has some kind of charisma." The structure forced the role to grow. The new PO had to lead 60 people, not five. And he did it. Not by writing more stories or shoving work harder, but by becoming an activator — visionary, charismatic, able to rally people behind a product direction. Aimé's framing: structure created the conditions for greatness. Reduce PO count, increase scope per PO, and the role has to step into real product leadership. "It doesn't happen too often that you get the opportunity to really have THE product owner in the company, and just the one."   Self-reflection Question: Does your structure give your PO room to be a leader — or does it force them to be a story-writer for one team? The Bad Product Owner: The Team-Manager-In-Disguise "What this product owner really did was just managing the team. He had the power to hire and fire, to decide on promotions, pay raises." - Aimé Flemm   Aimé's second PO ever was the opposite of an activator. He was a team manager in disguise — with full hire/fire authority and control over promotions and pay raises. He showed up about 15 minutes a week. "Just telling them, 'oh yeah, this is good, you should do this and do this,' and then he was gone for the rest of the week." What followed was textbook decay: an avoidant team, no initiative, refusing workshops and improvement work. "It became a collection of individuals, all on their own island. Just fixing their own work, just to make sure that they looked good." Aimé himself couldn't push back — his own job security ran through the same person. As Vasco named it in the conversation: these aren't product owners — they're output owners. Work-shovers. Proxies. The dynamic kills product value over time, because nobody is steering toward the customer.   Self-reflection Question: Is your PO an activator who rallies people behind a vision — or a proxy who shoves work from one inbox to another?   [The Scrum Master Toolbox Podcast Recommends]

Aimé Flemm: When The Team Tells You You're Doing Too Much — That's The Success Signal 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 when you know you're on the right track — when the teams start complaining that you're doing too much." - Aimé Flemm   Aimé got the feedback nobody wants to hear: "You're being too much in the front of the group." His first reaction was to take it personally. Then he saw it for what it was — the success signal. The team was telling him: let us do it. After months of helping them build self-managing capability, they hit a tipping point. They wanted the floor. He stepped back, started "actively doing nothing," sat down and crossed his arms. When they brought a problem, he asked: "What are you going to do about this? Have you tried that already?" But Aimé pushed back on himself in this conversation, and accepted the reframe: the Scrum Master isn't less needed at the tipping point — they're needed differently. The shift is from teaching and facilitating ceremonies to nudging with questions, helping the team reach out when they're stuck, surfacing issues with the PO and outside stakeholders. The focus shifts when you reach success. Don't take "you're doing too much" as offense — take it as your cue to change levels.   Self-reflection Question: When the team last pushed back on something you were doing, did you take it as feedback to defend — or as a signal that they're ready to take more ownership? Featured Retrospective Format for the Week: Retromat + Liberating Structures Aimé's favorite retro? "If I don't have to do it myself." Once teams reach the tipping point, he uses a pull system — they run their own retros, he checks in a few days later. But when he does facilitate, he layers two tools. First, Retromat — not just for the techniques, but for the flow: check-in, gather data, generate insights, decide what to do, checkout. Second, Liberating Structures on top of that flow. His favorite is Impromptu Networking — small groups answer a question, then re-form in different groups. "It's like a beehive. There's so much energy. It's bubbling." He's used it cross-org, his team and the client team in the same room. And his strong recommendation: do retrospectives on-site whenever you can.   [The Scrum Master Toolbox Podcast Recommends]

Aimé Flemm: Renting The Change vs Owning It — Why LeSS Transformations Get Reversed 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 rented the change instead of owning it." - Aimé Flemm   A year ago Aimé helped his Dutch employer adopt LeSS. The teams are happy. They're performing well. And now, he's watching it all get pulled apart. The company was acquired by a German parent that's "actually really German" — traditional, command-and-control. The parent wants to "align" all its companies and is pushing to revert the LeSS structure back to component teams. Why? Because higher management never went to the trainings. They never went through the change themselves. They signed off on it, but they didn't internalize it. And now the loud-but-few voices of the status quo are reaching upward, and management is panicking. That's what Aimé means by "renting the change" — you got the lease, you never bought the building, and the moment pressure rises, you walk away. His experiment for the next sprint, sharpened in this conversation: stop trying to defend the structure. Start a conversation with management to co-create success metrics for the merger itself. Decouple the structure from the definition of success. As long as the merger succeeds, the structure can stay fluid. Speak their language. And remember: coaching is the cherry on top — about 5% of the real gains. The big improvements live in the structural changes.   Self-reflection Question: When you sold your last change to upper management, did they buy it — or are they renting? And what's your plan for the moment when they want to give back the keys?   [The Scrum Master Toolbox Podcast Recommends]

Aimé Flemm: Culture Follows Structure — Why Some Teams Self-Destruct By Design 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.   "Culture follows structure. The destructive tendencies of a team are the consequence of how the organization is actually structured." - Aimé Flemm   Aimé doesn't blame teams when they go toxic. He looks at the org chart. At his first gig, the UX-only team grew bitter — making screens nobody used, blocked from talking to customers, drowning in dependencies. The team's behavior wasn't a coaching problem. It was a structural one. At his current company, building backend software for EV charging stations, he watched the opposite happen: leadership flipped seven component teams (backend, billing, etc.) into seven end-to-end feature teams with one Product Owner. Two-week sprints. Switching costs collapsed — they could decide on Wednesday to change direction, refine on Thursday, and have all seven teams pivot together by the next sprint. The org became truly adaptive. Aimé's question to every Scrum Master listening: is your organization fit for purpose? If the work is predictable and specialism-heavy, component teams can work. If you need adaptability, the structure has to match. Don't coach behavior that the structure forces.   In this segment, we talk about Larman's Laws of Organizational Behavior, the Star Model by Jay Galbraith, and Org Topologies.   Self-reflection Question: Look at the team you're coaching. Which of their "destructive habits" might actually be a rational response to the structure you've put them in? Featured Book of the Week: Large-Scale Scrum: More with LeSS by Bas Vodde and Craig Larman This week, Aimé recommends two books that complement each other. First — and his "holy bible" — is Large-Scale Scrum: More with LeSS by Bas Vodde and Craig Larman. "I remember reading this for the first time. It took me two weeks, the whole book. And I was just constantly texting people — 'this is it! It all makes sense now. I finally know what to do.'" For the how of organizational change — workshop ideas, possible structures, change tactics, and the people side — LeSS is the book. The companion book Aimé pairs with it is 10x Organization by Alexey Krevitsky, Roland Flemm, and Craig Larman — strong on the what and the why, with a 2x2 visual map that helps you explain to management where you are today, where the market needs you to be, and what should change. (You can also listen to our episode with Bas Vodde and our BONUS episode with Roland Flemm for a deeper view.)   [The Scrum Master Toolbox Podcast Recommends]

Aimé Flemm: Why Solo Scrum Masters Get Fired — The Coalition Of The Willing 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 doesn't make sense to try and change a system of 2,000 people on your own." - Aimé Flemm   Three months into his first gig out of consultancy, Aimé got the call: you're fired. He was at a Dutch pension fund — 2,000 people, deeply ingrained legacy structure — serving as Scrum Master to three component teams, including a UX-only team that couldn't ship anything end-to-end. Full of ambition and fresh ideas from a meetup, he pushed to restructure the teams to be cross-functional. His manager said "yeah, go for it." But Aimé was the only one pushing. He was, in his words, "poking and fighting the system way too much that they had built." So they didn't extend the contract. The lesson he carries from that firing reshaped how he approaches every change initiative since: do not try to do it alone. Find the coalition of the willing first — other Scrum Masters, other change agents, the volunteers — and build a network before you start pushing structural change. Use Scrum Master Syncs, communities of practice, even pizza budgets. Let the change spread like an oil spill. It takes time. It doesn't happen overnight. But you'll still have a job at the end of it.   In this episode, we refer to the coalition of the willing and change management tactics for Scrum Masters working in resistant systems.   Self-reflection Question: Where in your current organization are you trying to change the system alone — and who could become your first ally if you stopped pushing and started recruiting?   [The Scrum Master Toolbox Podcast Recommends]

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]

Njegos Ilic: The "Painting by Numbers" Scrum Master vs. The Quiet Leader Who Made the Team Self-Sufficient In this episode, we refer to the concepts of Scrum Master as facilitator and team empowerment. The Bad Scrum Master: The "Painting by Numbers" Approach That Leaves Product Owners Working Alone 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 basically feel totally alone because you are trying to deliver value as a team, but if nobody asks anything and nobody challenges anything, you end up defining everything yourself." - Njegos Ilic   Njegos describes the worst Scrum Master anti-pattern he's witnessed: the "painting by numbers" Scrum Master who runs every ceremony by the book — dailies, refinements, plannings, retros, reviews — but without understanding the purpose behind any of them. The meetings become a reporting cycle: "What did you do yesterday?" with no interaction, no challenging, no real engagement. From the product owner's perspective, this is devastating. Njegos describes feeling completely alone — trying to deliver value as a team while nobody engages, nobody asks questions, nobody pushes back on assumptions. The downstream effect is predictable: gaps that could have been caught early with a single conversation only surface during development or after deployment. Worse, the lack of engagement creates doubt and overthinking — the product owner starts over-defining requirements because there's no feedback loop, which reinforces the very passivity that caused the problem.   Self-reflection Question: Are the ceremonies on your team creating genuine engagement and learning — or have they become a reporting cycle that nobody actually needs? The Great Scrum Master: The Quiet, Impactful Leader Who Made the Team Self-Sufficient 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 best Scrum Masters I worked with were invisible — they knew always when to speak, they sensed the pulse of the team, and they weren't afraid to jump in when needed." - Njegos Ilic   The best Scrum Masters Njegos has worked with share a common trait: they were almost invisible. They didn't dominate meetings or insert themselves where they weren't needed. But they were always present — sensing the team's pulse, knowing when to step in, unafraid to say "we're out of time, let's take this offline." They were knowledgeable about the product, which earned them genuine respect from developers. And perhaps most powerfully, they delegated facilitation itself. Njegos shares an example where a Scrum Master introduced a round-robin system: when new developers joined the team, everyone took turns facilitating meetings — planning, retros, dailies. This wasn't just delegation for efficiency; it was empowerment by design. Team members who facilitated a retrospective suddenly understood how hard it is to lead one. That empathy changed how they participated when someone else was facilitating. The Scrum Master remained the guide, but the team grew its own capacity to self-organize.   Self-reflection Question: If your Scrum Master disappeared tomorrow, would your team know how to facilitate its own ceremonies — and if not, what does that say about how the role is being used?   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: Why Measuring Your Product Bets Is the Key to Product Owner Success Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If you cannot measure what you build, you will just be depending on who is screaming the loudest and using your gut feeling — which is not a good thing long term." - Njegos Ilic   Njegos defines product owner success through three pillars: the ability to measure product bets, deep knowledge of the industry and product, and the humility to admit mistakes and be challenged. The measurement piece is central — without it, he argues, you're flying blind, making decisions based on opinions rather than evidence, reacting to whoever screams loudest rather than what the data shows. But Njegos is honest that not every environment makes measurement easy. Some companies lack the tooling, the culture, or the historical infrastructure to set up proper analytics. In those situations, he turns to user interviews as the next best thing — getting direct feedback from users, even though he acknowledges that opinions are still limited without data to fact-check them against. His most powerful suggestion: invite the whole team to user interviews, not just the product trio. When developers hear directly from users, they connect to real-world problems, and conversations during refinements become richer and more grounded.   In this episode, we refer to The Mom Test by Rob Fitzpatrick and Shift: From Product to People by Michael Dougherty and Pete Oliver-Kruger.   Self-reflection Question: How do you currently measure whether the features you shipped actually delivered the value you expected — and if you can't measure it, what's your fallback? Featured Retrospective Format for the Week: Start With a Relaxing Exercise Njegos doesn't advocate for a specific retrospective template — and that's the point. From his product owner perspective, he values retrospectives that begin with a relaxing, informal exercise to set the tone. Not everything needs to feel like business as usual. This casual opening allows people to connect as humans first, which opens them up to think differently about what they learned during the sprint. Njegos is candid about the reality: some teams love icebreakers, while others find them childish and just want to get to the point. His advice is to sense the pulse of the team and adapt. The format matters less than whether it creates an environment where people can be honest about what went well, what didn't, and what to improve. A Scrum Master who reads the team's vibe and adjusts accordingly — that's what makes the difference.   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: How a Miro Board Experiment Changed the Way His Team Understood the Big Picture 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.   "Every feature is a product bet. I would call this a process bet — just try to see what works best for you." - Njegos Ilic   Njegos shares a change story from his time working with a tech lead who had previously been a Scrum Master — a partnership that made all the difference. Together, they introduced a simple but powerful change: visualizing the team's work on a Miro board instead of relying on a standard ticket board with cards and status columns. They mapped out concepts, connected ticket numbers to a visual representation of how different pieces of work fit together, and used this board during dailies and refinements to track progress in context. The change wasn't imposed top-down — Njegos and his tech lead simply said, "Give us one sprint to try this. If it doesn't work, we drop it." The result was immediate: dailies became more engaging, the team could see how their individual work connected to the bigger picture, and Njegos found it much easier to track progress as a visual thinker. His advice for Scrum Masters and product owners who want to introduce something similar is refreshingly simple — frame it as a "process bet," just like you'd frame a product bet. Try it, measure what happens, and if it doesn't work, drop it and try something else. The willingness to experiment with your own process is a prerequisite for experimenting with the product itself.   Self-reflection Question: What "process bet" has your team been avoiding — and what would it take to just try it for one sprint?   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: Why the Product Trio Breaks the Hand-Off Mentality That Kills Team Engagement 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 can't change people, but I can definitely involve them." - Njegos Ilic   Njegos describes a pattern he's encountered multiple times as a product owner: teams where engagement is almost nonexistent. He walks into a refinement session, presents ideas, asks for feedback — and gets crickets. Nobody pushes back, nobody asks questions, nobody challenges the assumptions. The result is a product owner working in isolation, defining everything alone, only to discover gaps during development that could have been caught early with a single conversation. Njegos is honest about the limits of what any one person can do — you can't change people's personalities, and expecting a Scrum Master to do so is unrealistic. But what you can do is involve people. His approach when joining a new team: don't come in announcing how things will work. Instead, learn how the team already works, meet them where they are, and then find ways to fit new concepts into their existing rhythm. For the non-negotiable things — the red lines — he's precise, open, and always provides an alternative rather than just pushing his way.   In this segment, we talk about Discovery and Delivery and the Product Trio concept.   Self-reflection Question: When you join a team meeting and get silence instead of feedback, do you assume agreement — or do you treat it as a signal that something deeper needs to change? Featured Book of the Week: Inspired by Marty Cagan Njegos recommends Inspired by Marty Cagan as the book that most shaped his approach to product ownership. He highlights the entire SVPG series — including Empowered and Transformed (available as the Product is Hard SVPG Box Set) — but points to the Product Trio concept as especially powerful. As Njegos puts it, the Product Trio — bringing together a product manager, a tech lead, and a designer — removes the hand-off mentality where each discipline works in isolation. Instead of the product owner defining everything alone and handing it to the team, the trio shapes problems together during discovery, so that by the time work reaches the team, there's shared understanding of why they're building something, not just what to build.   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: Why Saying Yes to Every Stakeholder Request Is the Fastest Way to Fail as a Product Owner Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The game is rigged because they are strong personalities, they want to get things done, but you don't have a magic stick — it's really hard to deliver results if you cannot say no." - Njegos Ilic   Njegos shares a failure from early in his career as a product owner in startup environments, where he found himself saying yes to every stakeholder request. Working with strong-willed founders who expected things done their way, Njegos fell into the trap of trying to please everyone — building everything that was asked without pushing back. The result was predictable: scattered priorities, no room to pivot, and a product backlog driven by the loudest voice in the room rather than real user needs. But Njegos frames this failure with a perspective that product owners at any stage can learn from. He compares the learning process to watching children learn to walk — stumbling and falling is not a sign of weakness, it's a necessary step in the process of growing. His advice to product owners currently stuck in this pattern: don't try to avoid failures too hard, because you might prevent yourself from learning the most important lessons. Instead, treat failure as a feedback loop — something happened, you can measure it, and you can change your approach. The key is doing the actual work of reflection: What did I do? What should have been different? What wasn't possible to change, and why?   Self-reflection Question: When was the last time you said yes to a stakeholder request even though your gut told you it wasn't the right call — and what would it take for you to say no next time?   [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]