Podcasts about agile coach

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]

Agile coach jobs aren’t coming back, and most of us already know it. What we haven’t done is accept what that means. Agile coach jobs went away (so we hid from the change) The irony of this profession is that agile is an approach to change, and we practitioners are as frightened of change as anyone we’ve ever coached. So when the roles went away, a lot of capable people did the predictable thing. They shrunk themselves. Back to project manager, program manager, product owner. Work that uses a fraction of what they know. I understand it. There’s a job description for those. But there isn’t yet one for what we actually do. No new job title is coming to replace agile coach jobs Don’t wait for it. If it does show up, it will have been written by someone who had nothing to do with the rebellion. That’s the part people forget. Agile was a rebellion, and rebellions are loosely organized and risky. With the economy and the geopolitics doing what they’re doing, nobody is volunteering for more risk. So nobody is going to stand up, announce the new category, and hand you a good rate for it. There are two kinds of change One is patching the bridge. I drove past a thirty-year-old overpass recently and you can see the repairs in the concrete. We know this kind well. Inspect, improve, carry the learning forward. The other is the forest fire. The forest gets too old, too dry, too crowded, too untenable, and the whole thing has to go. Some species of tree only drop their seeds in a fire. Vinyl got better for forty years. Better pressings, better styluses, better amplifiers. Then the CD arrived and none of it mattered. We had the BlackBerry with half its face given over to a keyboard. Then the iPhone. Show me a BlackBerry now. Notice what didn’t change. People still wanted to listen to music. People still wanted to reach each other. The problem stayed exactly where it was, and the thing built to solve it burned. Delivery will always have problems. What we built to solve them is what has to go. What to do instead of chasing agile coach jobs Stop waiting and start listening. Once or twice a year I export my LinkedIn connections, go through the spreadsheet, and highlight the people I enjoyed working with. Then I reach out. How are you doing, what have you been up to, here’s what I’m seeing, what are you seeing? They’ve changed jobs since we last spoke. Their companies have changed strategy. They know things. Have ten of those conversations in the next two weeks and patterns start showing up. Check them against Reddit, Quora, Substack, wherever people complain out loud. When you stop asking someone to hand you a solution, they describe their pain instead. Then propose something. This is where the iteration belongs, and it’s the part people get backwards. You don’t iterate on the bridge. You iterate on the offer. Maybe the price is wrong. Maybe a CEO doesn’t care and a VP does. Tweak it and go again. Eventually somebody says let’s get together and talk about what you’ve been up to. That’s your signal. This takes real courage and it isn’t for everybody. But the rate on an agile coach job is a cap, and you won’t raise it using that title. Forge Genesis is where I teach this. Link below, cohort starting soon. **FORGE GENESIS IS HERE** All the skills you need to stop relying on job postings and start enjoying the freedom of an Agile career on YOUR terms. First cohort starts in Q1 2026 https://learning.fusechamber.com/forge-genesis **THE ALL NEW FORGE LIGHTNING** 12 Weeks to elite leadership! https://learning.fusechamber.com/forge-lightning **CHECK OUT ALL MY PRODUCTS AND SERVICES HERE:** https://learning.fusechamber.com We’re also on YouTube! Follow the podcast, enjoy some panel/guest commentary, and get some quick tips and guidance from me: https://www.youtube.com/c/BadassAgilea ****** Follow The LinkedIn Page: https://www.linkedin.com/showcase/badass-agile ****** Our mission is to create an elite tribe of leaders who focus on who they need to become in order to lead and inspire, and to be the best agile podcast and resource for effective mindset and leadership game. Contact us (contact@badassagile.com) for elite-level performance and agile coaching, speaking engagements, team-level and executive mindset/agile training, and licensing options for modern, high-impact, bite-sized learning and educational content.

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]

Oliver und Tim sprechen in dieser Folge über ein Problem, das vermutlich viele Product Owner kennen: Das Team arbeitet dauernd an Stories, die gar nicht wichtig sind. Der Anlass ist ein Coachingfall. Ein Produktmensch klagt darüber, kaum voranzukommen. Sein Team hat immer zu viel zu tun. Gleichzeitig schreiben die Teammitglieder eigene Tickets ins Backlog. Oder sie ziehen sich Themen selbst von irgendeiner Stelle des Backlog. Manche Stories laufen auch gerne über mehrere Sprints weiter, ohne dass die Developer ein Störgefühl zeigen. Nur passt das selten zur eigentlich notwendigen Produktstrategie des Product Owners bzw. der Produktorganisation. Wenn Teammitglieder selbst Einträge für das Product Backlog schreiben, ist das natürlich erstmal ein absolut gutes Zeichen. Es zeigt echte Selbstorganisation. Schwierig wird es dort, wo diese Einträge ohne Absprache direkt ins Backlog wandern und die Reihenfolge verändern. Genau diese Reihenfolge liegt eigentlich in der Verantwortung der Produktverantwortlichen. Fehlen klare Working Agreements, wer Tickets erstellt und wer sie freigibt, entsteht schnell Unordnung im Backlog. Stories, die gar nicht wichtig sind, bleiben oft über mehrere Sprints liegen. Man möchte begonnene Arbeit ja zu Ende bringen… Das klingt vordergründig vernünftig, kostet aber Steuerungsmöglichkeit. Ein hilfreicher Reflex: Unfertige Einträge wandern konsequent zurück ins Product Backlog. So bleibt die Priorisierung nach Wert erhalten. Die Produktverantwortliche soll dann jederzeit neu entscheiden können, welche Themen gerade wichtiger sind. Hinter dem Punkt "Stories die gar nicht wichtig sind" stecken oft andere Gründe. Häufig fehlt eine klare Produktvision. Technisch geprägte Teams setzen dann eigene (ggf. technische) Prioritäten, weil niemand ihnen die Richtung von oben deutlich genug vermittelt hat. Aber auch andersrum mag technische Komplexität eine Rolle spielen: manche Produktverantwortliche durchdringen die technischen Zusammenhänge nicht gut genug bzw. schaffen es nicht, die fachlichen Zusammenhänge und Notwendigkeiten dem Team gut genug zu vermitteln. Entwicklerinnen und Entwickler treffen dann lieber eigene, technisch motivierte Entscheidungen - schlichtweg weil ihnen der Kontext fehlt. Fehlt zusätzlich eine Scrum Masterin bzw. Agile Coach moderiert oft niemand die nötigen Retrospektiven. Genau dort sollten solche Muster eigentlich auffallen. Auch geringe Präsenz der Produktverantwortlichen im Teamalltag begünstigt die Entwicklung. In dieser Lücke entstehen eigene Gewohnheiten und stille Freiheiten. Fehlendes Refinement und fehlende Sprintziele verstärken den Effekt zusätzlich. Ohne Sprintziel wird im Sprint Planning nie klar, warum ausgerechnet diese eine Story gerade wichtiger sein sollte als jene andere. Am Ende hilft nur Konsequenz: solche Beobachtungen dürfen nicht folgenlos bleiben. Sie brauchen Raum in Retrospektiven, im Refinement und im Sprint Planning. Dazu gehört auch eine Produktvision, die man immer wieder neu erzählt, bis sie beim ganzen Team ankommt (oder allen gefühlt schon zu den Ohren rauskommt). Wer also merkt, dass im eigenen Team dauernd an Stories gearbeitet wird, die gar nicht wichtig sind, sollte das als Alarmsignal für den gesamten Produktentwicklungsprozess verstehen. Oliver und Tim ermutigen dazu, dieses Storytelling auch mit Werkzeugen künstlicher Intelligenz auszubauen. So lässt sich die eigene Produktstrategie in einer Sprache aufbereiten, die im Entwicklungsteam wirklich verfängt. Folgende frühere Episoden werden im Gespräch genannt: - Wenn dein Team dir als Product Owner nicht folgt - Mit Storytelling andere von deinen Produktideen überzeugen - Product Backlog Refinement - Tipps für Product Owner - Product Principles (Produktprinzipien) - Verantwortung als Product Owner übernehmen

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

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?

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. 

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)

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

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.

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.

Earlier this year the PMI and Agile Alliance introduced the Manifesto for Enterprise Agility.  Then came the harder question: why do organizations with great strategies still struggle to execute them?  Their answer is a report called Closing the Change Readiness Gap, and in this episode Kate Megaw, Anu Smalley and Ryan Smith dig into what it found.  Executives are confident their purpose is clear, yet the single biggest problem they named was the disconnect between planning and execution.  The report points to four obstacles: signal loss, where the why gets stripped out on the way down; decision rights that sit too far from the work; a structural trap where friction hardens into process; and a lack of psychological safety to name any of it.  The trio unpack why these are not four separate problems but one connected system, why the frozen middle is really a shock absorber, and why you cannot bolt AI or a framework onto a broken structure and expect flow. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Iryna Stelmakh: The Firewall Product Owner, Turning PO Anti-Patterns Into Opportunities for Growth Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Market-Oriented and Vision-Driven "Great product owners don't just manage backlog items — they own the product vision and make sure the team understands how their work creates real value." — Iryna Stelmakh   Iryna describes the best product owners she's worked with through three qualities. First, they understand the market and the users deeply. Second, they can explain the business logic behind decisions — not just what to build, but why it matters. Third, they work closely with the team and treat them as partners in solving problems, not executors of tasks. The best PO Iryna worked with was responsible for sharing the business mindset, giving the team perspective and the possibility to contribute beyond the technical work. Everything was organized around a shared goal, and the team understood how their work created real value. As Vasco observes, when a PO just drops tasks without explaining why they matter, the team becomes "just a pair of hands." Great product owners create allegiance through understanding.   Self-reflection Question: Does your product owner share enough business context that your team could independently suggest features or improvements — or are they only able to execute what they're told? The Bad Product Owner: The Firewall Who Blocks All Business Context "We were working without the product mindset, without the product vision." — Iryna Stelmakh   Iryna shares the story of what she calls the Firewall Product Owner — a PO who constantly said "I need to go ask someone" for every decision, but never brought back answers. The result: backlog items lacked clarity, priorities changed frequently, and the team couldn't understand the real product direction. They were working without a product mindset or vision. As Vasco frames it, this PO wasn't just a proxy — they were a firewall, blocking the team from accessing any business context or market knowledge. The team couldn't reach the market representatives because they didn't even know who was on the other side.   Iryna's approach to this kind of situation: escalate with suggestions, not just complaints. Turn problems into opportunities and extensions — propose bringing in a business analyst to support the PO, or suggest restructuring the communication between the business and technical sides. In her case, the client eventually recognized the problem and replaced the PO with someone who could actually bridge the gap. The new PO changed everything.   In this episode, we also refer to the concept of turning problems into opportunities.   Self-reflection Question: When your product owner is unable to provide timely answers, do you escalate with specific suggestions for improvement — or do you simply wait and hope things get better?   [The Scrum Master Toolbox Podcast Recommends]  

Iryna Stelmakh: The Almost Invisible Scrum Master, Why Team Independence Is the Ultimate Success Metric Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "A successful Scrum Master is almost invisible — not because they don't contribute, but because the team is no longer dependent on them for every decision." — Iryna Stelmakh   Iryna offers a powerful definition of success for Scrum Masters: becoming almost invisible. Not because the Scrum Master isn't contributing, but because the system works — with or without them. The team takes ownership of delivery, solves problems collaboratively, and continuously improves its own process. Each team member can propose, vote, and suggest changes because the environment has a high level of trust.   When that happens, Iryna explains, the Scrum Master becomes more of a system observer and catalyst rather than a daily driver. As Vasco adds, this perspective is valuable because it looks beyond personal metrics — it examines behaviors across all the interactions the Scrum Master facilitates: between the team and the product owner, between the team and stakeholders during reviews, and within the team itself. The Scrum Master role sits at the nexus of many interactions, and success means those interactions work well even when you step back.   Self-reflection Question: If you were absent for a full sprint, would your team maintain the same quality of collaboration, decision-making, and delivery — or would things fall apart without you? Featured Retrospective Format for the Week: The Energy Retrospective Iryna shares her favorite retrospective format — one she calls the Energy Retrospective. Instead of the standard "what went well / what didn't" framing, it asks three questions: What gave us energy this sprint? What drained our energy? And what should we start, stop, or continue doing to keep our energy at the right level?   This approach shifts the conversation from purely technical task problems to real human dynamics. As Iryna explains, closing technical tasks and resolving issues is important, but so is the wellness of the team. The Energy Retrospective creates space for both. She also notes that retrospective format should match the team: for open, trusting teams, a straightforward format works fine. But for new teams or teams with high resistance — those still in the forming stage where the Scrum Master isn't yet a trusted figure — she uses metaphorical approaches, like asking team members to pick pictures that represent their feelings about the sprint. Even a happy, sad, or frustrated monkey picture can surface insights that direct questions might not.   [The Scrum Master Toolbox Podcast Recommends]