Podcasts about product owners

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

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

Als het drukker wordt, is je eigen ontwikkeling het eerste wat sneuvelt. Logisch, want de backlog wacht niet. Maar het is ook precies het moment waarop je het het hardst nodig hebt. Jochem gaat deze week in gesprek met Stephan van Rooden. In deze aflevering bespreken ze: Waarom product owners hun eigen ontwikkeling als eerste laten vallen zodra de druk toeneemt Hoe je uit die vicieuze cirkel komt en waarom stilstaan je uiteindelijk méér tijd kost Wat de product owner nulmeting is en hoe die je helpt om scherp te krijgen waar je nu staat en waar je moet groeien Een must listen voor iedere PO die te vaak denkt "daar heb ik nu even geen tijd voor" en zijn of haar eigen groei weer serieus wil nemen. De Product Owner podcast is een initiatief van productowner.nl

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

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

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

Was ist eigentlich das Produkt? Die Frage klingt trivial, ist für viele Product Owner aber alles andere als leicht zu beantworten. In dieser Folge spricht Oliver mit Philipp Weiß, Product Owner der Website bei Transfermarkt.de, über genau diese Frage an einem konkreten Praxisfall. Transfermarkt ist seit 26 Jahren die größte öffentlich zugängliche Fußballdatenbank der Welt, mit Profilen, Marktwerten, News, Forum, Spielen und Tools, in 16 Sprachen, dazu App und B2B-Angebot. Ist bei dieser Bandbreite einfach die ganze Website das Produkt? Und wie lassen sich Produktvision, North Star Metric und Strategie auf dieser Ebene sinnvoll nutzen? Oliver und Philipp gehen mögliche Produktschnitte durch: nach Kanal, nach Inhalt, nach Teamstruktur oder nach Nutzerbedürfnissen. Sie sprechen darüber, was jede Variante für Priorisierung und Zusammenarbeit bedeutet, warum sich Organisationen so schwer von gewachsenen Features trennen und warum der Fokus auf wenige Spielfelder oft wichtiger ist als der perfekte Produktschnitt. Eine Folge für alle Product Owner mit gewachsenen, komplexen Produkten, auch für Hörer:innen ohne Fußballbezug.

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

"Czy robiliśmy review lat temu trzy? Nie, nie robiliśmy, tylko wszyscy okłamywali się, że robią review porządnie i klikali: tak, tak, tak może iść."

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

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

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

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

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

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

In vielen Unternehmen kann man erleben, dass Menschen sich Product Owner nennen, obwohl ihr Team längst kein Scrum mehr lebt. Aber verdient ein Product Owner ohne Scrum überhaupt noch diesen Namen? Oder verliert der Titel dann seine Grundlage? In Trainings und Organisationen tauchen diese Fragen immer wieder auf. Die Rolle heißt dort dann oft weiterhin Product Owner, im Alltag bestimmt aber längst Kanban oder ein eigenes, vielleicht sogar informelles Vorgehen das Bild. Historisch wurde der Begriff Product Owner durch Scrum verbreitet und bekannt. Zusätzlich taucht er im Scaled Agile Framework auf, dort allerdings mit einer anderen Bedeutung als im ursprünglichen Scrum Guide. Verschwindet Scrum aus einer Organisation, bleibt die Bezeichnung trotzdem oft bestehen. Sie hat sich auch im deutschsprachigen Recruiting fest etabliert. Menschen suchen nach wie vor deutlich häufiger nach Product Owner als nach Product Manager. Der Rollenname überlebt also das Framework, aus dem er stammt. Wechselt ein Team beispielsweise zu Kanban, lässt sich die Rolle Product Owner meist einfach weiterführen. Kanban selbst lässt offen, wer Prioritäten setzt und Entscheidungen trifft. Schwieriger wird es, wenn mit Scrum auch die Rituale verschwinden. Dabei geben diese Rituale einer Person erst die Möglichkeit, Produktverantwortung wirklich wahrzunehmen. Ohne Sprint Review fehlt der regelmäßige Moment für Feedback und Kurskorrektur. Ohne Retrospektive fehlt der Raum für die Weiterentwicklung der eigenen Zusammenarbeit. Und ohne ein sauber priorisiertes Product Backlog tauchen schnell wieder Listen auf, in denen fast alles gleich wichtig erscheint. An genau diesen fehlenden Kadenzen zeigt sich, wie viel von der ursprünglichen Rollenidee verloren geht, sobald ein Product Owner ohne Scrum arbeiten muss und nichts Vergleichbares an dessen Stelle tritt. Zwischen Product Owner als Rollenbezeichnung und Product Ownership als eigentlicher Produktverantwortung liegt ein wichtiger Unterschied. Product Ownership beschreibt, wie viel Entscheidungsgewalt, Kundennähe und Gestaltungsspielraum ein Mensch oder ein ganzes Team für den Erfolg eines Produkts übernimmt. Das gilt unabhängig vom Framework und unabhängig vom Titel auf der Visitenkarte. Werkzeuge wie das Product Ownership Evolution Model oder eine klassische RACI Matrix machen diese Verantwortung sichtbar, statt sie stillschweigend vorauszusetzen. Wer offen mit Führungskräften und Stakeholdern klärt, wie viel Ownership das Unternehmen tatsächlich überträgt, gewinnt echte Klarheit. Das gilt ganz gleich, ob am Ende Scrum, Kanban oder gar kein Framework im Hintergrund steht. Fehlt diese Klarheit, ziehen sich viele Menschen in vertraute Muster zurück und aus ihnen werden reine Verwalter des Backlogs, obwohl der Titel eigentlich Gestaltung verspricht. Diese Lücke zwischen Erwartung und gelebter Rolle erzeugt bei Betroffenen häufig eine stille Unsicherheit. Besonders dann, wenn eine Organisation den Rollenwechsel nie bewusst und offen kommuniziert hat. Manche Unternehmen begegnen dieser Unschärfe mit einem neuen Namen, etwa Product Lead oder Head of Product. Ein neues Etikett allein schafft dabei aber noch keine Rollenklarheit. Solange niemand Entscheidungsbefugnisse, Erwartungen und den Zugang zu Kundinnen und Kunden ausdrücklich benennt, verändert sich wenig. Dominique und Tim geben eine Empfehlung an alle, die sich in genau dieser Situation wiederfinden: Die Frage nach dem passenden Titel tritt in den Hintergrund, sobald echte Klarheit über Entscheidungsrechte, Erwartungen und Handlungsspielräume entsteht. Wer als Product Owner ohne Scrum arbeitet, sollte diese Klarheit aktiv im eigenen Umfeld einfordern. Sonst bleibt oft nur die stille Anpassung an einen unpassenden Titel. Ob am Ende der Titel Product Owner bleibt oder eine andere Bezeichnung ihn ablöst, verliert dadurch spürbar an Bedeutung.

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

Eine Führungsperson im Team fällt aus. Eine andere Person springt ein. Alltag in Organisationen. Martin und ich diskutieren in dieser Folge die Herausforderungen und Chancen, die aus solchen Situationen entstehen. Wir betrachten die Vor- und Nachteile solcher Vertretungen und geben praktische Tipps für den Umgang mit Rollenkonflikten und organisationalen Veränderungen.

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

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

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

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.

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

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]

https://hpmexam.comAUG 22ND 2026 - RAPID BOOTCAMP

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

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

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

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

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

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

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

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

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

Hey Scrum Master, Product Owner and Dev team! If you experience rollover, items not getting done, or just want to optimize your workflow, this episode may help. Of course, it may not...?!I have observed and experienced the top 3 reasons why teams rollover work from sprint to sprint and of course, we'll dive in to the first one here and give you some practical tips on overcoming that nasty, routine rollover experience you're having to help you get things DONE.If you like this:Subscribe, tell a friend, write a reviewIf you don't like this or you want to reach out:scott@planetproductowner.org

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

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

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

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

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

If Your ScrumMaster Only Runs Meetings... You're Wasting Your Best LeaderAsk ten people what a ScrumMaster does, and you're likely to hear ten different answers."They run the Daily Stand-up.""They schedule Sprint Planning.""They update Jira.""They remove impediments.""They're the Agile coach.""They're the team's project manager."Some of those answers are partially correct.Most of them are incomplete.And that's becoming one of the biggest challenges facing Agile organizations today.Somewhere along the way, many companies unintentionally shrank one of the most influential leadership roles on an Agile team into something much smaller.A meeting facilitator.A calendar manager.A process referee.Someone who reminds everyone when the Sprint Review starts.That's not what the ScrumMaster role was designed to be.In fact, if that's all your ScrumMaster is doing...You're probably missing the greatest opportunity that role has to offer.Let's imagine two ScrumMasters.The first arrives every morning with a checklist.Start the Daily Scrum.Update the board.Send reminders.Schedule Retrospectives.Close completed stories.Generate reports.Stay organized.Nothing wrong with those activities.They're important.But now let's look at a second ScrumMaster.This person notices that two team members have stopped collaborating.They coach a Product Owner struggling to prioritize competing stakeholder requests.They help leadership understand why multitasking is slowing delivery.They facilitate a difficult conversation before it becomes a lasting conflict.They identify organizational policies that create unnecessary delays.They mentor new leaders.They build trust across departments.They help people solve problems they didn't even realize existed.Which ScrumMaster creates greater long-term value?The answer seems obvious.Yet many organizations still spend far more time measuring the first set of activities than the second.Why?Because administration is visible.Leadership often isn't.You can see a meeting on a calendar.You can't always see trust being built.You can count completed ceremonies.It's much harder to measure improved communication.You can track whether a Retrospective happened.It's much more difficult to quantify whether people actually feel safe speaking honestly during it.That's the challenge.The most valuable work ScrumMasters perform often happens between the ceremonies.Not during them.- [website] ⁠⁠⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠⁠⁠- [instagram] ⁠⁠⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠⁠⁠- [facebook] ⁠⁠⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠⁠⁠- [Linkedin] ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/

AI Can Write User Stories... So What Does the Product Owner Do Now?If artificial intelligence can write user stories...What exactly is the Product Owner supposed to do?It's a fair question.Over the past year, we've watched AI tools generate acceptance criteria, organize backlogs, summarize stakeholder interviews, identify duplicate requirements, estimate effort, draft release notes, and even suggest Sprint Goals.Tasks that once required hours can now be completed in minutes.Some see that as a threat.I see it as an opportunity.Because for years, many organizations unintentionally reduced the Product Owner role to backlog management.Write stories.Prioritize tickets.Attend meetings.Answer developer questions.Repeat.Those activities are important.But they were never the reason the Product Owner role was created.The Product Owner exists for one purpose above all others.To maximize value.Not backlog size.Not story count.Not velocity.Value.That's where artificial intelligence changes everything.- [website] ⁠⁠⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠⁠⁠- [instagram] ⁠⁠⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠⁠⁠- [facebook] ⁠⁠⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠⁠⁠- [Linkedin] ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/

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

Bad Agile Is Dying... And That's the Best News Agile Has Had in YearsAgile isn't dying.Bad Agile is.And honestly...that's fantastic news.For nearly two decades, organizations around the world raced to become "Agile."Some invested heavily in coaching.Others purchased new software.Many reorganized entire departments.Unfortunately, somewhere along the journey, a surprising number of organizations confused Agile with process.Stand-ups became status meetings.Sprint Planning became project planning.Retrospectives became complaint sessions.Story points became performance metrics.Velocity became a management scorecard.Scrum Masters became meeting coordinators.Product Owners became backlog administrators.The framework remained.The mindset quietly disappeared.Over time, employees became frustrated.Executives questioned the investment.Teams felt overwhelmed by ceremonies that no longer seemed connected to delivering value.Then something predictable happened.Organizations didn't reject Agile.They rejected bad experiences disguised as Agile.That's an important distinction.- [website] ⁠⁠⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠⁠⁠- [instagram] ⁠⁠⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠⁠⁠- [facebook] ⁠⁠⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠⁠⁠- [Linkedin] ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/

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

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

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]