Podcasts about scrum masters

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]

Last week was frameworks for agility in general. This week Kate Megaw, Anu Smalley and Ryan Smith put the best known one under the microscope. They walk through where Scrum came from, why Ken Schwaber and Jeff Sutherland waited fifteen years to write it down, and what the new Simple Guide to Scrum from Bob Hartman and Tobias Mayer changes. Kate makes the case for the 2020 switch from roles to accountabilities, and it turns out the three hosts cover all three of them between them. Then the can of worms: can you implement Scrum partially? From there it is Product Goals as Scrum's answer to OKRs, why so many teams cannot write a Sprint Goal, why the Sprint itself counts as an event, and the two events teams struggle with most: the Sprint Retrospective and the Daily Scrum. This episode closes with the line of the week, borrowed from a PMI colleague. Think big, do small, iterate often.

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]

Neste episódio, conversamos com o Luciano Oliveira e Luiz Felipe Gonçalves (Foca) para entender como a agilidade pode ir além de Scrum, cerimônias e frameworks para realmente gerar resultados para o negócio. Vamos discutir o papel do Scrum Master, os desafios de conectar times de tecnologia aos objetivos da empresa e como medir se uma transformação ágil está, de fato, trazendo valor.

BONUS: Why AI Is Agile's Best Use Case With Melissa Reeve AI is often framed as a technology rollout, but Melissa Reeve makes a different case: organizations that already know how to learn, adapt, and improve are better prepared for AI. In this BONUS episode, we connect Lean, Agile, DevOps, and AI-native work, and explore why Scrum Masters may be closer to the center of AI adoption than they think. From Toyota Production System to AI-Native Work "I didn't really have words for what would later be my career. I didn't know about systems thinking. I didn't know about this thing called Agile."   Melissa traces the through-line from studying the Toyota Production System in Tokyo, to early Agile marketing, to developing intellectual property at Scaled Agile, and finally to AI. Her point is that Lean, Agile, and AI-native work are not separate conversations. They all depend on sensing what is happening, shortening feedback loops, learning from reality, and improving the system instead of only optimizing individual tasks. The DevOps Lesson for AI Adoption "People go from doing the task to building, monitoring, and maintaining the automations that do the task."   Melissa's AI turning point came after ChatGPT arrived in November 2022. At first she was skeptical, then she started seeing end-to-end marketing workflows that could be changed with AI. That reminded her of the DevOps shift, where software teams moved away from throwing work over the wall and toward automated testing, deployment, and delivery pipelines. For Scrum Masters, the lesson is practical: AI is not only about automating Jira tasks or writing user stories faster. It changes the workflow, the roles around the workflow, and the learning loops that keep the work useful. Scrum Masters as AI Change Leaders "What are Scrum Masters really good at? They're good at helping teams adopt new ways of working."   Melissa sees a positive opening for Scrum Masters and Agile coaches. Organizations have bought AI licenses and told people to experiment, but many leaders are still unclear about how AI should change real work. Scrum Masters already work with flow, bottlenecks, experiments, psychological safety, and improvement backlogs. That gives them a useful place to start: map one or two workflows with the team, clarify decision rights, identify where AI can remove or improve steps, and surface concrete wins that others can learn from. From Linear Organizations to Hyperadaptive Work "A hyperadaptive organization compresses both of those dimensions."   In Hyperadaptive, Melissa contrasts linear organizations with hyperadaptive ones. Linear organizations move through strategy, execution, concept, and delivery with many handoffs and delays. Hyperadaptive organizations compress those delays by organizing around value, distributed decisions, and continuous learning. She points to Tomorrow.io as an example of an AI-native company that could run a much smaller marketing team because workflows were designed differently from the start. She also uses Moderna to show the other side: a large pharmaceutical company using AI to pursue a goal that would be impossible under normal industry timelines. Learning Loops, Communities of Practice, and the Retrospective Backlog "We surface our backlog of improvement items and there they sit."   For Scrum Masters, Melissa brings the conversation back to familiar territory: communities of practice, retrospectives, and improvement backlogs. Moderna's AI rollout included ways to identify power users and spread learning through a community. Scrum teams already have the bones of that system, but the weak point is often follow-through. Teams identify improvements, then lose track of them. Melissa's challenge is to use AI to manage those learning loops better: keep improvement items visible, help prioritize them, watch capacity, and make sure learning from retrospectives turns into action. The FOCUS Framework for Choosing AI Use Cases "Is it organizational? Does it fit with your organizational goals or your team goals? Or is it just a random act of AI?"   Melissa uses the FOCUS framework to help teams choose high-value AI work instead of chasing every new possibility. Fit asks whether the idea connects to team or organizational goals. Organizational pull asks whether others will use it, or whether it is a one-person tool. Capability checks whether the team can actually build it. Underlying data asks whether the data is good enough. Success metrics ask how the team will know the AI initiative made a difference. This is a natural fit for Scrum Masters because it connects AI adoption to value, capacity, and inspect-and-adapt thinking. The Five Stages of AI Adoption "AI learning is social learning, and we need to harvest the learning from each other and spread it."   Melissa outlines five stages of AI adoption. Stage 1 is foundation: named AI leads and AI councils. She warns against assuming the best power users are automatically the best AI leads, because the role needs change-agent skills. Stage 2 is AI augmentation, where teams examine workflows and build support structures such as an AI Activation Hub. Stage 3 is automating end-to-end workflows. Stage 4 is scaling those automations. Stage 5 is interconnected value streams driven by AI and AI telemetry. Stages 3 and 4 are the messy middle, because jobs shift, roles change, and organizations move from functional silos toward value-stream orientation. AI, M-Shaped Skills, and More Complete Teams "I'm hopeful that in the age of AI, with these adjacent competencies, that we can create more complete teams."   Vasco and Melissa connect AI-native work with the idea of M-shaped people: people with deep skills in some areas and useful range across others. Melissa notes that AI can unlock adjacent competencies, making it easier for teams to cover skills that used to require fractional specialists. For Scrum Masters, that means the future is less about defending a title and more about understanding durable skills, purpose, and the contribution they can make as team boundaries and role boundaries keep changing. About Melissa Reeve Melissa Reeve is the author of Hyperadaptive: Rewiring the Enterprise to Become AI-Native. She's worked with the Toyota Production System, Agile marketing, and executive leadership at Scaled Agile. She helps organizations move beyond AI pilots by building the human, learning, and operating-model capabilities needed for AI-native work at scale. LinkedIn   You can link with Melissa Reeve on LinkedIn and learn more about her work at Hyperadaptive Solutions.

Matthew Hodgson, founder of Zen X Machina, joins Dave West to unpack the Raptors project, an experiment that started by accident during digital transformation work and grew into a working model for agentic teams. Hodgson explains how he built a cross-functional AI team, complete with a Scrum Master agent named Al, and what it took to get the agents to self-organize, adapt sprint by sprint, and catch their own mistakes. The conversation digs into why explicit governance files matter more with agents than with humans, where agents still need human oversight, and why traditional governance models move too slowly for agentic AI. Hodgson also previews ideas from his book, Evolve, on adaptive governance for modern product operating models.Access the whitepapers that cover the experiment and learnings.

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: From AI Curiosity to Practical Project Tools With William Davis AI becomes useful when it moves from generic answers into the daily work of solving real problems. In this BONUS episode, William Davis shares how he started building his own AI-assisted project management tools, what went wrong when the code grew too fast, and how Scrum Masters can use AI more carefully at individual, team, and project levels. When AI Stops Being a Curiosity "I really need to get a handle on how to productively use AI in my job."   William's shift started with a familiar problem: release plans are full of uncertainty, but stakeholders still need to understand what might happen and when. Instead of handcrafting uncertain delivery ranges in Excel, William used AI to build a desktop application that created probabilistic Gantt charts. In his work, these were not traditional command-and-control schedules. They were release plans that showed stakeholders a realistic range of possible delivery dates, making uncertainty visible instead of hiding it behind a false promise. The Euphoria and the Crash "Anybody can prompt an app into existence, but if you want an app that is actually enterprise-worthy, it does take a little bit of software engineering knowledge to know what questions to ask."   The first experience felt almost magical: ask questions, get code, assemble the pieces, and see a working application appear. But the magic faded when William kept extending the tool and the code started breaking in familiar ways. The AI forgot previous decisions, repeated mistakes, and produced a growing mass of tangled code. The lesson was direct: AI can move fast, but it still needs architecture, tests, and software engineering judgment. Without that, teams can build quickly and still end up with something hard to use, hard to maintain, and hard to trust. AI as a Partner Inside the Tool "The collaboration has a third partner, the AI."   William's work expanded from one application to several tools for forecasting, story mapping, release planning, and budgeting. The more interesting change was not only using AI to build tools, but building tools that could connect to AI while people used them. Through Model Context Protocol, William's tools can work with an LLM partner to help teams turn rough product ideas, emails, and scattered artifacts into structured story maps. The team still edits, challenges, moves, splits, and reframes the result. AI helps create a first model faster, but the team keeps responsibility for meaning and decisions. Security Starts With Where the Data Lives "Start with the easy sell: I'm building a tool, and the data that I'm creating is stored locally on your employer-managed device."   William is clear that AI adoption in organizations cannot ignore infrastructure and cybersecurity concerns. His first approval path came from designing tools that default to local storage in the browser, on an employer-owned and managed device. That made experimentation easier because sensitive project data did not need to leave the company environment. For teams using MCP or company AI platforms, the same question matters: where is the data going, who governs it, and what agreements protect it from being used for model training? Scrum Masters and software leaders need to treat security as part of the coaching conversation, not as an afterthought. Better Questions, Earlier in the Work "My goal is to solve the problems that I have at the moment that I'm having them."   For William, AI changed the work by removing delays between seeing a problem and trying a solution. A release forecast that once took 30 minutes to handcraft can now be updated in a few minutes during the team conversation. In a cloud ERP evaluation, AI allowed him to ask vendor-specific timeline questions much earlier than before. Instead of waiting deep into an RFP process to discover how different solutions would change the implementation plan, he could compare likely timelines upfront and make the trade-offs visible sooner. Go Slow to Go Fast With AI "Ask three different sessions the same question."   One of William's strongest warnings is that a single LLM answer can feel more certain than it really is. LLMs are probabilistic, and the same prompt can produce different answers across models or sessions. His workaround is to slow down the design step: ask multiple sessions or models to analyze the same problem, then use an orchestrator session to compare the answers and improve the design. For architecture questions, he may use Claude, ChatGPT, Grok, and Gemini. For smaller product improvements, he uses multiple sessions inside one LLM ecosystem. This is not a return to big upfront design. It is short-cycle research, planning, and implementation, repeated in small increments. A Practical First Step for Scrum Masters "Rather than just read about how to use AI, just start using it."   William's practical advice is to choose one real problem and ask your LLM how to approach it. If you are not familiar with MCP, start there: ask your preferred model how to connect to a tool through MCP, and experiment with a low-risk use case. William also invites listeners to try the free tools at SPERT Suite, where the default local mode keeps data on your own device. His broader point is simple: AI becomes useful when it is connected to a specific work problem, a clear feedback loop, and a human who still owns the judgment. About William Davis William Davis is a seasoned IT professional with four decades of experience as a software developer, project manager, and agile advocate. A certified Scrum expert and PMP, he promotes personal and organizational agility, delivers customized training, and mentors agile practitioners. Creator of Statistical PERT® and SPERT® Suite, William innovates with free, AI-powered project management tools for today's agile teams.   You can link with William Davis on LinkedIn and explore William's free tools at SPERT Suite.

BONUS: How Scrum Masters Can Use AI Without Losing the Human in the Loop AI makes it easier than ever to build software, prototypes, courses, and coaching tools. In this BONUS episode, Mike Lyons and Greg Pfister share what that speed changes for Scrum Masters, why product judgment becomes more important, and how coaches can start using AI without outsourcing the conversations their teams still need. When AI Stops Being a Curiosity and Starts Saving Real Time "It's not that the work is wrong or not needed, it is needed. That's an important step. Retrospectives are critical."   Greg's first practical AI moment came while trying to build an "Ask Mike" capability for self-paced courses. After a frustrating outsourcing attempt, he started using ChatGPT to help him rebuild the tool himself, eventually moving into Cursor, Claude Code, and the Superpowers plugin for Claude Code. Mike's moment was less technical: using AI inside Mural to affinity-map retrospective notes. The lesson for Scrum Masters is not that AI removes the work, but that it can remove enough friction to let facilitators spend more time on judgment, listening, and follow-through. The Bottleneck Moves From Building Fast to Building the Right Thing "The cost to produce prototypes for software engineering is approaching zero."   Mike and Greg argue that AI does not create the "wrong feature" problem, but it makes the problem much easier to multiply. If a prototype can appear before lunch, the old excuses disappear. Teams still need to ask whether the customer problem is real, whether the payoff matters, whether there is proof from users or data, and whether this work deserves priority now. For Scrum Masters and Agile coaches, this is a clear invitation to help Product Owners slow down the decision before accelerating the delivery. Building AskMe With AI as the Engineering Partner "I'm really playing product manager. That's really what I'm doing."   Greg describes AskMe as an AI-enabled coaching tool embedded into training courses. Instead of asking learners to pass obvious multiple-choice quizzes, AskMe asks them to apply what they learned to their own context, then reflects back practical coaching based on the course material, instructor context, and learner profile. In their own product development, Greg uses AI as an engineering partner while Mike keeps asking the product question: should we build it? Their 4P lens is simple: problem, payoff, proof, and priority. The Scrum Master Role Becomes More Important, Not Less "Don't just outsource your brain, your decision making power."   When leaders push teams to "adopt AI," Mike warns Scrum Masters not to let the tool become the decision maker. AI can cluster retrospective notes, summarize long threads, propose learning plans, or help prepare for a hard conversation, but the human still needs to inspect the output and understand the consequences. Greg adds the practical security angle: teams must be careful about what they paste into AI systems, especially personal, customer, or sensitive company information. Start Small: Context, Role Play, and Shared Learning "Context is king when you're talking with your AI."   Greg suggests starting with basic AI training, then practicing with small workflow improvements: prioritizing work, summarizing material, or drafting communication that the Scrum Master then edits. Mike's practical starter experiment is role play: describe a difficult team situation without names, ask the AI to act as the other person, and practice the one-on-one conversation. Vasco adds a simple working habit: keep a running context file with meeting notes, team insights, worries, decisions, and open questions, then use that context when asking AI for help. Resources for Scrum Masters Learning AI "Let AI help you get smart about AI."   Mike recommends the PMI AI in Project Management learning resources and the 37signals Rework podcast for pragmatic thinking about how AI fits into work. Greg recommends learning directly from the AI tool providers, exploring how to configure projects and context, and reading Marty Cagan's Inspired to strengthen the product judgment that becomes more important when teams can build faster. About Mike Lyons and Greg Pfister Mike Lyons and Greg Pfister are the team behind KaiRise, where they've used AI to build new products, including AskMe, an AI coaching tool, and to create their most recent certified Product Management training course end-to-end.   Greg Pfister works with Mike at KaiRise on AI-enabled learning products, including AskMe and their certified Product Management training course.   You can link with Mike Lyons and Greg Pfister on LinkedIn. You can find KaiRise and AskMe at kairise.com.

The last three weeks were the mindset: the Agile Manifesto and its 12 principles. This week Kate Megaw, Anu Smalley and Ryan Smith move on to the frameworks that help you live it.  Anu starts with the difference between a mindset, a framework and a methodology, and a picture frame analogy that does a lot of work for the rest of the conversation: change the picture as often as you like, but saw a side off and it is no longer a frame.  From there it is how organizations choose between Scrum, Kanban and XP (Ryan's honest answer: most default to Scrum because it is the only one they know), the questions each host asks a client before recommending anything, and why Kate once ran Scrum and Kanban side by side with the same team.  Then the Business Agility Institute framework for the leaders who shut down at the word Scrum, the scaling frameworks and the ones that quietly faded.  It closes with four questions to ask before you adopt anything, starting with the one that matters most. What problem are you trying to solve?

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

How to Handle Conflicting Stakeholder PrioritiesMarketing wants it faster.Finance wants it cheaper.IT wants it safer.Operations wants it stable.And the customer?They just want something that actually solves their problem.

"L'IA propose, l'humain décide." Le D.E.V. de la semaine est Salim Gomri, coach agile et coach professionnel d'organisation certifié. Fort de 23 ans d'expérience, il est aussi l'auteur du Système S.A.L.I.M. (Scrum Augmenté Livré Incrémental & Mesurable), un framework sur Scrum Augmenté disponible sur aigile.lu. Il revient sur l'impact de l'IA sur le manifeste agile et présente son AIgile Manifesto, une version augmentée du manifeste agile face à l'accélération IA. Ensemble et sans langue de bois, nous explorons comment les cycles, les cérémonies et surtout le rôle du Scrum Master évoluent face à l'accélération permise par les outils d'IA.Un échange riche pour repenser la vélocité, la valeur et surtout, ce qui devient vraiment critique : la place de l'humain dans des équipes ultra-augmentées.Chapitrages00:01:02 : L'IA bouscule l'agilité00:03:40 : Manifeste agile augmenté00:09:52 : Vélocité ou piège00:14:22 : Spikes et granularité00:19:29 : Faut-il raccourcir les cycles ?00:28:08 : Contrôle et transparence00:28:25 : Stories, features et valeur00:31:46 : Le daily change de sens00:37:22 : Planning à l'ère de l'IA00:43:45 : Review, pas seulement démo00:49:41 : La rétro, moteur d'amélioration00:54:30 : Scrum Master indispensable01:00:51 : Livre et recommandations Liens évoqués pendant l'émission Les 4 accord toltèques

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]

Last time it was the WHO: customers, businesspeople, face to face.  This time it is the HOW.  @Kate Megaw, @Anu Smalley and @Ryan Smith finish the Back-to-Basics run through the 12 Agile Principles with numbers 7 through 12, asking the same question of each: what wording would keep someone in legal, marketing, or finance reading?  Working software becomes delivered value in about ninety seconds, no notes.  Sustainable development turns out to be the most ignored principle of the twelve, partly because it says development and partly because people think sustainable means 40+ hours a week.  Technical excellence loses the C-suite at the word technical, and then the three hosts split on whether design has to go too.  Simplicity and the retrospective principle survive untouched, which raises the obvious question of why the retrospective is the first event teams drop. 

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]

Your company cut the Scrum Master role and called it self-organization. Fantastic... Where did the coordination work go? We'll bet it landed on someone who doesn't get paid to do it.Product Manager Brian Orlando and Enterprise Business Agility Leader Om Patel argue through what happens when organizations defund facilitation roles but keep the complex frameworks. Stick with as Brian tries to discern if "let the team figure it out" is really just financial code for a transfer of labor from funded to unfunded and stay till the end to understand how to spot the competence tax on your own team.Listen or watch as we discuss:• Why "automate it with AI" and "let the team self-organize" are the same failure• What is the competence tax: being good at unfunded coordination work• Who non-promotable tasks disproportionately land on and why• How NOBODY EVER accidentally rolled out SAFe and "forgot" to fund rolesIf you're an Engineer, Product Person, Scrum Master, or Agile Coach watching coordination work get quietly dumped onto the wrong people, this episode is for you! I fight for the users!#ScrumMaster #Agile #CompetenceTaxTanya Reilly (Being Glue, Lead Dev talk), Winning with People by John Maxwell, Babcock and Vesterland (gender differences in non-promotable tasks), SAFe, SquarespaceLINKSYouTube: https://www.youtube.com/@arguingagileSpotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596INTRO MUSICToronto Is My BeatBy Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

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]

The 12 principles behind the Agile Manifesto are the most skipped page in agile. Plenty of people can quote the four values.  Far fewer know there are 12 principles sitting underneath, and fewer still could name one. Kate Megaw, Anu Smalley and Ryan Smith continue the Back-to-Basics series by working through the first six, one at a time, asking the same question of each: what wording would make this land for someone in marketing, finance, or HR?  Software becomes value, then the three of them discuss whether value is too vague.  Business people and developers becomes stakeholders and teams, because “I am not a developer” is a very easy way to leave a conversation.  The word project shows up twice and nobody minds anymore, which is a shift from five years ago. And face to face gets a defense from Alistair Cockburn that is worth quoting the next time someone tells you a remote team cannot do it.  The point is not a new set of principles. It is that people shut down when the words do not fit their world, so hand them words that do.

BONUS: Why Software Projects Fail When Everyone Keeps Quiet Software projects rarely fail because no one noticed the problem. More often, people see the missing database, the wrong assumptions, the broken process, or the weak product ownership, but the organization has trained them to stay quiet. In this BONUS episode, Mark Stringer, author of Delivering the Impossible, helps us understand how Scrum Masters can make reality visible again. The Problem Of Intention In Software Projects "You've got here a problem of intention, and you can't fix that by coming up with new, more magical marks on the page."   Mark starts with a story from the mid-1990s, before Agile was a common word in software teams. In a software development course, he heard the familiar promise: if only requirements could be captured with the right notation, the project would go correctly. His reaction was different. Software is not only a problem of documentation or process, it is a problem of translating intent into reality. That gap between marks on a page and what people actually need is where many projects begin to drift. Point Of View Can Make Smart People Miss Reality "If we see things in the wrong way, then point of view can take 80 IQ points off us."   Mark uses Alan Kay's idea that point of view is worth 80 IQ points to explain why good people can still make poor project decisions. A methodology can help, but only if it helps the team see what is actually happening. When the model becomes more important than reality, teams start defending the plan instead of learning from the system they are trying to change. Scrum Masters can help by asking what the current point of view hides, not only what it explains. The Swamp: Why Project Complexity Is Not On The Diagram "The fastest way between two points in a real organization is not necessarily a straight line."   In one banking project, Mark found two realities that had not survived the diagrams. First, a transaction database shown on every architecture diagram did not exist. Second, after six months of requirements work and several million pounds spent, a simple show and tell revealed that the design was organized around accounts when stakeholders needed it organized around people. The point was not that the team had failed to write enough requirements. The point was that the real environment was a swamp of legacy systems, power shifts, competing groups, regulations, users, and assumptions. You only discover that swamp by starting, showing real work, and letting stakeholders react. Agreed Activity: When The Rituals Keep Going But The Project Is Already Lost "Everybody knows why the project's failing. It's not a mystery at all."   Mark calls one common failure mode "agreed activity." The team keeps attending standups, planning meetings, status reviews, and retrospectives, even when people privately know the project is not going anywhere. Often they have tried to raise the real issue before and were punished for it. After that, silence becomes rational. The organization keeps reporting activity, expenditure, and compliance with the process, while the real blockers stay untouched. For Scrum Masters, this is a warning: ceremonies are useful only when they let reality enter the conversation. Product Ownership, Bad News, And The Message Leaders Send "The message that the development team hears is: don't rock the boat, just keep taking the money."   The Product Owner role can help break agreed activity, but only if the person has enough authority to make decisions and enough proximity to the team to learn. Mark describes two common anti-patterns: appointing someone junior who can be pushed around, or appointing someone so senior they have no time for the work. Worse, when someone points out a fundamental problem and gets metaphorically shot, the team learns the real rule: stay quiet. Leaders may think they are asking for positivity or commitment, but the team hears permission to cut corners, hide bad news, and treat spending as progress. Make Scrum A Hypothesis Testing Framework Again "That kind of unexpected feedback, that's the hope. That's the machine working."   Mark's practical advice is to keep the cadence, but make the meetings real. A show and tell should expose assumptions. A retrospective should make uncomfortable feedback usable. Scrum works best when it is treated as an empirical, hypothesis-testing framework, not a list of meetings to implement. Mark also points to user research as a way to extend learning back into the environment. Teams cannot guess how users will react, which buttons they will press, what they will ignore, or what market and organizational changes are shaping the work. They have to test, learn, and adjust. About Mark Stringer Mark Stringer is the author of Delivering the Impossible, a 2026 Apress book on better ways of seeing software project management. He has spent 30 years in software delivery as a developer, application researcher, and project manager, working with IBM, Xerox, and Cambridge University.   You can link with Mark Stringer on LinkedIn and follow Mark's writing at markstringer.github.io. You can find Delivering the Impossible on Amazon and Springer.

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.

BONUS: How Scrum Masters Turn AI Into a Thinking Partner, Not a Magic Answer Box Everybody talks about AI in theory. In this BONUS episode, Dave Westgarth talks about it in practice — the boring, everyday ways a Scrum Master and Agile Coach actually puts AI to work. From t-shirt sizing to sprint reports to a self-coded Monte Carlo forecaster, Dave shares what works, what doesn't, and the one mindset shift that separates people who get value from AI from those who just generate more noise. From "Magic Answer Box" to Personalised Partner "Instead of taking it as a magic answer box, using it as a personalised partner to work through problems, look at your ideas, and really hold them in the cold light of day before proposing things."   Dave came into agile from a development background, moved through project delivery, and had already worked at AI and ML companies long before ChatGPT made the technology personal and accessible. Like most people, he first met these tools as a "magic answer box" — ask a question, get an answer, run with it. The real shift came when he stopped optimizing for output and started using AI to drive better outcomes: ping the model, get a response, then interrogate it, refine the thinking, and go around again. The value isn't the first answer. It's the conversation that sharpens your own reasoning. These Tools Aren't Neutral — So Corner Them Into Being a Critic "If you ask it to be punishing, negative, and brutal, it gives you a lot more relevant feedback."   One of Dave's sharpest points: AI tools are not neutral guides. Because of their system prompts and the incentives baked in by the providers, they're relentlessly positive — they want to affirm you and keep you around, a little like social media. That makes them weak for anything where you need honest pushback: personas, user stories, feedback on ideas. Dave's fix is to flip it on its head. Rather than asking "is this any good?" (which reliably earns an "8 out of 10, but to make it a 10…"), he tells the model to be as harsh and brutal as it can and really try to punish the idea. You don't want a partner that always agrees with you — you want one that pinpoints the areas you haven't thought about. The First Real Time-Saver: Reports, and the Themes You Missed "Are there any themes that have emerged over the last 4 weeks that I might have missed in this latest deck?"   The first thing that stopped feeling like a party trick was the one we all know: project documentation and reporting — sprint reports, status updates, review decks. Instead of letting AI invent the structure, Dave feeds it his own structure plus Teams recordings, notes, and existing docs, and lets it populate the format he already uses. The trick that goes a level deeper: after several sprints, feed all the AI-assisted reports back in and ask what themes have emerged across the last four weeks that this latest deck might have missed. Again, it stops being an answer box and becomes a partner and critic. AI Is Part of the Job Now — Like Spreadsheets Once Were "The way to get ahead now is figure out how to use it as effectively as you can in your role."   Dave sees the early resistance movement against AI as a false economy. For delivery professionals — project managers, Scrum Masters, agile coaches — knowing how to use these tools well is fast becoming a core expectation, not a nice-to-have. Vasco draws the parallel to spreadsheets: once dismissed as too complicated and "not my kind of thing," until people started building real forecasting and capacity models with them and the work changed. AI is on the same arc — still a little mystical today, genuinely useful tomorrow, and eventually just another tool in the box. A Week With AI in the Loop "The power that these prompt-to-product tools give you to create these hyper-personalized tools that make you more effective is, in a lot of ways, magic."   Dave walked through what his week actually looks like with AI in the loop:   Monday primer: a scheduled ChatGPT task emails him a scene-set every Monday — last week's plan and top priorities — so he isn't spending the first half hour reconstructing where things stood. Priority calls: which items are the toughest, where the quick wins are, where he can get early traction, and where risks might be emerging that he can squash early. Everyday comms: drafting the bones of emails, pings, and project updates so he spends almost no time formatting. Prompt-to-product tools: using Base44, Lovable, and Replit to build his own tools — including a Monte Carlo forecaster that takes his team's sprint throughput and projects the remaining backlog, replacing an ugly spreadsheet with a clean web app. He also builds AI-powered widgets in Miro for retrospectives, mood check-ins, and planning poker.   The theme running through all of it: hyper-personalized tooling, shaped by your team and your own skills, rather than one-size-fits-all software. The Myth That AI Makes Scrum Masters Worse "I can't see any role of a knowledge worker where having an LLM at your disposal makes you less capable, less knowledgeable, less skilled than someone that doesn't."   Dave sees the same adoption spectrum among developers and Scrum Masters — from "I'll never touch it" to "I'll never write code by hand again." And he pushes back hard on an emerging prejudice that echoes the old "technical Scrum Masters are worse" debate: the idea that Scrum Masters who use AI are somehow weaker. Used well, AI lets you elevate your strengths and cover your gaps — a people-centered Scrum Master can become far more technical, and a technical one far more people-centered, each with a trusted teaching guide right there. The key competency isn't avoidance; it's discernment about when to reach for the tool and when not to. From More Output to Better Outcomes "The bottleneck has never really been typing code. The bottleneck has been understanding the problems and the customers well enough to define a solution that fixes them."   Dave's clearest reframe: AI is driving the price of output down. When volume is easy — more features, more emails, more documents on demand — churning out more of it stops being a differentiator, because everyone can do it. What matters is deciding which problems are worth solving and finding the most effective solution. Experienced agile professionals have always known the real bottleneck was understanding the customer well enough to define the right solution, not the typing. AI just exposes that in a much starker way: there's nowhere left to hide behind sheer volume. What to Pay Attention To — and a Monday Experiment "It can do a lot of that manual, low-thinking, high-effort work to free you up to do more of the really impactful stuff."   For Scrum Masters being told to "adopt AI," Dave's advice is to let it take the joyless work — the end-of-sprint collateral, the Jira monitoring, the reports and charts — so you can spend your time on the coaching, the strategic thinking, and the organizational-level impact that's harder to reach when you're buried in tactical chores. His concrete Monday-morning experiment: take the two or three prioritized actions from your next retrospective, bring them to ChatGPT or Claude, and ask, "which of these could you really help me with, and how could you help me move the needle?" Start a conversation. You don't have to accept its answers — the point is to sharpen your own thinking about where you can add the most value next sprint. Developing "Taste" With AI "One element of taste is being able to judge it fairly harshly — getting through the beige as quickly as you can to find the little nuggets and gems."   Both Dave and Vasco land on the same skill for the year ahead: taste. These tools produce a lot of text, and not all of it is useful. Vasco shares his own aha moment — asking for ideas, getting the obvious ones, then repeating "give me more, don't repeat any" until the model finally surfaced something genuinely unexpected. That simple move turns AI into an engine for exploring the solution space until something clicks. The competency to build is the ability to move through the beige quickly and recognize the gems that materially change what you do next.   About Dave Westgarth   Dave Westgarth is a product and Agile practitioner exploring how AI transforms product development, experimentation, and team workflows. He shares practical insights on leveraging tools to accelerate value delivery and innovation.   You can link with Dave Westgarth on LinkedIn and find him in the Miro community and on Miroverse.

BONUS: How Scrum Masters Can Use AI Without Becoming the Human API   AI is already changing the practical, everyday work of Scrum Masters and Agile Coaches. In this BONUS episode, Vasco talks with Fred Deichler about moving from curiosity to real AI-supported workflows: finding team signals faster, preparing better conversations, keeping documentation in sync, and staying focused on outcomes instead of just producing more output. From Automation to an AI Sparring Partner "I have this partner I can work with to help me ideate things."   Fred's journey into AI started before the current AI wave, with automation in Jira and the practical need to surface bottlenecks without manually watching every board. The turning point came when ChatGPT stopped feeling like a search box and started acting like a thinking partner. Faced with a team being pushed toward multiple sprint goals, Fred dumped the context into AI and asked for three to five options instead of one "right answer." That shift helped him move from a deterministic mindset into a problem-solving mindset, using AI to explore options, challenge his own assumptions, and prepare a better conversation with the team. The Monday Morning AI Context Builder "It instantly sets that context for me. It sets that tone for the whole week."   Fred describes his weekly workflow as a very practical use of AI: on Monday morning, he opens Cursor and works with his own AI harness, Atlas. Atlas is built from markdown files containing persona, skills, history, meeting transcripts, notes, and Jira data. When Fred says "good morning," the system pulls the most relevant signals forward: aging work items, backlog health, sprint goals, and where the next team conversation should focus. Instead of starting the week by hunting for data, Fred starts with questions he can bring into the first stand-up: what is stuck, what needs refinement, and what risk is already visible? Making Flow Metrics Visible Inside Jira "If you're on a page, what do you hope you could learn without asking?"   Beyond using AI as a thinking partner, Fred used AI to build a Chrome extension that surfaces useful Jira insights directly where the team already works. On the active sprint board, it shows work in progress, aging items, sprint goals, and sprint changes. In the backlog, it exposes backlog health and epic health. On the sprint report page, it adds cycle time per item so the retrospective can move from generic discussion to concrete learning. The point is not to shame the team with metrics. The point is to make the right conversation easier to start: what caused this item to take seven days, what blocked it, and what do we want to learn from that? AI as Extra Eyes and Ears for Team Conversations "It helps make sure that we don't lose sight of these things I can bring back to the team."   Fred also uses AI agents to review meeting transcripts and look for patterns that are easy to miss in the flow of daily work. The system can notice hesitation, unresolved topics, or a requirement problem that was mentioned once and never followed up. For retrospectives, Fred's Atlas setup can review sprint transcripts around day nine of the sprint and suggest themes for the next retro. It can even generate prompts for a visual retrospective board in Copilot or a Miro board from a prompt. This helps Fred avoid relying only on recency bias and creates a better starting point for the conversation the team actually needs. Keep the Human in the Loop, Especially for Outcomes "It's not about building a faster hammer. It's about identifying the outcome you're going for."   A major warning in the episode is that AI can make Scrum Masters faster at producing more of the same: more notes, more summaries, more documents, more reports. Fred argues that the useful question is not "can we automate this exact process?" but "what outcome are we trying to achieve?" In a Jira-to-Azure DevOps migration, for example, the goal was not to reproduce the current time-tracking process perfectly. The goal was to provide the information accounting needed. That outcome focus keeps the human accountable for direction, judgment, and value, while AI helps explore better ways to get there. The SPOT Framework for Finding AI Opportunities "If it meets three or four of those, this is a great opportunity for an automation to free me up to do that more human-centric work."   Fred uses a simple filter, the SPOT framework, to decide what AI should help with and what should remain human-led. A task is a good candidate when it is simple, predictable, observable, and tedious. Simple means it requires low human judgment and could be explained on an index card. Predictable means it happens repeatedly, either on a schedule or triggered by an event. Observable means the needed data is available to the agent and not locked away in someone's head or behind policy. Tedious means it consumes energy without adding much human value. When a task matches most of those criteria, Fred looks for ways AI can handle the toil while he stays focused on facilitation, coaching, and decision-making. A Small Experiment Scrum Masters Can Try Tomorrow "If a Scrum Master finds himself operating as, like, I'm moving data from point A to point B, that is a great opportunity to say, how might we do this?"   Fred's concrete advice is to start by noticing where you have become the "human API": moving data between tools, updating spreadsheets, copying information into reports, or keeping documents manually aligned with reality. Write down one tedious workflow and ask your approved work AI, "How might we automatically populate this, while keeping me in the loop?" Vasco adds a useful ideation tip: if the first five ideas are not good enough, ask for five more without repetition, then five more again. The goal is not to hand over accountability. The goal is to discover what might be possible and choose one safe, small experiment. Resources for Scrum Masters Exploring AI "It's all about building up your own idea of what's possible to start those how-might-we conversations."   For listeners who want to keep learning, Fred recommends The AI Daily Brief as a way to stay current with what is happening in AI, and Jack Roberts' YouTube channel for practical ideas around personal AI and agent-based workflows. Fred also points listeners to his own work at Triforce Agility, where he shares blog posts, resources, and updates about his talks. He will be speaking at the Kansas City Developers Conference in early September about AI and career progression, and at Scrum Day in Madison, Wisconsin in October about how AI impacts Scrum Master roles.   About Fred Deichler   Scrum Master, Agile Coach   You can link with Fred Deichler on LinkedIn and connect with Fred Deichler at Triforce Agility.

BONUS: How AI Took the Boring Out of Agile Coaching—Where Scrum Masters Should Actually Start, With Michael Dougherty Today we speak with Michael Dougherty — "Agile Mike" — about how a 30-year veteran of solution development and product leadership made AI a working part of his Agile coaching practice. Michael walks us through the journey from early ChatGPT curiosity, to documentation as the first real win, to the personal-passion project that built his comfort with the tools, and finally to where every Scrum Master should start: the retrospective. From Curiosity to Toolbox: A Slow Burn That Started With User Stories "I tried, and I thought it sucked at that. I'd rather write this by hand."   Michael's AI journey started in late 2022 with ChatGPT — like most coaches, he tried to make it write user stories and acceptance criteria. It didn't work. The output wasn't usable, and he went back to writing them by hand. What looks like a failure was actually the first lesson: not every coaching task is a good fit for AI, and the way to find out is to try. He kept experimenting in the background through 2023 and 2024 — Claude, Grok, Perplexity — while keeping personal use and business use cleanly separated. The real shift came at the Department of Homeland Security, where he sat alongside ex-Googlers, ex-OpenAI people, and an Anthropic alumnus on the team building DHS's internal chatbot. Watching what AI could do inside a heavily-protected enterprise environment changed his frame: this wasn't a productivity hack anymore, it was infrastructure. The Boring, Tedious, Now Quicker: Documentation as the First Real Win "AI has taken all those boring, tedious tasks and made them quicker, more valuable, and more fun to boot."   The first AI practice that stuck was documentation — the part of Agile coaching nobody enjoys but every client demands. Michael had spent years writing SDLC docs from blank pages, and his co-author on Shift: From Product to People used to look at empty docs and ask for help getting started. AI removed that blank-page problem. He'd give the model the team context, the client's documentation requirements, and a template — and get a draft to edit. He stayed in the loop as the human, bringing context, judgment, and final shape, but he no longer started from zero. The same shift happened with presentations: instead of fighting PowerPoint spacing, he tells the AI to drop content into a template and gets back a formatted deck. Small tasks, but multiplied across a coaching week, they bought back real time. The Personal Project Trick: Find Something You Love First "Find something you have a passion with, something you really enjoy. That made me feel comfortable with AI so I could do more."   Michael's strongest advice for coaches who feel intimidated by AI isn't to start at work — it's to build something for yourself, in a domain you care about. His own example: the Nordic Metal Tour Tracker, a personal AI agent for tracking heavy metal bands across Northern Europe (and Spain and Portugal). It plays music. It maps tours by country. It exists purely because he loves heavy metal. The trick isn't the tool — it's that working on something he actually cared about removed the fear and built the muscle memory. Once the comfort was there, transferring it to work became a small step instead of a leap. He references the rundown AI as a daily input that keeps him aware of how others — even people in their 80s — are using AI for everything from gardening to balanced school lunches. A Week With Preppy Paul: Agents, Connectors, and the End of Inbox Drudgery "Preppy Paul gives me a list of all my meetings today and the top three items I should have on each one — based on my notes, my email, my calendar."   Michael's current weekly routine looks nothing like his Agile coaching week from three years ago. He works at Zion Cloud Solutions as a Tier 1 Google AI partner, splitting time across three roles: about 20–30% traditional Agile project management (coaching a Scrum Master on a state of Illinois project), and the rest as an AI Growth Engineer and AI delivery lead on short 4–6 week projects with 3–5 person teams. The backbone is Google Gemini Enterprise — a platform that lets him run Claude, ChatGPT, or any major model behind enterprise protection (Model Armor, the SAIF framework). Inside it, connectors pull in Gmail, Outlook, Calendar, Confluence, Jira, Slack, Teams, monday.com, and thousands of other tools — each agent inherits only the permissions the user already has. A few practical patterns he runs every week:   Preppy Paul — an agent that prepares him for the day's meetings, pulling top topics per meeting from his notes, email, and calendar. Meeting-to-email — AI records and summarises every meeting, and he asks the agent to draft updates to specific team members directly from the summary. LinkedIn drafts in his voice — hashtags, formatting, and tone all match his style; he edits lightly and posts.   The pattern across all of these: the agent isn't replacing the work. It's removing the friction between the meeting and the next conversation. The Retrospective: The Best Place for Every Scrum Master to Start "Don't have it be the same darn Jira spreadsheet of the same darn three questions every time. Go to AI and eat your heart out with it."   When pushed for one thing a Scrum Master could try tomorrow morning, Michael was clear: the retrospective. It's the one Scrum event where creativity is usually welcome, where format experimentation has a low cost, and where teams are already expecting something new. Ask AI for retrospective formats that fit the team's current situation — review five or ten options, pick one, run it. The signal you watch for within a week is double: how many improvements the team generated, and how many of them actually got done. The simpler signal is the team's reaction. If at the end someone says "that was fun" — and then you tell them you used AI to design the format — you've shown the team what AI is good for without a single slide or framework. It's the smallest possible experiment with the largest possible upside. Experiment Like a Scientist, Not a Spectator "Don't be afraid of it. Try whatever you can with it. Have the viewpoint of a scientist."   The trap Michael sees most coaches falling into is curiosity without commitment — reading about AI, watching demos, talking about it, but never building anything. His framing is the opposite: be a scientist. Run experiments. Some will fail (his user-story attempt did). Some will quietly become essential (documentation did). The way to find out which is which is to keep trying, in low-stakes contexts, with both personal projects and small work experiments. The coaches who'll be useful to their teams in 18 months aren't the ones who can describe AI accurately — they're the ones who've built enough small things to know what AI is bad at, what it's surprisingly good at, and where the human in the loop has to stay.   About Michael Dougherty   "Agile Mike" has over 30 years of experience with solution development and product leadership, working in nearly every IT role that exists and literally hundreds of companies during his career. Michael has taught multiple Agile courses to over 1000 people, spoken at multiple events and podcasts, written dozens of blogs, and has been recently serving the US Government. He is the other co-author of Shift: From Product to People.   You can link with Michael Dougherty on LinkedIn and find more about his work at shiftingpeople.com and AP8XGlobal.com.

Many Scrum Masters and Agile Coaches have been cut loose, organizations are changing how they deliver products and services, and AI has landed on top of both. Kate Megaw, Anu Smalley and Ryan Smith open a new Back to Basics series with the document that started all of it, the Manifesto for Agile Software Development. They start with the obvious question. If it was written for software, what word belongs there now? Ryan says iterative development. Anu says iterative fill in the blank, because coaching a leader is iterative too. Then they go to the four values and pick favorites, and pretty much land on the same pair. Individuals and interactions, and responding to change, come out as the bookends that give the middle two somewhere to stand. Meanwhile AI is quietly pulling attention back toward the tools on the right and working software and customer collaboration are where teams are slipping.  The close is the useful part. This is not a rulebook to recite at people. It is a short piece of text that gives a team permission to work better.

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]

Every month when we teach the Certified Agile Leader class it opens with the same question: what is your biggest challenge right now? In 2025 the answer was “leading multi generational teams”. This year it is “doing more with less”, and Kate Megaw, Anu Smalley and Ryan Smith take it apart. They cover what the phrase really means, from layoffs and canceled tool licenses to the quiet blurring of the Scrum Master and Product Owner roles, and they name the 2026 version of the argument: four humans plus a handful of agents, surely that equals a team of ten! It does not. If output goes up and outcomes stay flat, waste has gone up, and adding weight to a car whose wheels are already spinning only sinks it deeper. The conversation goes to the real costs, including burnout, quiet quitting, quality shortcuts, and a junior pipeline nobody is filling, then lands somewhere useful. Make the trade offs visible, go back to the basics, and stop trying to do more with less. Do less, better.

BONUS: When Burnout Looks Like Productivity—The Hidden Risk to Your Team's Innovation Capacity In this BONUS episode, Alison Campbell shares the research that reframes burnout as a measurable threat to a team's ability to innovate. We learn why your most productive people may be your biggest innovation risk, how to spot capacity draining out of a team before the output drops, and where Scrum Masters have the leverage to protect the one thing that keeps teams building: the space to think. From the ER to the Research "I kept normalizing the stress, the exhaustion, eventually the stomach aches as, well, this is just the price of entry. This is part of being a busy, full-time executive and working mom."   Alison spent nearly twenty years in corporate roles—moving from finance to e-commerce to HR tech, with analytics as the through line and a love for the building phase inside companies. The pandemic was the turning point. With two young kids at home and a global team to hold together, she pushed through eighteen months of warning signs she had normalized, until severe stomach pain landed her in the emergency room needing surgery. That was the stop moment. What started as private shame—the feeling that she alone had failed while everyone else "had it all figured out"—became a research question the moment she started talking about it and heard the same story mirrored back from colleague after colleague. This wasn't one exhausted mom at a hard moment. It was a design and systems problem worth studying. When Burnout Looks Like Productivity "Even when that innovative work behavior was high, when burnout was high, that segment of our sample had the lowest innovation capacity of the entire group we surveyed."   The counterintuitive finding at the center of the research: activity, busyness, and visible output stayed high even when burnout was high. Burnout doesn't always look like withdrawal, disengagement, or someone who has already collapsed. Often it looks like the person still shipping, still moving fast, still showing up to every meeting—while the deeper capacity underneath quietly erodes. Alison's study measured this through two separate constructs, and the gap between them is the whole point:   Innovative work behaviors — the visible signs of innovation: coming to meetings, generating creative ideas, being present and active. Innovation capacity — the cognitive and strategic bandwidth to hold complexity, make hard decisions, collaborate well over time, and translate ideas into durable, long-term company value.   The people scoring high on visible activity while burned out were exactly the people whose capacity to do the deep work had already dropped the lowest. What Innovation Capacity Actually Is "Not just, am I coming to the meetings, am I visibly showing up—but do I have the ability to translate these ideas into durable, long-term company value?"   This isn't only about product features or new products. Innovation capacity shows up in every layer of the work: the micro decisions, the macro strategy, the processes, the willingness to try a new tool or approach at all. Innovation capacity is present when people have the mental space to be curious, to ask questions, to explore, to want to play with something new. When that space disappears—when the answer to every new idea is "we don't want to hear no, we don't want to hear that there's a problem"—the work turns tactical and reactive. People narrow their thinking and just chip away. That's the moment you stop getting the best from your team, even though they look every bit as busy as before. The Signals to Watch For "Can I name what is blocking progress? Do I feel safe enough to say, this is what's at risk? Or is this a culture where we don't talk about what's not going according to plan, and we just keep our heads down and keep going?"   The conditions most strongly correlated with high burnout and low innovation capacity clustered around a few themes: uncertainty—especially about the role of AI in someone's work—unclear meeting outcomes where a lot of meetings produce little clarity on the next action, and a general cluster of fear and ambiguity. The fix isn't to make everything finite and remove all agility—that's the wrong message in a genuinely uncertain world. It's to provide bounds. Communicate clearly about what you do know and why, so teams can operate confidently even through an uncertain pivot. For Scrum Masters, this maps directly onto AI adoption conversations: when curiosity turns into anger, frustration, or blanket anti-AI resistance, that's a signal worth investigating. Get at the why—both by taking a genuine pulse on the team, and by making sure the team understands the bigger-picture why the whole company is driving toward. As Alison put it, strip it all down and you land on good communication and psychological safety: the conditions where people can name what's blocking them and still do their best work. Fragmented Work and the Myth of the Finished List "It's about baking in periods of rest and reset, and being comfortable with this notion that the list is quite literally never going to be done."   Fragmented work—context switching, too many things in flight, the sprawl of tools and issue trackers—came up as a real innovation-capacity killer, and it's something agile teams can actually measure. The study asked about context switching, interruptions, and how many channels people move between; a deeper follow-up study is now underway focused specifically on AI-driven uncertainty and tool-switching. Alison's guidance isn't "do less and stop switching," because that reality isn't going away. It's to design rhythm into the work: periods of sprint followed by a deliberate pull-back—reflective work, postmortems, space to talk about what didn't go to plan. She didn't put a number on the right ratio of recovery to sprint; it's contextual to the industry, the stage of the business, the size of the team. The leadership move is to look at the actual rhythm of the business, and to proactively plan and openly name the recovery after a big push—instead of treating "recovery" like a bad word. Why Managers Are at Higher Risk "Managers were 1.7 times more likely to experience high burnout—and about three times more likely to say, yes, I delay complex problems or hard decisions."   When the data was split between managers and individual contributors, the extra management layer showed up as a measurable source of additional pressure. Managers reported high burnout at 1.7 times the rate of individual contributors, and were roughly three times as likely to strongly agree with the statement "I delay complex problems or hard decisions"—a direct marker of eroded innovation capacity. There's more to unpack there, and a second paper is coming in September that adds caregiving as a third dimension, building toward a "responsibility index" that looks at how obligations outside of work—an aging or sick family member, for example—compound the burnout picture. For a Scrum Master, the takeaway is that the pressures draining a team's capacity are often invisible from the outside, and they land hardest on the people carrying the most responsibility. One Thing to Start Tomorrow "Not another meeting—but a reflective question first. Rate your energy, rate your stress, and look at where your time actually got spent versus the goals you had."   Alison's concrete recommendation for anyone who suspects something is off: start a weekly check-in. First an individual reflection—rate your energy and stress for the week, and compare where your time actually went against the goals you set. Then bring that same question into a Friday stand-up or retrospective and ask the team to weigh in: what was the team's stress and energy, and were there major constraints nobody saw coming? The first few weeks people may be hesitant to answer honestly. But keep the practice going week over week, and you build a real data set on how the team is actually feeling—and start surfacing the systemic blockers getting in the way of good work.   About Alison Campbell   Alison Campbell is the founder and CEO of unBurnt® and Executive in Residence at Bentley University's Center for Health and Business. Her 2026 research — "When Burnout Looks Like Productivity: The New Risk to Innovation Capacity" — surveyed 544 professionals across 17 industries and reframes burnout as a measurable threat to an organization's capacity to innovate. unBurnt® · Research · LinkedIn   You can link with Alison Campbell on LinkedIn and read her research at getunburnt.com.  

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