Podcasts about scrum master toolbox podcast

Pankaj Kumar: Product Owners Who Prepare the Ground for Agile Teams The Great Product Owner: Proactive Preparation Before the Team Asks 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.   "Before the team asks, you know that this is the prerequisite for this user story." - Pankaj Kumar   Pankaj's example of a great Product Owner is someone who did the homework before meeting the team. This PO understood what the team needed to deliver, prepared the acceptance criteria, talked to UX early, and made sure design inputs were available before developers were blocked. Vasco describes this as "preparing the ground" for the team. The PO was not just pushing features into a sprint. He was listening to what the team could achieve, translating stakeholder needs into clearer work, and reducing waiting time so the team could focus on execution. For Scrum Masters, this is a useful pattern to notice: great Product Owners protect the team's flow by handling communication and dependency work early.   Self-reflection Question: What does your Product Owner prepare before the team discovers it needs help? The Bad Product Owner: Pushing Urgent Work Into an Already Full Sprint Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The team was already having everything on the plate, and they can't take any more." - Pankaj Kumar   The anti-pattern Pankaj highlights is a Product Owner who treats urgency as permission to ignore capacity. In one sprint, a PO arrived with an important customer case and insisted that it had to enter the current sprint backlog. The team was already overloaded, but the PO was not ready to hear the tradeoff. Pankaj's advice is to slow the conversation enough to make the real decision visible. Why is this urgent? Who is the stakeholder? What is the risk? What is the impact? Can it wait until the next sprint? If it cannot wait, what will be adjusted? Agile welcomes change, but change still has a cost. A Product Owner who says yes without making the tradeoff visible risks damaging trust with the team.   In this segment, we refer to root cause analysis, capacity planning, and Product Owner anti-patterns.   Self-reflection Question: When urgent work enters the sprint, what does your team explicitly remove or renegotiate?   [The Scrum Master Toolbox Podcast Recommends]

Pankaj Kumar: The Scrum Master Success Metric of Team Independence 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 thing to measure the success of a Scrum Master is that the team is not dependent on the Scrum Master." - Pankaj Kumar   For Pankaj, Scrum Master success has a clear test: can the team work, decide, inspect, and improve without depending on the Scrum Master for every step? He looks for self-organization, confidence in Scrum events, and a team that can continue improving without constant intervention. But he does not rely only on impressions. Pankaj uses team metrics such as velocity, backlog health, lead time, cycle time, and Cumulative Flow Diagrams when Kanban is in use. He also pays attention to team satisfaction and regular feedback. The frequency of that reflection depends on team maturity. Mature teams may need a two-week check-in rhythm, while newer teams need closer weekly attention. His maturity model is deliberately adapted team by team, because every team's product, skills, technical context, and backlog are different. The bigger point for Scrum Masters is useful: success is not being needed in every conversation. Success is seeing the team grow enough that your presence becomes lighter.   Self-reflection Question: What would your team do this week if you were not available to guide the Scrum events? Featured Retrospective Format for the Week: Anonymous Action-Tracking Spreadsheet Pankaj keeps retrospectives simple and practical. Before the retrospective, he shares a spreadsheet where team members can add what went well, what needs improvement, the action needed, who is accountable, the deadline, and the status of previous actions. He also allows anonymous input, which helps quieter team members raise points they may not want to voice live. During the meeting, the team reviews previous retrospective actions and then discusses the current sprint. Pankaj is careful about who is in the room. Sometimes supervisors are needed, but often their presence changes what people are willing to say. For him, facilitation starts with creating the right audience for the conversation.   [The Scrum Master Toolbox Podcast Recommends]

Pankaj Kumar: Using Agile Prioritization to Handle Competing Roles Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Who am I going to deliver to, and how urgent is this task for them?" - Pankaj Kumar   Pankaj's current challenge will sound familiar to many Scrum Masters and Product Owners: too many important demands, all arriving at once. He runs his consultancy, Test2Deploy, works with a startup, serves as a board member in Agile Finland, and is also building a healthcare app. The problem is not motivation. The problem is deciding what deserves attention when everything looks valuable. Pankaj uses a simple prioritization matrix built around value and importance, then adds practical filters: deadline, effort, risk, impact, stakeholder, and the stage of the work. Is it still planning? Is it in execution? Can it be delegated? Can it be removed? Vasco connects this personal challenge back to product work, because teams face the same question every sprint. Prioritization is not just a private calculation. The stakeholder matters because they understand urgency, tradeoffs, and business consequences. Pankaj's approach gives Scrum Masters a useful coaching angle: help teams make the decision criteria visible before the pressure hits.   In this episode, we refer to prioritization, stakeholder management, and Product Ownership.   Self-reflection Question: What criteria does your team use when two pieces of work both look urgent?   [The Scrum Master Toolbox Podcast Recommends]

Pankaj Kumar: The Agile Team Split Between Seniors and Juniors Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "We have to focus not on individual tasks, but the team goals. Shared goals." - Pankaj Kumar   Pankaj describes a team that had all the ingredients for friction: senior people with deep experience, junior people who needed support, and a Sprint Goal that required everyone to move together. The weak signal showed up in the retrospective. The junior team members were quiet, and the seniors were implicitly treating mentoring as work that did not help them. Pankaj started with one-on-one conversations to understand what was behind the silence. Then he reframed mentoring around the team outcome. The senior people were not being asked to "lose time" helping juniors. They were being asked to build the capability the whole team needed to deliver. He also pointed out that learning flows both ways: junior team members often bring fresh technical knowledge that experienced people have not yet seen. By pairing senior and junior people on shared tasks, the team started to build trust, empathy, and confidence. The result was visible outside the team too. Stakeholders could see the difference in sprint reviews when the team showed up with more alignment.   In this segment, we talk about team dynamics, psychological safety, and mentoring.   Self-reflection Question: Where is your team still optimizing for individual tasks when the real need is a shared outcome? Featured Book of the Week: Straight from the Gut by Jack Welch Pankaj mentions several leadership books that shaped his thinking, including Start With Why by Simon Sinek, Leaders Eat Last by Simon Sinek, and Stay Hungry Stay Foolish by Rashmi Bansal. The one that stayed with him most was Straight from the Gut by Jack Welch. What connected the book to his Scrum Master work was the push against bureaucracy and the image of building a speedboat instead of a large, slow ship. For Pankaj, that linked directly to empowered teams, fast learning, and the Scrum Master responsibility to help people move from hierarchy into ownership.   [The Scrum Master Toolbox Podcast Recommends]

Pankaj Kumar: Building Agile Trust One Small Scrum Sprint at a Time 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 are here to learn. Learning is the key." - Pankaj Kumar   When Pankaj Kumar first moved from QA lead into the Scrum Master role, the organization was also moving from waterfall into Scrum. The team had been used to long project cycles, and suddenly they were being asked to deliver working software every two weeks. The difficult part was not the process language or the events. It was the fear behind the change. Pankaj saw that the team needed trust before it could take the first real step. He started with one-on-one conversations, made the pilot explicit, and kept bringing people back to a shared outcome instead of individual tasks. The breakthrough came when the team stopped trying to prove that "Scrum works" all at once. Instead, they picked small pieces of work, delivered something tangible, and celebrated the first signs of progress. That sense of accomplishment helped the team replace fear of failure with confidence. For Pankaj, the lesson was simple: a Scrum Master helps the team stretch, but not so far that people stop feeling safe enough to try.   In this episode, we refer to psychological safety and Scrum.   Self-reflection Question: What is the smallest useful increment your team could deliver this sprint to build confidence in itself?   [The Scrum Master Toolbox Podcast Recommends]

BONUS: Real-Time Research for Change Leaders Using AI AI is changing how Scrum Masters, Agile coaches, and change leaders make sense of organizations. In this BONUS episode, Ari-Pekka Skarp shares how he uses AI as a research assistant, a workspace partner, and a way to bring qualitative research into day-to-day change leadership. From Curiosity to Research Assistant "It felt like having a research assistant."   Ari-Pekka's first serious AI use did not start in his full-time change leadership role. It started with side projects, research, psychotherapy-related work, and watching his son build websites with Lovable. That curiosity became practical when Ari-Pekka began using AI to support his PhD research. Instead of spending a full day scanning articles, he could find relevant sources, generate useful summaries, and decide where to go deeper in about half an hour. The key was not that AI replaced his judgment. Because he already knew the research area, he could evaluate the quality of what the AI returned and use it as a complement to his own expertise. AI Expands the Research Surface "With the help of AI, I could actually make a little more of these sidetracks."   One of the biggest changes Ari-Pekka noticed was that AI made side paths cheaper to explore. In research and change work, we often ignore interesting but uncertain threads because time and attention are limited. AI gave him a way to examine adjacent ideas without losing the main direction. At the same time, he points out a real risk: AI can guide us toward something too quickly. Sometimes a slower, more intuitive decision is more aligned with the deeper research goal. For Scrum Masters and coaches, that is an important distinction: AI can widen the field of inquiry, but it should not quietly take over the choice of where to look next. Workspaces for Change Leadership "I can create this kind of bird's eye perspective of the organization or the given project quite quickly."   Ari-Pekka describes a major shift when he started using Visual Studio Code and AI agents as a workspace for knowledge work, not only for software. In his workspaces, he organizes goals, themes, source material, Jira data, Confluence material, meeting notes, and other organizational signals so that AI can help him analyze and visualize the big picture. This gives him a practical way to represent relationships, dependencies, open threads, and organizational responses to interventions. For change leaders, the point is not the tool itself. The deeper idea is to structure the work so AI can help process the data while the human still owns the interpretation. Bringing Qualitative Research Into Daily Change Work "I try to form a hypothesis of what I find from the data, and then I see whether those hypotheses are correct or not."   Ari-Pekka uses his qualitative research background to teach AI how to process organizational data in a consistent way. He is not just asking for a summary. He is thinking like a researcher: what is the question, what data is available, what method should be used, and what output format will make interpretation possible? Vasco connects this to the work Scrum Masters already do: hypothesis thinking, looking for evidence beyond our own biases, and using data to test what is really happening in the system. AI makes it possible to bring those research habits into day-to-day work, instead of reserving them for long academic projects. PDCA With Larger and Messier Data Sets "Now we can just use far more extensive data sets from many different sources and integrate it with the help of AI."   Ari-Pekka links AI-supported change work to PDCA: plan, do, check, act. The cycle is familiar, but the available data has changed. Teams and organizations now generate large amounts of textual, conversational, and workflow data across tools like Jira, Teams, Slack, and Confluence. AI can help integrate those sources, but Ari-Pekka warns that organizations are missing an understanding of research methodology. When the same AI tool can produce different answers from the same data, small changes in the research question, method, and prompt matter. Scrum Masters do not need to become full-time researchers, but they do need enough discipline to ask better questions and separate method from interpretation. A Small Experiment: Analyze Power Relations in Meeting Transcripts "With the help of AI, anybody can have a little bit of this kind of experiment in real time."   For a practical experiment, Ari-Pekka suggests starting with meeting transcripts, with explicit consent from the people involved. A Scrum Master or Agile coach can ask AI to perform a power-relation or discourse analysis of the conversation and look for patterns in who speaks, who defines the agenda, which ideas are ignored, and how decisions emerge. Organizational psychologists and researchers have studied these dynamics for years, but the work has traditionally been slow and specialized. AI makes it possible to try a lightweight version of that analysis quickly, then use the results as a prompt for reflection, not as a final judgment. About Ari-Pekka Skarp Ari-Pekka is not only a very experience Agile Coach, but he's also a Psychotherapist, and Organizational Psychologist with over 20 years of experience working with organizations. As an author of several books on topics such as Complexity, the mind, and Mindfulness, Ari-Pekka blends deep psychological insight with practical expertise to help leaders and teams navigate the evolving landscape of work.   You can link with Ari-Pekka Skarp on LinkedIn. You can read Ari-Pekka's Finnish writing at Mielen laboratorio and his English blog at Fractal Sauna. You can also find Ari-Pekka's previous Scrum Master Toolbox Podcast episodes on his guest page.

BONUS: The Hidden Dangers of AI at Work With Ari-Pekka Skarp AI is usually sold as a productivity tool, but Ari-Pekka Skarp argues that the real story is what it does to the conversations, skills, and purpose that hold teams together. In this BONUS episode, Ari-Pekka explores why organizations are rushing to use AI "as efficiently as possible" without defining what efficiency means, and what that rush is quietly costing us. Organizations Are Conversations "The organizations are actually conversations, conversational patterns between people."   Ari-Pekka's path from software engineering in 1999 to psychology, psychotherapy, and change leadership was driven by one thread: how the mind works, both individually and socially. Meeting Ralph Stacey, Esko Kilpi, and Douglas Griffin at Nokia changed how he saw organizations. Instead of a machine made of parts, an organization is a living pattern of conversations — people responding to each other's gestures, again and again. George Mead added the idea that the human mind itself is not individual but relational. This matters for AI because a large language model is a new kind of player in those conversations, not just a tool that moves data between them. The Efficiency Fetish "It's like how much people are pressing the acceleration pedal in the car. It doesn't tell anything where the car is going."   Many organizations are trying to use AI "as efficiently as possible," but Ari-Pekka points out that few have defined what efficiency means. What he sees instead is measurement of AI usage itself — how many people are prompting, how many tokens are flowing. He calls this tokenmaxxing. The car metaphor is the key: pressing the accelerator harder says nothing about direction, and going fast in the wrong direction is more costly than going slow. Efficiency only has meaning against a purpose, and purpose is itself a conversational achievement — something a team has to talk its way into. De-Skilling Is the Hidden Cost "If there's nobody in the room who could review what AI has produced and say whether it's correct or not, it's not an AI strategy. It's a liability."   The risk Ari-Pekka worries about most is de-skilling. When we offload cognitive work to AI, we lose the friction that builds learning. There is neurological evidence that people who rely heavily on AI do not develop the same brain structures as those who work through challenges manually. Some skills are fine to lose — nobody needs machine code anymore — but the ability to review and judge AI output is critical, and it is exactly what erodes when we skip the slow work. The result is a double bind: senior experts burn out under the review burden of fast-produced AI output, while juniors never get the time to build the expertise they would need to review it. We Need Speed Limits for AI "We can't optimize individual going as fast as possible... we need a collective... boundaries for individuals."   Ari-Pekka reaches for a historical analogy. Our biological rate of processing information is roughly ten bits per second, and it is not going to change. When we only had horses, we did not need speed limits. When we built cars that could go 200 kilometers per hour, we had to invent rules and boundaries to protect the system. AI is the same: we have reached a threshold where optimizing individual output — more code, more stories, more messages — can damage the whole organization. The control mechanism Ari-Pekka proposes is cognitive friction, deliberately added back into the system so that speed serves the system rather than breaking it. The Tokenization of Work "It's very easy to lose the purpose where you are going if you are only doing fragments of work."   Ari-Pekka's article The Tokenization of Work describes what happens when the unit of work is no longer a job, a profession, or even a task. Digital tools make it easy to fragment work into tiny pieces and spread them across AI agents, and in the process the boundaries that gave work its meaning vanish. Purpose is what protects us from burnout: with a clear purpose, people can do very demanding work without burning out, because the work feeds them. Without purpose, exhaustion arrives fast. For Scrum Masters, this means grounding the work in why it matters is more important now, not less. AI Is an Echo Chamber, Not a Mirror "The AI is more kind of an echo chamber in a sense that it doesn't push back so much."   Ari-Pekka compares AI to George Mead's "generalized other" — the internalized sense of how others see us. AI can play that role, but with a dangerous twist: it is programmed to be agreeable, so it behaves more like an echo chamber than a mirror. Real people push back, point out mistakes, and keep disagreeing. That friction is where learning, competence, and self-awareness grow. Ari-Pekka's practical move is to prompt AI for three different and conflicting perspectives rather than one, using it to go wider rather than only faster. It is not a perfect fix — the model still tries to merge them into one — but it is better than a single agreeable answer. A Three-Second Pause "Take a three-second pause... and just ask yourself, what are you doing?"   Ari-Pekka leaves listeners with a small challenge. A few times a day, when you are about to prompt an AI, pause for three seconds and ask what you are actually doing: are you seeking information, or seeking confirmation? Then consider whether it would be better to call a person and have a real conversation. It is a tiny practice, but it points at the whole episode's message: AI is not neutral infrastructure. It changes the conversations, the skills, and the purpose of work, and the people who notice that — Scrum Masters and Agile coaches especially — are the ones who can keep it from quietly reshaping their teams. About Ari-Pekka Skarp Ari-Pekka Skarp is a psychologist, psychotherapist, Lead Change Coach, organizational psychologist, and author. He wrote Mindfulness, mielenselkeys ja myötätunto, hosts Mielen laboratorio, and researches nondualism. His work connects psychology, complexity, Agile, and AI at work.   You can link with Ari-Pekka Skarp on LinkedIn. You can read Ari-Pekka's Finnish writing at tietoisuustaidot.com and his English blog at Fractal Sauna. You can also find Ari-Pekka's previous Scrum Master Toolbox Podcast episodes on his guest page.

Deborah Colombari: Product Owners Who Protect Focus and Enable Ownership In this episode, we refer to INVEST criteria and Behavior Driven Development. The Great Product Owner: Clear Outcomes, Strong Refinement, and Space for the Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "He doesn't say how. That allows the team to own the solution." - Deborah Colombari   Deborah describes a great Product Owner who came from project management, but learned to work deeply with upstream discovery and refinement. This PO uses INVEST criteria, Behavior Driven Development-style acceptance criteria, and explicit policies so that developers understand what needs to be done and why. He writes down expected outcomes at the epic and feature level, not only at the story level. Because he does not have a developer background, he depends on the tech lead, and Deborah sees that as a strength when the collaboration works. The PO brings business outcomes and clarity. The team brings technical options and owns the solution. That split creates room for trust.   Self-reflection Question: Does your Product Owner make the outcome clear while still leaving the solution to the team? The Bad Product Owner: Adding Work Without Understanding the Consequences 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 doing whatever he wanted without thinking of the consequences." - Deborah Colombari   Deborah's Product Owner anti-pattern is a cross-team PO who accepted incoming requests and simply added them to the Sprint. There was no clear requirement discussion, no Definition of Done check, no Definition of Ready conversation, and no technical refinement with someone who could expose complexity. The PO treated every request as urgent, even when it was not, and told developers to stop their current work to pick up the new item. The result was more parallel work, broken Sprint Goals, less predictability, and a destabilized team system. Deborah eventually had to step partly into the Product Owner space to limit WIP and protect delivery. The lesson is blunt: Product Owners who ignore consequences turn priority into chaos.   Self-reflection Question: What is the cost of every "small urgent request" your team accepts mid-Sprint?   [The Scrum Master Toolbox Podcast Recommends]

Deborah Colombari: Stable Agile Teams Make Delivery Predictable Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "When I have a stable team, I have reliable data." - Deborah Colombari   For Deborah, success as a Scrum Master comes down to one word: stability. A stable team communicates better, shares knowledge, avoids hero-driven delivery, and becomes predictable enough that the Scrum Master can use historical data instead of wishful thinking. Deborah connects stability with flow metrics and statistical thinking. When an expedite request appears, a stable team can look at its own history and forecast with a useful level of confidence. An unstable team, by contrast, creates silos, overloads key people, and turns every new request into a crisis. Vasco connects Deborah's answer to systems thinking and statistical process control: the team is part of a wider system, and its delivery capability reflects that system. The point is not to force the team to commit beyond what the system can support. The point is to observe the system, improve it, and use real data to forecast what is likely to happen.   Self-reflection Question: Do you know your team's delivery capability from evidence, or are you still depending on optimistic commitments? Featured Retrospective Format for the Week: The 4Ls Retrospective Deborah recommends the 4Ls retrospective: liked, learned, lacked, and longed for. She adds one practical extension: an action-items column. Deborah likes the 4Ls because the quadrants help the team see the same issue from different angles. Something the team longed for may connect to something they learned. Something they liked may expose what was previously missing. The action-items column matters because complaint is easy, but turning a complaint into a concrete experiment is harder. Deborah uses those actions to create or update team agreements, making the retrospective outcome last beyond the meeting.   [The Scrum Master Toolbox Podcast Recommends]

Deborah Colombari: Coordinating Global Agile Teams Around One MVP 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 scope is clear. How we are going to deliver it is not clear." - Deborah Colombari   Deborah brings a live challenge from a new global project. Her team carries the deadline, but three other teams must contribute, and those teams do not share the same priority or urgency. The question becomes: how do you align teams when only one of them feels the pressure? Deborah has already tried management alignment meetings, but they have not worked as well as needed. Her next experiment is a one-week workshop inspired by Lean Inception, where managers and teams can write down what is needed, when it is needed, and what each team can realistically contribute. Vasco and Deborah explore three practical moves: define the MVP as a real vertical slice, ask whether a person from each dependent team can join for a Sprint or a few days per week, and reduce dependencies by moving ownership closer to the team that holds the deadline. The coaching conversation ends with a useful image: even vertical slices contain thinner vertical slices. When the deadline is fixed, scope must become flexible.   In this episode, we refer to Lean Inception and Minimum Viable Product.   Self-reflection Question: When your team depends on others, are you managing the dependency or trying to reduce it?   [The Scrum Master Toolbox Podcast Recommends]

Deborah Colombari: The Agile Team Destroyed by a Toxic Feedback Loop 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.   "Whenever we almost started to achieve norming, we went back to storming." - Deborah Colombari   Deborah shares the story of a team of about twelve developers and QA specialists that kept losing people one by one. The early signal was not a technical problem. It was turnover. A toxic direct leader created pressure, blame, and snarky responses whenever the team tried to explain what was happening. Because that leader's own manager behaved the same way, Deborah saw a reinforced pattern rather than an isolated personality problem. The team could not stabilize. Every time it moved toward norming, someone left or someone new arrived, sending the team back into storming. Knowledge walked out the door with the people who left, delivery dates slipped, morale dropped, and a fixed-date call center project was eventually canceled. Deborah's story is a sharp systems thinking reminder for Scrum Masters: sometimes the problem is not inside the team. The team may be showing the symptoms of a system that punishes honesty, overloads people, and teaches them that leaving is safer than speaking.   In this segment, we talk about Russell Ackoff, his systems thinking interview with Haynes Media Works, and the Tuckman model.   Self-reflection Question: What turnover or morale signals are you treating as team problems when they may be system problems? Featured Book of the Week: Russell Ackoff Interview by Haynes Media Works Instead of a book, Deborah recommends an old Russell Ackoff interview from Haynes Media Works. She connects Ackoff's thinking to Donella Meadows and to the practical work of Scrum Masters. Deborah highlights how Ackoff explains that the outcome a system is designed to produce affects how the whole system behaves. Her example is health care: if the system rewards treating sickness, it becomes a disease-care system instead of a health system. For Scrum Masters, the lesson is direct. Teams are systems, companies are systems, and the incentives around them shape what they do. Deborah uses Ackoff's work to remind us to look at feedback loops before assuming people are the problem.   [The Scrum Master Toolbox Podcast Recommends]

Deborah Colombari: When Agile Principles Became a Fight With the System Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I was trying to go against the system, but you cannot go against the system." - Deborah Colombari   Deborah Colombari's Scrum Master journey started with a sense that Agile gave her permission to work differently. After early project management work, a year in Canada exposed her to Agile, and the Scrum Master role soon "felt like a glove." But her failure story starts when a supportive leader left and a more command-driven manager arrived. Deborah pushed back hard, trying to protect the Agile practices she believed were right: dailies, burn-down and burn-up charts, transparency, and team focus. The problem was that she was fighting the manager instead of first understanding the system around him. That conflict spilled into the team and damaged morale. Looking back, Deborah says she would now sit down with the manager first, understand the goals and pressures behind the change, and look for compromise before escalating into resistance. Her key learning was pragmatic: Scrum Masters need principles, but they also need diplomacy. The work is not only helping the team inside the Agile bubble, but also translating between that bubble and the wider organization.   In this episode, we refer to ITIL, the Dunning-Kruger effect, and Thinking in Systems by Donella Meadows.   Self-reflection Question: Where are you fighting the system before you have understood the pressure it is trying to respond to?   [The Scrum Master Toolbox Podcast Recommends]

Sheik Meeajaun: Product Owners Need the Justified No to Protect Customer Value In this episode, we refer to Vasco's Product Owner episodes, where Product Owners share their own lessons from the role. The Great Product Owner: Owning the Product and Practicing the Justified 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.   "No, you cannot have this, but this is why." - Sheik Meeajaun   Sheik's model for a great Product Owner came from a mentor he worked with early in his career. That PO owned his slice of the product, delivered consistently, and taught Sheik the power of the "justified no." A strong PO does not simply reject stakeholder requests. They explain the trade-off, ask what should be removed from the sprint, and make business value visible. If a stakeholder wants urgent work, the PO can ask them to get agreement from the person whose work would be displaced. That shifts the conversation from pressure to prioritization. For Sheik, great Product Owners understand that their job is to bring value to the business and delight customers. They care deeply enough about the product to protect it from random requests, HiPPO decisions, and backlog noise. They know success is not only delivery. It is the visible appreciation that comes when people recognize a product decision created real value.   Self-reflection Question: Does your Product Owner have a practical way to say no that protects value without turning every request into conflict? The Bad Product Owner: The Executor Who Cannot Say No Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "A Product Owner's primary job is to bring value." - Sheik Meeajaun   The anti-pattern Sheik warns about is the Product Owner as executor. This PO does not own the product, does not know the customers deeply enough, and does not push back when leadership changes direction. They become a project manager with a backlog, accepting whatever the highest-paid person in the room asks for next. The team then loses coherence, the product loses a clear direction, and the Scrum Master is left helping the team manage the consequences of weak ownership. Sheik is careful not to blame only the individual. Many POs are placed in the role without mentoring, without a clear understanding of product ownership, and without the organizational support to say no. The result is predictable: a mountain of requests, no clear value conversation, and a team delivering work without a strong product story behind it.   Self-reflection Question: Where is your Product Owner being treated as an order taker instead of the person accountable for product value?   [The Scrum Master Toolbox Podcast Recommends]

Sheik Meeajaun: Scrum Master Success Starts With Trust and Ends With Teams Delivering 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 try to build trust before I build anything else." - Sheik Meeajaun   For Sheik, Scrum Master success is simple to describe and hard to earn: the team delivers what it committed to, demos happen, customers are impressed, and the Scrum Master has protected the team from avoidable disruption. He sees himself as a shield, pushing back when stakeholders bypass the team or when a Product Owner wants to interrupt the sprint without acknowledging the cost. But when he joins a new team, Sheik does not start with burndown charts or velocity. He starts with one-on-one conversations. He tells people his job is to make their work easier, then asks what help they need. Those conversations reveal the real blockers that charts often hide. Trust comes first because teams deliver through people, not dashboards. When people know each other, help each other, and pick up work when someone is away, they become more than a collection of roles. They become a team with a shared future.   Self-reflection Question: What do your first conversations with a new team tell people about the kind of Scrum Master you intend to be? Featured Retrospective Format for the Week: Three Words to Sum Up the Sprint Sheik starts retrospectives by asking each person for three words that sum up the sprint. The words can be simple: productive, boring, repetitive. The value comes from asking people to explain what sits behind those words. Instead of stopping at "I could not finish my story," Sheik wants the team to walk back through what happened: who was unavailable, what help was missing, where the Product Owner did not clarify, and which impediment stayed hidden too long. For him, a good retrospective creates a safe place to talk honestly about the details before the failure. The format is intentionally plain. The goal is not novelty. The goal is a conversation that finds the friction early enough for the team to do something about it.   [The Scrum Master Toolbox Podcast Recommends]

Sheik Meeajaun: Scrum Masters Must Learn by Experimenting When AI Joins the Agile Team Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Never be afraid to admit you don't know something." - Sheik Meeajaun   Sheik brings a current challenge that goes beyond one team: the gap between Scrum theory and real work when the context changes faster than the playbook. His example is AI. Scrum Masters are now asked to help teams where AI agents contribute to delivery, but no certification course can fully prepare us for that. Sheik's starting point is humility: say "I don't know," learn the domain, run small experiments, and reflect quickly. In one team, two human developers worked alongside several AI agents. They could not run a normal standup with Claude, so the team created a status report and reviewed it with the human team members. Sheik framed the agents as junior developers: useful, fast, and still requiring clear instructions, review, and guardrails. That framing helped experienced developers see AI collaboration as coaching and oversight, not as magic productivity. The key lesson is practical empiricism: try, inspect, adapt, and keep learning as the work changes.   In this episode, we refer to Scrumling's AI Product Owner course and the need to adapt Scrum practice to AI-enabled work.   Self-reflection Question: What new reality is your team facing where the honest Scrum Master answer should start with "I don't know yet"?   [The Scrum Master Toolbox Podcast Recommends]

Sheik Meeajaun: When Spillover Becomes Normal, Scrum Teams Stop Seeing the Cost 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 good Scrum Master makes their Product Owner look like a superstar." - Sheik Meeajaun   Sheik describes a team pattern many Scrum Masters recognize: spillover had become so normal that finishing the sprint felt like a special event. Refinement was weak, stories were often written during refinement instead of before it, and Product Backlog Items were sometimes little more than one-line titles. The Product Owner was not consistently engaged, standups had become update sessions for the PO, and nobody was connecting non-delivery to business impact. Sheik brought his Product Owner background into the Scrum Master role and started asking a more pragmatic question: what is the cost per sprint when we do not deliver? By making cost of delay visible, he helped the team see that spillover was not just a process issue. It was lost value. The experiments were practical: protect focus, prepare stories before refinement, and tackle the gaps at ground level instead of pretending the organization would fix everything first.   Self-reflection Question: What does your team treat as normal today that is quietly costing the product money every sprint? Featured Book of the Week: The Scrum Guide by Ken Schwaber and Jeff Sutherland Sheik does not pretend to have a long reading list. He says experience shaped him more than any single book, because contracting exposed him to many organizations and many versions of Scrum in practice. Still, he points listeners back to The Scrum Guide as the minimum reference every Scrum Master should know. For Sheik, the guide gives the vocabulary and foundation, but experience teaches the translation work: how those ideas survive contact with real teams, weak refinement, Product Owners who are stretched thin, and organizations that say "Agile" while still behaving like escalation machines.   [The Scrum Master Toolbox Podcast Recommends]

Sheik Meeajaun: The Scrum Master Who Let Standups Stay Silent Until the Team Took Ownership Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "You can't fix something until it breaks." - Sheik Meeajaun   Sheik Meeajaun joins us from Bulgaria with a failure story about silence, escalation, and the uncomfortable work of helping a team own its own communication. He stepped into a hybrid team where the previous Scrum Master had led the Daily Scrum like a status meeting. When Sheik stopped driving the conversation, the team simply stopped speaking. For two weeks, the standups were painfully quiet. The Product Owner tried to take over, managers escalated complaints, and Sheik had to explain that the silence was exposing the real problem: the team had learned to wait for someone else to lead. The breakthrough came when one quiet team member finally spoke up and said what she was working on. Sheik asked her to pass the conversation to the next person, and the team slowly built the habit of talking to each other. His lesson is clear: sometimes the Scrum Master must resist rescuing the team long enough for the team to see what needs to change.   Self-reflection Question: Where are you stepping in so quickly that your team never has to build the muscle of ownership?   [The Scrum Master Toolbox Podcast Recommends]

BONUS: When the Team Becomes the Operating System for AI — Marko Taipale on the Twin Project at Solita Most teams trying to "use AI" end up with fast individuals and a slower system. Marko Taipale ran a two-year experiment at Solita that suggests the real bottleneck isn't the tool — it's the team's operating model. In this conversation, Vasco and Marko walk through the Twin Project with ISS Finland — two teams, same ERP pricing tool, one classical agile, one with generative AI in the room — and the lessons that became the CollabAI framework. The Twin Project — Two Teams, Same Product, One With AI in the Room "We had a luxury of: do whatever you want with AI, please get at least the same results, towards the same goal."   In 2024, Marko's team at Solita was set up as the counterpart to an existing Scrum team building an ERP pricing tool for ISS Finland. Same product mission, two different operating models. The first days were chaotic and exploratory — the team tried over 120 AI tools, built a custom GPT to act as a stand-in product owner, and even sent a virtual assistant to sit silently in the other team's meetings so nobody from Marko's team had to attend. The framework grew out of what kept working, not from a plan written upfront. "Fast Individuals, Slow System" — Why Buying Licenses Doesn't Fix the Bottleneck "If you don't change your structures, AI won't do anything faster. The only thing that gets faster is the queues between your decision-making gates."   The line from Marko's book lands hard once you have seen it inside a team. A Copilot license speeds up the individual — and then the individual sits and waits for the rest of the system: reviews, handoffs, refinement, stakeholder meetings. Those queues are exactly what AI accelerates, and the team feels even more frustrated than before. The real intervention is upstream, in how the team shares context and makes decisions together. Without that, AI just makes the existing inefficiency more obvious. Drifting in the Solution Space — Why Sense-Making Has to Happen Together "None of the real problems are so simple that a single person can solve them. If it's that simple, you should automate it."   The early Twin Project team kept seeing what Marko calls drifting — small interpretive mistakes at the start of a task that twisted the solution into something unrecognisable later. Each person was reading the same docs and the same proxy-PO conversations, and each was leaving with a slightly different picture. Individual interpretation was not enough. They moved from individuals to pairs, then to whole-team sense-making sessions. The shared context only became useful when the team processed it together — and that processing turned out to be where the learning compounded. Never Leave the Daily — When Mob Programming Becomes the Operating System "This is happening so fast, we shouldn't actually leave the daily."   The team started with vanilla Scrum, extended dailies, then ran multiple per day, then realised that the meeting was the work. They drifted into mob programming without naming it — a shared virtual machine where one person controlled the screen at a time, switching every few minutes. The agile labels came later, when someone read Mob Programming by Woody Zuill (see his earlier episodes on the Scrum Master Toolbox Podcast) and saw the team's own behaviour reflected back. The takeaway: when the pace of decisions exceeds the cadence of meetings, the team has to live inside the conversation, not visit it once a day. The 40-Prototypes Moment — When the Customer Joined the Mob "You waited 37 hours to get to this point where we get feedback."   This was the turning point. Marko had built 40 different prototypes of the pricing tool in one hour, then walked into a weekly review where the customer pointed out the obvious: if the prototypes took one hour to make, the team had been waiting 37 hours to get the feedback that actually mattered. From that moment the client became part of the mob. New product directions started landing every five to seven minutes. The backlog quietly disappeared — issue management stayed, but for the AI's context, not for humans. When the product owner is in the room all day, the storage-and-handover layer stops earning its keep. The Regulation Layer — Why Sustainable Pace Gets Sharper, Not Softer, With AI "AI is a machine. It won't stop. That's why we need a regulation layer — and we have to regulate together, not individually."   What broke first in the Twin Project was not the technology — it was the people. Cognitive load and the brain's hunger for clarity become the new constraint once decisions are flying every few minutes. The old Scrum idea of sustainable pace gets a second life here, but it has to be a shared pace, set by the team, not an individual one. Engagement is the early warning signal — when people start disengaging, the system is already over its capacity. For Scrum Masters and coaches, this is where the work moves: watching the team's energy curve, not just its throughput. The Agentic Horizon — From Teammates to Agents Acting on the Team's Behalf "AI is a new player in this field. The next conversation is governance — and it has to start now."   CollabAI was about humans and AI on one screen. The next move — what Marko is now building at Agion — is agents acting on the team's behalf. The governance shape is not optional, and it is the conversation Scrum Masters and coaches need to start having before agentic systems are everywhere on the team. Marko's article series on Agion (the brain fry posts) is the public record of what they are learning as they build the governance layer for autonomous agents. About Marko Taipale Marko Taipale is the author of CollabAI: AI Teamwork In Practice (foreword by Joe Justice) and currently works at Agion Inc. At Solita, he co-led the Twin Project with ISS — two teams building the same ERP pricing tool, one with classical agile, one with generative AI embedded end-to-end — and turned what they learned into a framework for teams that want AI as a synchronous teammate, not a faster individual tool. CollabAI book · Leanpub · LinkedIn   You can link with Marko Taipale on LinkedIn.

Arun Parameswaran: Product Owners Who Create Better Product Conversations in Scrum In this episode, we refer to Arun's AI prompt library for Scrum Masters and project managers. The Great Product Owner: Curiosity, Clear Direction, and Outcome Focus 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 great PO doesn't only ask, did we deliver? They ask, do people communicate openly?" - Arun Parameswaran   Arun describes great Product Owners as collaborative, curious, and close enough to the team to understand how delivery really works. The best POs he worked with did more than check whether items were delivered. They asked whether knowledge was distributed, whether people communicated openly, and whether everyone had a chance to contribute. They gave the team clear product direction, supported prioritization, managed stakeholders, and stayed available when the team needed context. Arun emphasizes outcome focus: value for the customer expressed in a way the team can understand. A strong PO becomes the bridge in both directions, helping stakeholders understand the team and helping the team understand the customer.   Self-reflection Question: Does your Product Owner help the team understand customer value, or only the next ticket? The Bad Product Owner: Turning the Team Into a Ticket Factory 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 Scrum Master shouldn't just help the PO write better tickets. We should help create better product conversations." - Arun Parameswaran   The anti-pattern Arun warns about is the Product Owner as ticket distributor. Stakeholders ask for something, the PO turns it into a ticket, and the team delivers without understanding the problem, the outcome, or why the work matters. Over time, the team becomes a delivery factory, and Scrum starts to look like waterfall with smaller batches. Arun's coaching move is to shift the conversation away from "better tickets" and toward better product thinking. What problem are we solving for customers? What outcome do we expect? What should we prioritize? What can we say no to? For Scrum Masters, this means coaching the PO and the team to bring customer context, stakeholder feedback, and prioritization into the same conversation.   Self-reflection Question: What product conversation is your team avoiding by hiding behind ticket writing?   [The Scrum Master Toolbox Podcast Recommends]

Arun Parameswaran: Success for Scrum Masters Means Teams Ask Better Questions Without You Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "My goal isn't to become indispensable. My goal is to create a team that doesn't depend on me." - Arun Parameswaran   For Arun, Scrum Master success is not measured by how many meetings he runs or how often the team asks him for help. It is measured by the team's ability to solve problems without depending on him. If he has to remind everyone to update Jira, facilitate every difficult conversation, or resolve every obstacle, he is creating dependency. A healthier signal is when team members talk directly to each other: "This is blocked. Who can help me?" or "Let's finish this before starting something else." Arun compares the Scrum Master to a football coach watching the match from the side. The team needs space to play, make decisions, and learn. The Scrum Master still observes and coaches, but the goal is to intervene less often and more intentionally. As Vasco summarizes, this requires learning to wait before stepping in.   Self-reflection Question: What would your team do differently if you waited one more minute before intervening? Featured Retrospective Format for the Week: What? So What? Now What? Arun's favorite retrospective format is "What? So What? Now What?" because it moves the team from facts to meaning to action. "What happened?" helps the team describe reality. "So what?" asks why it matters. "Now what?" turns the discussion into a small experiment for the next sprint. Arun also avoids using the same format every time. He often shares the board two or three days before the retrospective so people can reflect before the meeting, add observations, and appreciate teammates. That preparation saves time in the session and makes space for a short fun activity before the team works through the real topics. His goal is simple: every retrospective should produce learning and at least one concrete experiment.   [The Scrum Master Toolbox Podcast Recommends]

Arun Parameswaran: Using Scrumban and WIP Limits to Help Agile Teams Find Focus 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 WIP limit helped the developers not context switch." - Arun Parameswaran   Arun brought a practical challenge to the Wednesday coaching conversation: a team doing both operations and development work needed more visibility and focus than their Scrum board was giving them. The trigger was context switching. Work stayed "in progress" even when blocked, people picked up new topics before finishing old ones, and stakeholders kept asking what was actually happening. Arun helped the team experiment with Scrumban, keeping useful Scrum events while adding a Kanban-style board and explicit WIP limits. The breakthrough was not just visualizing the work. It was helping the team own the limits. They created an "operator of the week," rotating the responsibility for watching WIP and calling out when the team was taking on too much. That small practice made focus a team responsibility instead of a Scrum Master lecture.   Self-reflection Question: Who owns your team's WIP limits in practice, not just on the board?   [The Scrum Master Toolbox Podcast Recommends]

Arun Parameswaran: How Powerful Questions Help Scrum Teams Handle Stakeholder Conflict 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 thing a Scrum Master can give the team isn't the answer. It's a question." - Arun Parameswaran   Arun describes a team pattern many Scrum Masters recognize: stakeholders bypassing the Product Owner and going straight to developers with new requests after the sprint had already started. The developers wanted to help, so they accepted the interruptions. The result was context switching, broken priorities, and a quiet loss of focus. Arun worked with the customer team, Product Owner, and developers to create a simple agreement: new work had to come through the PO, be clarified, and be prioritized before it reached the team. That agreement gave developers permission to protect the sprint without turning every conversation into a personal conflict. Arun also shares how he handled the classic misunderstanding that "being Agile" means accepting every change immediately. For him, adaptability still needs timing, clarity, and shared agreements.   In this segment, we talk about the coaching stance and how Scrum Masters can use questions to help teams think together.   Self-reflection Question: What agreement would help your team protect focus without shutting stakeholders out? Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins Arun recommends Coaching Agile Teams by Lyssa Adkins because it helped him move beyond ceremony facilitation. The book gave him a clearer picture of the Scrum Master as a coach for individuals, the team, and the wider organization. One question stayed with him: am I solving the problem for the team, or helping the team learn to solve it themselves? That shift changed how Arun worked. Instead of telling teams what to do, he began asking questions such as "What do you think is causing this?", "What options do we have?", and "What are we not seeing?" For Arun, the book is a practical reminder that coaching is not about leading people to your answer. It is about helping people think.   [The Scrum Master Toolbox Podcast Recommends]

Arun Parameswaran: The Scrum Master Mistake of Fixing Trust With Process 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 confuse activity with progress." - Arun Parameswaran   When Arun Parameswaran stepped into one of his first Scrum Master assignments, he joined a distributed team where everything looked normal from the outside. Meetings were happening, Jira was updated, and work appeared to be moving. Underneath that surface, knowledge was unevenly shared, communication between locations was weak, and trust was not yet strong enough for people to speak openly. Arun's first instinct was to add more structure: more meetings, more activities, more process. Looking back, he saw the real mistake. He was creating activity, not progress. The shift came when he stopped trying to provide answers and started listening through one-on-one conversations. He learned where people were struggling, what they expected from him, and what the team needed to own for itself. In this episode, Arun shares why Scrum Masters must understand people before changing the process, and why the best coaching often starts by asking better questions.   Self-reflection Question: Where are you adding process today because the real issue feels harder to talk about?   [The Scrum Master Toolbox Podcast Recommends]

Joshua McDonald: Product Owners Earn Team Loyalty By Showing Up, Learning, And Deciding The Great Product Owner: Vulnerable Enough To Learn The Technical Details 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've seen developers be fiercely loyal to their product owner who makes that type of effort." - Joshua McDonald   Joshua describes the great Product Owner as someone who connects with the team even without a technical background. They do not pretend to know everything. Instead, they get into refinement with curiosity, write stories with the developers, and say, "I think this is what needs to be done, but correct me if I'm wrong." That vulnerability creates a strong partnership. Developers see the effort and often respond with loyalty, to the point where they may refuse to continue important discussions without the Product Owner in the room. The lesson is useful for Scrum Masters coaching Product Owners: deep technical expertise is not the entry ticket. Presence, curiosity, and the willingness to learn with the team are what create trust.   Self-reflection Question: How does your Product Owner show the team they are willing to learn the product with them? The Bad Product Owner: The Dependent Note Taker Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Sometimes you ask the product owner, you're the bus driver, where do you want us to go? And they say, let me go talk with the product manager." - Joshua McDonald   The Product Owner anti-pattern Joshua highlights is the dependent PO: the person who shows up as a note taker rather than a decision maker. This often happens when a Product Manager sits behind the PO and every decision has to be checked elsewhere. The day-to-day symptoms are easy to spot: camera off, muted, disconnected, asking people to repeat questions, missing meetings they scheduled themselves, and leaving the team without timely answers. Joshua's coaching response starts with one-on-ones, support, and curiosity. He asks how they are doing, what support they need, and what signals would help the team see they are engaged. When the product feels too technical, he sits beside them, learns with them, and helps them build confidence instead of leaving them exposed.   Self-reflection Question: Where is your Product Owner dependent on someone else for decisions, and how is that affecting the team?   [The Scrum Master Toolbox Podcast Recommends]

Joshua McDonald: Scrum Master Success Means People Feel Heard, Respected, And Safe To Speak 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.   "I hope you can feel heard and respected at the end of the day." - Joshua McDonald   Joshua defines Scrum Master success through the team's comfort with self-organization, respectful pushback, and asking for help when they do not know what they do not know. For him, a successful team is not drama-free because nothing hard happens. It is low-drama because people can raise problems without fear, communicate openly, and keep moving forward even on bumpy roads. Joshua keeps himself honest by reviewing retrospective notes, one-on-one notes, and the commitments he made to follow up. He keeps a running to-do list from Slack messages, meetings, and team conversations so feedback does not disappear after someone shares it. Periodically, he brings past retrospectives back to the team and asks what they accomplished, what changed, and whether anything fell through. That ledger matters because Scrum Masters work through people. If people feel heard and respected, they are more likely to keep working with you, regardless of your title.   Self-reflection Question: What system do you use to make sure team feedback turns into visible follow-up? Featured Retrospective Format for the Week: Personalized AI-Themed Retrospectives Joshua's favorite retrospective format is never using the same format twice. He noticed teams getting bored and agitated when the same sailboat or standard board appeared every sprint. His answer was to personalize retrospectives around team members' interests: a BMW theme for a developer who liked cars, a beach theme after someone's vacation, or a TV-show theme tied to a person's hobby. He uses tools like Mural, Zoom whiteboards, Microsoft Teams, and AI-generated visual themes to make each retro feel like it was designed for someone in the team. The point is not decoration. The point is listening. When people recognize their interests in the retro, they feel seen as people before they reflect on the work.   [The Scrum Master Toolbox Podcast Recommends]

Joshua McDonald: Using Cycle Time As A Storyteller, Not A Scorecard In Agile Retrospectives 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.   "Metrics is not about telling people do better. It's about telling that story." - Joshua McDonald   Joshua brings cycle time as his biggest current coaching challenge. The problem is familiar: when a Scrum Master points to a story with high cycle time, developers can feel blamed, even when the intent is learning. Joshua reframes the metric as a storyteller. Instead of asking why someone took too long, he asks what journey the story went through, where it changed hands, where it waited, and what the team now knows that it did not know at the start. He also describes practical tactics: warn people in advance before discussing specific stories, keep the language gentle, avoid forcing people to explain themselves publicly, and sometimes skip the metric conversation entirely when the team needs encouragement more than analysis. Metrics matter because they move coaching away from gut feeling and toward observable patterns. Used well, cycle time becomes a barometer for stress, bottlenecks, missing product owner review, and places where the team needs support.   Self-reflection Question: How do you introduce metrics so the team becomes curious about the system instead of defensive about individual performance?   [The Scrum Master Toolbox Podcast Recommends]

Joshua McDonald: The Distributed Agile Team That Hid Problems Behind Follow-Up Stories 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 started to separate and call each other out, which is definitely not Agile." - Joshua McDonald   Joshua shares the story of a 17-person distributed team spread across time zones, cultures, and communication styles. Some team members were direct and ready to challenge problems in public. Others preferred quieter, one-on-one conversations. Over time, those differences created a blame environment where people stopped asking for help and started hiding problems. Long-running work was closed and replaced with follow-up stories, then part two, then part three, until the real issue disappeared under Jira housekeeping. The result was not better flow, but delayed learning, missed upskilling opportunities, and a stressful team environment where quieter people stopped speaking in standups and retrospectives. Joshua explains what he would do differently now: split the team by communication patterns, listen to what each group needs, act as a mediator, and only bring the whole group together once people feel heard.   In this segment, we talk about different communication styles.   Self-reflection Question: What signals tell you that people are hiding problems because the team environment does not feel safe enough? Featured Book of the Week: Never Eat Alone by Keith Ferrazzi Joshua recommends Never Eat Alone by Keith Ferrazzi because it reframed networking as a relationship practice, not a transaction. The book helped him see that staying connected with people creates learning, support, and a safety net over time. He also mentions the Bible as a daily source for reflecting on respect, peace, and conflict resolution, especially because Scrum Masters often need more than process knowledge to help teams work well together. For Joshua, both recommendations point to the same deeper idea: our work improves when we treat relationships as something to maintain before we urgently need them.   [The Scrum Master Toolbox Podcast Recommends]

Joshua McDonald: When Your Agile Enthusiasm Creates Resistance, Start With 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.   "Don't assume they're as enthusiastic about Agile and Scrum as you are." - Joshua McDonald   Joshua McDonald joins us from the USA with a failure story many Scrum Masters will recognize: stepping into a team and assuming the role, the expectations, and the Agile conversation were already understood. The team had worked with a hands-off Scrum Master before, so Joshua's attempts to facilitate events, talk about metrics, and bring more structure were received as interference. The pushback grew so strong he sensed people were talking to his manager about removing him. The turning point came when Joshua stopped leading with Scrum language and started rebuilding social equity through one-on-ones. He asked what he could have done differently, acted on the feedback, and reminded himself and the team to assume positive intent. His lesson is direct: when we join a new team, trust is the work before the work. Go slow, understand how people operate, and bring suggestions through relationships before bringing them to the whole room.   Self-reflection Question: When you join a new team, what do you do first to understand their relationship with Scrum before you suggest changes?   [The Scrum Master Toolbox Podcast Recommends]

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

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

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

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

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

Havva Sevay: From "Scrum Master Is the Secretary" to True Co-Leadership 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 Co-Leader Who Mastered the PO Stances 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.   "Co-leadership means both sharing leadership in a lateral way, not a disciplinary way—the PO owns the technical part, the Scrum Master the organizational part." - Havva Sevay   Havva's best Product Owner already understood co-leadership—and went further. He used the Product Owner stances from Scrum.org as a feedback tool, asking the team to rate him on each stance (customer representative, company representative, and so on) with a percentage, then using that input to improve his skills deliberately. It's the same mindset Scrum Masters can adopt with their own stances: be aware of the options, get honest feedback, and adapt to the context, because the right stance changes over time. A great PO, in Havva's experience, treats their role as a skill set to be developed in partnership—not a title to defend.   Self-reflection Question: Could the PO stances become a feedback tool in your team—and would you be willing to be rated on your own Scrum Master stances? The Bad Product Owner: "The Scrum Master Is My Secretary" 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 worst is the PO who believes he's the product manager and the Scrum Master is the secretary. I said: I'm not your assistant, I don't bring your coffee." - Havva Sevay   The worst anti-pattern Havva has lived through is the Product Owner who treats the Scrum Master as a secretary—there to share the screen, organize the meeting, and take orders. Havva confronted it directly in a one-on-one: this is upside down. My job is to teach self-organization, not to be your assistant. But she didn't stop at the boundary—she helped the PO understand her role and walked in his shoes too, even sending him to a Scrum Master training while she experienced his responsibilities. Her strongest recommendation: from the very first meeting with a Product Owner, talk explicitly about who does what, surface expectations, and agree how you'll work together. Don't assume they know your job—or that you know theirs. The way out of the "secretary" trap is co-leadership: lateral, shared leadership built on time and trust.   Self-reflection Question: Have you ever explicitly agreed with your Product Owner on who is responsible for what—or are you both operating on untested assumptions?   [The Scrum Master Toolbox Podcast Recommends]

Havva Sevay: Success Is Feedback, Not Metrics—And the Power of Standing in Someone Else's Shoes Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "My success is not metrics or numbers—that was my controller past. I measure myself through feedback, and through team satisfaction." - Havva Sevay   As a former project controller, Havva could have defined success in numbers. Instead, she measures it through feedback and team satisfaction. As long as people keep talking to her—telling her how she can be a better Scrum Master—she considers that success, and she treats even hard feedback as learning. But the most striking part of her definition is the discipline of standing in someone else's shoes. When a developer suggested she'd give better advice if she understood programming, she took the Scrum Developer training—the hardest training she's ever done—just to feel the team's daily reality. Vasco connects it to coaching a team that builds tools for other teams: the role isn't to produce the system, it's to make the other teams' lives easier. Havva's takeaway for every Scrum Master: put your shoes in a different position. Understanding the work from the other person's perspective is what drives team success.   Self-reflection Question: How do you measure your own success as a Scrum Master—and when did you last experience your team's work from their perspective?   [The Scrum Master Toolbox Podcast Recommends]

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]