Podcasts about agile coach

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

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

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

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

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

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

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

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

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

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

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

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

In dieser Podcast Folge spricht Jan Neudecker von der Agile Academy mit Tim darüber, was Scrum Master über agiles Produktmanagement wissen und in der Zusammenarbeit mit Product Ownern wirksam vermitteln können sollten. In vielen Teams zeigt sich ein wiederkehrendes Muster. Im Refinement entstehen gute Ideen, im Sprint Planning wird viel diskutiert, doch Entscheidungen bleiben liegen. Genau hier wird klar, warum Scrum Master agiles Produktmanagement Wissen brauchen. Wenn ein Product Owner zögert, weil Freigaben fehlen oder weil Unsicherheit besteht, verlangsamt sich nicht nur die Umsetzung, sondern vor allem das Lernen im Produkt. Jan beschreibt aus seiner eigenen Erfahrung als Scrum Master, Product Owner und Certified Scrum Trainer sehr klar, woran man starke Product Owner erkennt. Für ihn treffen sie Entscheidungen, wenn sie gebraucht werden, und sie verstehen die Realität ihrer Nutzer. Beides entsteht nicht zufällig. Es braucht ein Umfeld, das genau diese Verantwortung ermöglicht. Und hier liegt ein zentraler Beitrag des Scrum Masters. Er arbeitet nicht nur an Prozessen und fürs Team, sondern sorgt dafür, dass Entscheidungsfähigkeit des Product Owners überhaupt entstehen kann. Das bedeutet, Hindernisse im Umfeld sichtbar zu machen und gemeinsam mit Organisation und Stakeholdern daran zu arbeiten, dass Verantwortung wirklich beim Product Owner ankommt. Gerade in der täglichen Zusammenarbeit wird deutlich, wie eng Scrum Master bzw. Agile Coaches und Product Owner verbunden sind. Wenn ein Team verschiedene Lösungsoptionen erarbeitet und der Product Owner keine klare Richtung vorgibt, entsteht Unsicherheit im Team. Diese Situation lässt sich nicht durch Moderation allein lösen. Ein Scrum Master, der agiles Produktmanagement Wissen mitbringt, erkennt, dass hier kein Methodenproblem vorliegt, sondern ein fehlender Entscheidungsrahmen. Statt nur das Meeting zu strukturieren, unterstützt er den Product Owner dabei, Optionen zu bewerten, Konsequenzen zu verstehen und Entscheidungen vorzubereiten. Gleichzeitig hilft er dabei, die Perspektive der Nutzer stärker einzubringen. Denn ohne ein echtes Verständnis für den Nutzungskontext entstehen schnell Lösungen, die technisch sauber sind, aber am Bedarf vorbeigehen. Diese Verbindung aus Entscheidungsfähigkeit und Nutzerfokus macht den Unterschied im Alltag. Oft sehen wir Teams, in denen beide Rollen noch wenig Erfahrung haben. Dann wird agiles Arbeiten schnell zu einer Abfolge von Meetings, ohne dass echte Produktverantwortung entsteht. Genau hier wird die Rolle des Scrum Masters anspruchsvoll. Wer als Scrum Master agiles Produktmanagement Wissen hat, beschränkt sich nicht auf die Einhaltung von Scrum Regeln, sondern arbeitet aktiv daran, Produktdenken im Team zu verankern. Das zeigt sich in kleinen Situationen. In einem Review, in dem nicht nur Ergebnisse gezeigt werden, sondern echtes Feedback eingeholt wird. Oder in Gesprächen mit Stakeholdern, in denen Erwartungen geklärt werden, bevor sie Druck auf das Team ausüben. Diese Arbeit ist oft unsichtbar, hat aber direkten Einfluss auf die Wirksamkeit des Product Owners und damit auf den Erfolg des Produkts. Folgende ältere Episoden empfiehlt Tim im Gespräch: Dein Freund der Scrum Master Erfolgreich mit User Stories arbeiten Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Wenn ihr Kontakt zu Jan Neudecker aufnehmen möchtet oder weitere Fragen an ihn habt, erreicht ihr ihn am besten über sein LinkedIn-Profil. Im Gespräch erwähnt gibt Jan Neudecker eine ganze Reihe von sehr erfolgreichen Zertifizierungstrainings für Scrum Master und Product Owner. Die Übersicht zu seinen offenen Trainings findet ihr auf der Seite der Agile Academy. Im Gespräch hat Tim zudem folgende Bücher empfohlen: - Teresa Torres: Continupus Discovery Habits - Bruce McCarthy: Aligned - Stakeholder Management for Product Leaders

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

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

Most Agile coaches build their careers inside large organizations — but what happens when a new opportunity calls from an unexpected direction? Scrum.org CEO, Dave West, sits down with Marina Alex, an AI & modern management expert and Founder of The SWAY Academy, who answered that call. After the enterprise market shifted in 2022, Marina pivoted her practice toward small and medium-sized businesses in Knoxville, Tennessee — and discovered what she describes as a blue ocean: many companies that have never heard of a Sprint, but are ready for one.Along the way, Marina found that AI has become a natural entry point into these conversations. With most small businesses neither tech-heavy nor equipped with an IT department, the excitement and anxiety around AI opens the door to deeper work around team culture, structure, and customer focus. Rather than leading with frameworks, she leads with outcomes — helping business owners understand that strong teams and clear processes are what make any new technology actually stick.Marina walks Dave through the mindset shifts, networking strategies, and practical adaptations — from one-week Sprints to sticky-note Retrospectives — that have allowed her to build a thriving practice doing work she loves, serving the local business communities that need her most.Free Guide from Sway Systems with tips to find new clientsConnect with Marina

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

The Evolving Role Of The Agile Coach Being an Agile Coach is no longer about staying buried in frameworks or cheerleading teams. It's about getting out of the team room, talking to the business, and understanding what people are measured on, what they fear, and what they need to move faster and create value. Why It Matters When we build regular conversations with the business, we stay closer to real priorities, spot changes sooner, and become more useful to the organization. You also make your value visible, which matters when most people still don't fully understand what an Agile Coach does. What To Do Now See your job as helping connect technology to outcomes that show up in the business, not just in process metrics. That means networking, asking better questions, joining strategy discussions, and looking for low-risk experiments that improve speed, revenue, or customer results. In a world where technology is no longer the bottleneck, the Agile Coach who stays curious, visible, and aligned with the business is the one who stays relevant. If You Liked This Epsiode you may also like: Episode 231 – What A Great Coach Does Outcomes, Not Outputs – How To Resurrect Agile FORGE GENESIS IS HEREAll the skills you need to stop relying on job postings and start enjoying the freedom of an Agile career on YOUR terms. Next cohort starts in Q2 2026https://learning.fusechamber.com/forge-genesis THE ALL NEW FORGE LIGHTNING12 Weeks to elite leadership!https://learning.fusechamber.com/forge-lightning JOIN MY BETA COMMUNITY FOR AGILE ENTREPRENEURS AND INTRAPRENEURSThe latest wave in professional Agile careers. Get the support you need to Forge Your Freedom! Join for FREE here:https://learning.fusechamber.com/offers/Sa3udEgz GET THE BUSINESS OUTCOMES PARTNER PLAYBOOKLearn how to deliver undeniable ROI that saves your job and accelerates your futurehttps://learning.fusechamber.com/outcomes-partner-playbook CHECK OUT ALL MY PRODUCTS AND SERVICES HERE:https://learning.fusechamber.com ELEVATE YOUR PROFESSIONAL STORYTELLING – Now Live!The most coveted communications skill – now at your fingertips!https://learning.fusechamber.com/storytelling JOIN THE FORGE*New cohorts for Fall 2025!  Email for more information:contact@badassagile.com We’re also on YouTube! Follow the podcast, enjoy some panel/guest commentary, and get some quick tips and guidance from me:https://www.youtube.com/c/BadassAgile Follow The LinkedIn Page:https://www.linkedin.com/showcase/badass-agile Our mission is to create an elite tribe of leaders who focus on who they need to become in order to lead and inspire, and to be the best agile podcast and resource for effective mindset and leadership game. Contact us (contact@badassagile.com) for elite-level performance and agile coaching, speaking engagements, team-level and executive mindset/agile training, and licensing options for modern, high-impact, bite-sized learning and educational content.

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

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

„Wenn du stolz auf deine 50 zertifizierten Scrum Master und deine perfekte Jira-Hygiene bist, dann schalt am besten jetzt ab.“ In dieser Episode graben wir die Leiche der Agilität aus. Marc räumt mit dem weitverbreiteten Missverständnis auf, dass Agilität etwas mit „schnellerem Bauen“ zu tun hat. Die Wahrheit ist schmerzhaft: Die meisten Unternehmen haben das Agile Manifest zwar gelesen, aber nicht die Eier gehabt, es umzusetzen. Statt echter Transformation gab es teures Wasserfall-Theater mit neuen Vokabeln. Doch jetzt kommt der Endgegner: Die Künstliche Intelligenz. Wenn KI die Delivery-Kosten gegen Null drückt, was bleibt dann von deinem Job als Agile Coach oder Scrum Master übrig? Die harten Fakten dieser Folge: Die Velocity-Falle: Warum es völlig egal ist, wie schnell der Hamster im Rad läuft, wenn das Rad im Keller steht. Wir haben Customer Collaboration durch eine Mauer aus Jira-Tickets ersetzt. Der KI-Hammer: KI schreibt Code, baut Prototypen und moderiert bald deine Sprints. Wer sich nur als „Prozesswächter“ definiert, ist in zwei Jahren arbeitslos. Vom Verwalter zum Strategen: Dein einziger Überlebensweg ist der Wechsel in den „Problem Space“. Verstehst du wirklich, welchen Schmerz ihr beim Kunden löst? Das 0-Euro-Ticket: Marcs radikale Methode für das nächste Refinement. Wenn keiner erklären kann, wer gefeuert wird oder Geld verliert, wenn ein Feature nicht gebaut wird – dann lösch das Ticket. Sofort. Die „Unfiltered“ Challenge für deine Woche: Geh morgen in dein Team-Meeting. Sobald die Diskussion über Story Points losgeht, brichst du ab. Stell die eine Frage, die wirklich zählt: „Welchen konkreten Schmerz eliminieren wir hier gerade?“ Kann es keiner in einem Satz sagen? Dann stoppt den Sprint. „Agilität ist nicht tot. Aber eure Interpretation davon verdient den Gnadenschuss.“ Ressourcen & Links: Das Delivery Manifest: https://deliverymanifest.org/  Vernetz dich mit Marc: https://www.linkedin.com/in/marcsteffenloeffler/  Nichts verpassen: Abonniere Agile Unfiltered auf Apple Podcasts oder Spotify.

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

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

Iryna Stelmakh: Fighting Agile Theater, When Organizations Adopt the Ceremonies But Not the Mindset 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.   "Transparency can be uncomfortable, but without transparency, there is no real improvement." — Iryna Stelmakh   Iryna brings a challenge she calls "Agile Theater" — organizations that implement all the visible parts of Agile (the ceremonies, the boards, the terminology) while the underlying mindset remains unchanged. Decisions stay centralized, transparency is avoided, and problems are hidden. As she puts it: "Teams go through the emotions of Agile without actually benefiting from it."   But her real challenge goes deeper. Iryna shares a story about building trust with outsourcing clients. Five days into a new assignment on a project the company had worked on for over ten years, she received an email listing team members to be removed — with no explanation. It was a red flag: the absence of transparency signaled that the client relationship lacked the trust bridge needed for genuine collaboration.   Iryna's response was characteristically direct. She organized a call with stakeholders and discovered the client operated on quarterly budget cycles — these cuts could happen every three months. Instead of accepting the loss, she shifted the cut team members to other projects within the same account, turning the problem into an opportunity. A QA engineer moved to another project that needed one. A developer and two others got upsold into a team extension. Nobody ended up on the bench.   Then came the systemic fix: Iryna set up one-on-one meetings with each stakeholder across different divisions to stay informed in advance. Prevention over reaction — because, as she says, reactions cost more.   Self-reflection Question: In your current engagement, do you have direct relationships with the people who make budget and staffing decisions — or would a surprise email catch you completely off guard?   [The Scrum Master Toolbox Podcast Recommends]  

Iryna Stelmakh: When Communication Clarity Matters More Than Technical Complexity, A Healthcare Project That Fell Apart Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Communication clarity is more important than technical complexity, because if you do not understand, it's pretty hard to execute." — Iryna Stelmakh   Iryna shares one of her most painful career stories — a project in the healthcare domain focused on cancer treatment research data. When she joined, she was managing around 9 projects simultaneously and agreed to take this one on the condition that a strong technical lead would own the technical direction. The project began with a critical misunderstanding: sales had communicated that the client needed a database redesign, but the client actually needed a migration to a different database type. Similar words, fundamentally different work.   For three months, the team worked through research and discovery phases, trying to understand the actual problem. But communication gaps — compounded by language barriers between the Ukrainian development team and the US-based client — prevented them from identifying the real need in time. Iryna trusted the technical lead's reports that everything was on track. She relied instead of checking. Eventually, the client lost confidence and left. It remains the only project in her career she considers a genuine failure.   The lesson cuts deep: teams must have people who can ask the right questions early. As Vasco observes, the root cause was implicit assumptions that were never discovered or explored by the different people involved.   In this episode, we also talk about the importance of the monitoring and controlling phase in project management.   Self-reflection Question: When you trust a team member's assessment that "everything is fine," what verification steps do you take to confirm that understanding is truly shared across all stakeholders? Featured Book of the Week: Team Topologies by Matthew Skelton and Manuel Pais Iryna recommends Team Topologies by Matthew Skelton and Manuel Pais as a book that changed how she thinks about Agile leadership. "Great agile leadership is not only about frameworks, but it's about communication, influence, and the ability to align people around shared goals," she explains. The book helped her understand that Agile isn't just about team process — it's about organizational structure, team boundaries, and responsibilities. She also recommends Never Split the Difference by Chris Voss for Scrum Masters who want to sharpen their communication and influence tactics. As Iryna puts it, communication is one of the most important skills a Scrum Master must have.   [The Scrum Master Toolbox Podcast Recommends]  

Iryna Stelmakh: When "Agile" Becomes a License to Change Everything, The Cost of No Rules in Backlog Management Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "For me, it was pretty hard to explain that Agile is about cost reduction, and not about cost increasing." — Iryna Stelmakh   Iryna shares a story from one of her first projects as a Scrum Master, working with a client from Israel who saw Scrum as an open invitation to add anything to the backlog at any time. For this client, agility meant unlimited flexibility — the freedom to extend not just the product backlog but the sprint backlog, multiple times per sprint. As Vasco points out, this is a pattern many teams recognize: when there's no cost to disrupting a sprint, it becomes effortless to keep piling on work, destroying the very predictability that sprints are designed to create.   Iryna struggled to push back. It was one of her first projects, and the client was confident in his approach. But the experience taught her a lasting lesson: the collaboration with external clients must start with an agreement about how the team works. That means explaining the methodology during the pre-sale phase, documenting it in the contract, and teaching the client the benefits of the process before the work begins. As she puts it, when she checked back with the sales and engagement teams, she realized nobody had set those expectations. She relied instead of checking — and paid the price. Once she held sessions with the client to explain how Scrum works and what it delivers, things shifted. New tasks went into the product backlog and were prioritized properly through refinement, not dumped into active sprints.   Self-reflection Question: When was the last time you verified that your client or stakeholders truly understand how your team works — not just the label, but the actual rules and commitments?   [The Scrum Master Toolbox Podcast Recommends]  

Junaid Shaikh: Product Owner Anti-Patterns, From Team Owner to Product Owner, And The PO Who Got It Right Junaid opens with a line that cuts straight to the most common PO anti-pattern: "You are the product owner, not the team owner." When he sees a PO slipping into command-and-control mode, he asks them one question: "What is your role?" They say "Product Owner." He says: "Exactly. You own the product, not the team. If you were meant to own the team, we'd call you a project manager." The worst case he witnessed: a PO who was so possessive of "his" team that he required approval on everything — processes, tools, even holiday requests. In sprint planning, he would assign stories to individual team members ("Mr. X, you take this one"). He'd estimate the work himself, and when developers pushed back, he'd override them: "I was a developer, I know how long this takes." For approaching PO anti-patterns, Junaid has a deliberate style: he doesn't confront upfront. He observes, takes notes, and starts by solving a smaller impediment to demonstrate he's there to help. Once trust is built, he brings in coaching tools — first teaching the basics ("this is what the PO role is in Scrum"), then gradually coaching on specific anti-patterns observed in practice. He targets 10-15% improvement at a time. Six months later, you've already achieved 30-40% improvement. The best PO Junaid has worked with had four qualities: clear, concise communication; an open mindset willing to be coached; courage to say "no" when needed; and the discipline to define the "what" and leave the "how" to the team. This PO started with five sources of truth — Excel tabs, whiteboards, JIRA, and other tools. When Junaid pointed out that five sources of truth is the opposite of transparency (one of Scrum's three pillars), the PO asked for help. Junaid's response: "I can't do the push-ups for you." Together, they consolidated everything into one tool. The team was happier, and the PO managed the backlog much better. The key lesson: great product owners trust their team, communicate clearly, prioritize ruthlessly, and have the courage to say no. And they don't try to own the team. You can link with Junaid Shaikh on LinkedIn. [The Scrum Master Toolbox Podcast Recommends]

Junaid Shaikh: How Scrum Masters Can Measure Their Own Impact, Practical Self-Assessment Metrics Junaid's favorite retrospective format? The vanilla: what went well, what could have gone better, what to do better next. He's tried many formats — the Three L's (liked, learned, lacked), the Three Little Pigs, the sailboat — but the core principle is always the same. His practical advice: stick with a consistent format so the team gets better at the process itself rather than constantly adjusting to new concepts. One addition he insists on for any format: an appreciation component. In the rush to analyze processes and outcomes, teams often skip acknowledging how another team member, PO, or Scrum Master helped during the sprint. That appreciation builds trust, respect, and openness that feeds into subsequent sprints. On defining success as a Scrum Master, Junaid starts with a Peter Drucker quote: "You cannot improve something you cannot measure." He proposes several practical self-assessment metrics: First, the Agile Team Maturity Index — a spider graph that shows where the team stands across multiple criteria, making gaps visible and actionable. Second, track retrospective action items. Create tiger teams for specific issues, run small iterative experiments, and measure in the next retrospective whether the trend is improving. Third, watch for shared sprint goals. Junaid once saw a team with nine sprint goals for a two-week sprint — those weren't goals, they were individual tasks. A real sprint goal should be something multiple team members work together to achieve. Fourth, self-organizing teams. If the team falls apart when the Scrum Master is absent for a sprint, there's a problem. Coach teams to self-organize, and their ability to function independently becomes a success metric. Fifth, communication patterns. Too many emails flying around can signal hidden conflicts or trust barriers. If communication happens through the right channels — dailies, direct interactions — you're likely in good shape. Sixth, Scrum event health. If events get canceled too frequently, the team may be reverting to traditional ways of working. [The Scrum Master Toolbox Podcast Recommends]

Junaid Shaikh: Managing Uncertainty As A Scrum Master, How Scrum's Rhythm Creates Stability In Unstable Times For this week's coaching conversation, Junaid brings a challenge that resonates well beyond any single team: dealing with uncertainty. He references the World Uncertainty Index report from February 2026, which showed the highest levels of global uncertainty ever recorded — surpassing both the COVID pandemic and the 2008 financial crisis. This uncertainty doesn't stay at the geopolitical level. It seeps into teams. People show up stressed, unsure about what the next month or three months will bring. As Scrum Masters, we need to be cognizant of where our team members are coming from. Vasco adds an important layer: uncertainty operates at multiple levels within organizations. A colleague you depend on might be out sick for two weeks. A supplier might not deliver on time. Every dependency is a source of uncertainty. The question becomes: what in our processes is designed to accept and adapt to that uncertainty? Junaid's answer is powerful in its simplicity: Scrum's rhythm. The sprint, the planning, the daily, the retrospective — these events at a defined cadence create internal predictability. "When you have a rhythm, when you have a known sequence of events in front of you, that takes away a lot of uncertainty." Vasco builds on this: Scrum creates a boundary — the sprint — that accepts uncertainty outside while reducing it inside. Internal versus external predictability. Inside the sprint, the team can fail in small ways without exposing every failure to the outside. Compare that with traditional project planning, where every task on the critical path has external visibility and impact. For practical tools, Junaid shares how he used the Eisenhower matrix with a team to convert uncertainty into actionable priorities. They listed all activities from recent sprints, plotted them on the matrix, and found they could delegate or deprioritize 20-25% of their work. That freed them to focus with certainty on the remaining 75%. Combined with timeboxing as an uncertainty management mechanism, teams can create pockets of predictability even in turbulent times. [The Scrum Master Toolbox Podcast Recommends]

Junaid Shaikh: Why Teams Go Through The Motions of Agile Without Being Agile, And What To Do About It Junaid's book recommendation is The Culture Map by Erin Meyer. As a Scrum Master working at companies like Ericsson and ABB — organizations that are a "United Nations" of cultures — understanding cultural tendencies has been essential. But Junaid goes further: you can customize the Culture Map framework even within a team of people from the same country, using the parameters to map different personalities. It's about how you use the tool, not just where people come from. He also recommends Scrum Mastery: From Good to Great Servant Leadership by Geoff Watts for practical advice on the servant leadership role, and regularly visits Scrum Alliance and Scrum.org for real-world insights from the community. On the topic of teams that self-destruct, Junaid paints a picture that many listeners will recognize. He picked up a team's retrospective history and cumulative flow diagrams and found problems at every level: managers who declared "from tomorrow we're going agile" without understanding what that meant, then started comparing velocity across teams. Product owners who took PO training but reverted to command-and-control project management. A previous Scrum Master doing what Junaid calls "zombie Scrum" — implementing the framework mechanically without understanding its purpose. The pattern underneath it all: people enveloping their traditional mindset under an agile umbrella. The ceremonies happen, the daily standups run, but nobody is questioning why they're doing any of it. As Vasco observes, this zombie pattern isn't limited to Scrum — it happens with code reviews, architecture reviews, any process that gets adopted without critical thinking about its purpose. Junaid's insight: if you don't understand the basics with the right mindset, every event feels like overhead. Teams complain about "too many meetings" because they're running agile ceremonies on top of their old informal processes. "If you don't get out of your previous shell, you cannot get into a new shell." [The Scrum Master Toolbox Podcast Recommends]

Junaid Shaikh: The Eager Scrum Master Trap, Why Proposing Solutions Too Early Can Backfire In this episode, Junaid shares a story from his early days as a Scrum Master when enthusiasm got ahead of experience. Fresh from a CSM certification and full of ideas, he walked into teams and started proposing solutions — "No, this is not how you should do it." It felt obvious. It wasn't. The wake-up call came when he proposed working agreements to a team that had been collaborating well for two years. The pushback was immediate: "Why do we need this?" He realized he was bringing a tool he'd seen elsewhere without first understanding whether the team actually had the problem that tool was meant to solve. This led to a key shift in his approach: stop assuming. Instead of going in with answers, Junaid started creating small tiger teams with the affected people, facilitating sessions where they owned the solution. The result? Much higher acceptance and genuine continuous improvement. These days, Junaid tests his ideas before bringing them to the full team. He connects with individual team members first — his "closer allies" — to validate whether his analysis matches reality. Only when a few people confirm "yes, this is a real problem" does he bring the proposal to the group. As Vasco puts it: not all tools are appropriate at all times for all people. The same working agreements that were wrong for one team at one moment might be exactly right for a different team, or the same team at a different moment. [The Scrum Master Toolbox Podcast Recommends]

If you are a Scrum Master, Agile Coach or in a related role and have questions about how to use AI as a tool to better support your job, teams and organization, this episode is for you!AI has become a core capability in product delivery and is transforming every role. Scrum Masters and Agile Coaches have a key part to play in the use of AI and introducing AI to teams, products and organizations, acting as a catalyst for change. Through the proper use of AI tools, Scrum Masters, their teams and organization become more effective. But in what ways can you reap the benefits?In this Ask a PST session hosted by Patricia Kong, PSTs Miriam Blommers and Said Azarfane took listener questions on how to leverage AI to be more successful as a Scrum Master! Whether you are looking to find ways to improve facilitation, collaboration or solve more challenges, get great advice in this episode on how to make AI a helpful and important part of your toolbox!

Nigel Baker: The Scrum Master Mistake of Copy-Pasting Success Instead of Recreating the Journey Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I was trying to recreate the results of our team, not recreate the journey. And that is what killed me to begin with." - Nigel Baker   Nigel fell into Scrum Mastery almost by accident. Working at British Telecom in 2002—before most people had even heard of Scrum—his team adopted it not to speed up, but to add rigor to an already fast-moving tactical unit full of "pirates" who could get stuff done but needed guardrails. His first Scrum Master, Geoff Watts, got promoted and moved on, leaving a vacancy. Nigel was the third person asked—and the first to say yes. He loved the role, but his earliest mistake became his most enduring lesson.  On his very first daily Scrum, Nigel brought a big leather book and wrote down what every team member was doing, acting like a proto-project manager collecting status reports. The team already had all this information in their system—he was unconsciously positioning himself as the authority figure, having people report to him rather than to each other.  As Nigel evolved into an Agile Coach, the bigger failure emerged: trying to copy-paste the process that worked with his first team onto other teams, recreating the results rather than the journey that got them there. Each team needs to evolve its own process—there are no shortcuts to that growth.   In this episode, we refer to the importance of self-awareness and servant leadership in the Scrum Master role.   Self-reflection Question: Are you trying to replicate a successful process from a previous team, or are you investing in helping your current team discover their own path to effectiveness?   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: Coaching Product Owners to Be the Voice of the Customer In this episode, we refer to Henrik Kniberg's "Product Owner in a Nutshell" video and Product Ownership by Geoff Watts. The Great Product Owner: Rob Gard's Customer Obsession 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 role of the PO really is to help the team empathize with the user, the customer of the product, because that's how they can develop great solutions." - Steve Martin   Rob Gard worked at a fintech firm and is now CPO of a major fintech company. Steve describes him as having a brilliant mind and being a real agileist—someone Steve learned a huge amount about Agile from. Rob's defining characteristic was his absolute obsession with the user. Everything focused on customer pain points. Working with engineering teams serving military customers, Rob held regular workshops with those customers to understand their pain firsthand. He was literally the voice of the customer, not theoretically but practically. Rob pushed and challenged teams to be more innovative, always looking for better ways of providing better software. His gift was communication—specifically, briefing the team on the problem rather than just reading out stories in refinement sessions. This is the anti-pattern many Product Owners fall into: going through the motions, reading requirements without context. Real product ownership, as Rob demonstrated, is telling a story that helps the team empathize and understand the pain. When teams can internalize customer problems, they develop better solutions. Rob's ability to communicate the problem into the minds of teams enabled them to serve customers more effectively. This is the essence of great Product Ownership: not being a proxy for management, not juggling multiple teams, but being deeply connected to customer pain and translating that pain into context the team can work with.   Self-reflection Question: Do your refinement sessions tell stories that help the team empathize with customer pain, or do you just read out requirements? The Bad Product Owner: Proxies for Management Instead of Customer Advocates 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 weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte   Steve emphasizes that Product Owners often have great intentions but struggle due to lack of training and coaching. The anti-patterns are systemic: commercial managers "dressed up" as Product Owners without understanding the role. Project managers transitioning to PO roles—though Steve notes PMs can make really good POs with proper support. The most damaging pattern is Product Owners spread across multiple teams, having very little time to focus on any single team or their customers. These POs become proxies—representing the voice of senior management rather than the voice of the customer. They cascade requirements downward instead of bringing customer insights upward. The solution isn't to criticize these struggling Product Owners but to help them understand their role and see what good looks like. Steve recommends Henrik Kniberg's "Product Owner in a Nutshell" video—15 minutes, 15 years old, still profoundly relevant. He also points to Product Ownership by Geoff Watts and formal training like CSPO or IC Agile Product Ownership courses. The fundamental issue is meeting Product Owners where they are, providing coaching and support to transform them from management proxies into customer advocates. When POs understand their role as empathy builders between customers and teams, everything changes.   Self-reflection Question: Is your Product Owner the voice of senior management or the voice of the customer?   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: Making Scrum Master Success Visible with OKRs That Actually Work Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "It is not the retrospective that is the success of the retrospective. It is the ownership and accountability where you take improvements after the session." - Steve Martin   The biggest problem for Scrum Masters isn't just defining success—it's being able to shout it from the rooftops with tangible evidence. Steve champions OKRs as an amazing way to define and measure success, but with a critical caveat: they've historically been poorly written and implemented in dark rooms by executives, then cascaded down to teams who never bought in. Steve's approach is radically different. Create OKRs collectively with the team, stakeholders, and end users. Start by focusing on the pain—what problems or pain points do customers, users, and stakeholders actually experience? Make the objective the goal to solve that problem, then define how to measure progress with key results. When everyone is bought in—Scrum Master, engineers, Product Owner, stakeholders, leaders—all pulling in the same direction, magic happens. Make progress visible on the wall like a speedometer, showing exactly where you are at any moment. For an e-commerce checkout, the problem might be too many steps. The objective: reduce pain for users checking out quickly. The baseline: 15 steps today. The target: 5 clicks in three months. Everyone can see the dial moving. Everything should focus on the customer as the endpoint. The challenge is distinguishing between targets imposed from above ("increase sales by 10%") and objectives created collaboratively based on factors the team can actually control. Find what you can control first, work with customers to understand their pain, and start from there.   Self-reflection Question: Can you articulate your team's success with specific, measurable outcomes that everyone—from developers to executives—understands and owns? Featured Retrospective Format for the Week: Post-Retro Actions and Ownership The success of a retrospective isn't the retrospective itself—it's what happens after. Steve emphasizes that ownership and accountability matter more than the format of the session. Take improvements from the retrospective and bring them into the sprint as user stories with clear structure: this is the problem, how we'll solve it, and how we'll measure impact. Assign collective ownership—not just a single person, but the whole team owns the improvement. Then bring improvements into the demo so the team showcases what changed. This creates cultural transformation: the team themselves want to bring improvements, not just because the Scrum Master pushed them. For ongoing impediments, conduct root cause analysis. Create a system to escalate issues beyond the team's control—make these visible on another board or with the leadership team. Find peers in pain: teams with the same problems can work together collectively. The retrospective format matters less than this system of ownership, action, measurement, and visibility. Stop retrospective theatre—going through the motions without taking action. Make improvements real by treating them like any other work: visible, measured, owned, and demonstrated.   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: Why Agile Fatigue Means We Need to Change Our Approach Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "We teach transformation, we support transformation, we help change, but we don't really understand what they're changing from." - Steve Martin   Steve believes Agile as a whole is on the back foot, possibly regressing. There's palpable fatigue in the industry, and transformation in its current form hasn't been the success we hoped. Organizations still need to work in a state of agility—making rapid decisions, aligning teams, delivering value at pace—but they're exhausted by how we've implemented Agile. As Agile professionals, Steve argues, we have a responsibility to take stock and reflect on what's not working. The problem isn't that organizations don't need agility; it's that we've been force-feeding them frameworks without understanding their context. Steve invokes an ancient principle: "When the student is ready, the teacher will appear." But we haven't waited for readiness—we've barged in with Big Bang transformations, bringing 10, 15, or 20 Agile coaches to "save the world." The solution requires meeting people where they are, understanding what they're changing from, not just what they're changing to. Steve's coaching conversation centers on a radical idea: stop trying to help teams that don't want to be helped. Focus on teams already interested in incremental, adaptable delivery. Run small pilots, learn what works, then scale when ready. The age of prescriptive transformation is over. We need to adapt to the reality of the moment, experiment with what works, and have the courage to change the plan when our approach isn't working.   Self-reflection Question: Are you forcing Agile on teams that aren't ready, or are you working with those who genuinely want to improve their delivery approach?   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: When a Distributed Team's Energy Vanishes into the Virtual Void 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 weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte (describing Steve's team situation)   The infrastructure team looked promising on paper: Product Owner in Italy, hardware engineers in Budapest, software engineers in Bucharest, designers in the UK. The team started with energy and enthusiasm, but within a month, something shifted. People stopped showing up for daily stand-ups. Cameras went dark during meetings. Engagement in retrospectives withered. This wasn't just about being distributed—plenty of teams work across time zones successfully. The problem ran deeper. The Scrum Master had a conflict of interest, serving dual roles as both facilitator and engineer. Team members were simultaneously juggling three or four other projects, treating this work as just another item on an impossibly long list. Steve spent a couple of months watching the deterioration before recognizing the root cause: there was no leadership sponsorship or buy-in. Stakeholders weren't invested. The team wasn't actually a team—they were individuals happening to work on the same project. Steve considers this a failure because he couldn't solve it. Sometimes, the absence of organizational support creates an unsolvable puzzle. Without leadership commitment, even the most skilled Scrum Master can't manufacture the conditions for team success.   In this episode, we refer to The Phoenix Project by Gene Kim, a book about organizational culture disguised as a DevOps novel.   Self-reflection Question: Is your team truly dedicated to one mission, or are they a collection of individuals spread across competing priorities? Featured Book of the Week: The Phoenix Project by Gene Kim "There's a lot of good lightning bulb moments that go off." - Steve Martin   Steve describes The Phoenix Project as a book about culture, not just DevOps. Written like a novel following a mock company, it creates continuous light bulb moments for readers. The book resonated deeply with Steve because it exposed patterns he'd experienced firsthand—particularly the anti-pattern of single points of failure. Steve had worked with an engineer who would spend entire weekends doing releases, holding everything in his head, then burning out and taking three days off to recover. This engineer was the bottleneck, the single point of failure that put the entire system at risk. The Phoenix Project illuminates how knowledge hoarding and dependency on individuals creates organizational fragility. The solution isn't just technical—it's cultural. Teams need to share knowledge and understanding, deliberately de-risking the concentration of expertise in one person's mind. Steve recommends this book for anyone trying to understand why organizational transformation requires more than process changes—it demands a fundamental shift in how teams think about knowledge, risk, and collaboration.   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: When the Gospel of Agile Becomes a Barrier to 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.   "It took me a while to realize that that's what I was doing. I felt the reason wasn't working was them, it wasn't me." - Steve Martin   Steve carried the Scrum Guide like a Bible in his early days as an Agile coach. He was a purist—convinced he had an army of Agile practitioners behind him, ready to transform every team he encountered. When teams questioned his approach, he would shut down the conversation: "Don't challenge me on this, because this is how it's supposed to be." But pushing against the tide and spreading the gospel created something unexpected: resistance. The more Steve insisted on his purist view, the more teams pushed back. It took him a couple of years to recognize the pattern. The problem wasn't the teams refusing to change—it was his approach. Steve's breakthrough came when he started teaching and realized he needed to meet people where they are, not force them to come to him. Like understanding a customer's needs, he learned to build empathy with teams, Product Owners, and leaders. He discovered the power of creating personas for the people he was coaching, understanding their context before prescribing solutions. The hardest part wasn't learning this lesson—it was being honest about his failures and admitting that his righteous certainty had been the real impediment to transformation.   Self-reflection Question: Are you meeting your teams where they are, or are you pushing them toward where you think they should be?   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: From Spreadsheets to Discovery—Helping POs Make the Transition The Great Product Owner: Taking Ownership and Coaching the Team Forward 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.   "That person was not just a great product owner, but a great coach—he had excellent communication and stakeholder management skills, and he coached myself as a Scrum Master, showing me how product ownership should look like." - Natalia Curusi   Natalia worked with a Product Owner who embodied everything the role should be. He didn't come from a technical background, but he possessed exceptional domain knowledge, outstanding communication skills, and stakeholder management expertise you rarely find in one person. What made him truly remarkable was that he coached everyone around him, including Natalia as the Scrum Master.  He demonstrated full empowerment and ownership—making decisions himself rather than constantly escalating to higher management. When risks needed to be taken, he took them with courage and conviction. The team trusted him completely because he balanced business needs with team capacity, always understanding what they could realistically achieve. Over the past five years, this person has been promoted multiple times and now serves as a global director of product, still with the same company.  When Natalia thinks about what great product ownership looks like, she thinks of him—someone who combined technical understanding with coaching ability, took genuine ownership of outcomes, and empowered the team through clear vision and decisive leadership. These are exactly the skills that are hardest to find in the market, yet when you find them, the impact is transformative for the entire organization.   Self-reflection Question: Does your Product Owner take ownership and make decisions, or do they constantly escalate to higher management, preventing the team from moving forward with confidence? The Bad Product Owner: Assigned Without Training, Support, or Willingness "She was a great subject matter expert with deep domain knowledge, but the organization assigned her the product owner role without her willingness, without training, and while she was already 80% loaded with other responsibilities." - Natalia Curusi   Natalia encountered a Product Owner anti-pattern that reveals a systemic organizational failure. The person was an exceptional subject matter expert with incredible domain knowledge, but when the organization decided to adopt Agile, they assigned her the PO role like sticking a label on a box—no training, no consent, no preparation. She was already working at 80% capacity on other responsibilities and had no understanding of what product ownership meant. Frustrated and overwhelmed, she approached the role from a command-and-control mindset. At the project start, she brought a massive spreadsheet of requirements, expecting the team to implement them sequentially.  The team tried a different approach, wanting to understand problems before discussing solutions, but the PO surprised everyone by re-introducing the spreadsheet in a later meeting—a clear sign of misalignment and broken trust. Natalia, recognizing this was a battle she couldn't win without organizational support, chose to manage the relationship rather than create open conflict. She worked to mediate between the PO's spreadsheet approach and the team's need for discovery and iterative development. The real anti-pattern wasn't the individual—it was the organization assigning critical roles without providing training, time, or psychological safety. This situation illustrates why product ownership fails: not from bad people, but from bad systems that set people up to fail.   Self-reflection Question: When you see a struggling Product Owner, are you addressing the individual's behavior or the systemic conditions that set them up to fail in the first place?   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: Measuring What Matters Beyond Velocity and Story Points Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "We as Scrum Masters need to put a scope for ourselves—we need to aim to leave the place where we work a little bit better than it was, and to make sure that this place could improve itself without us." - Natalia Curusi   Natalia defines success for Scrum Masters with crystal clarity: leave the organization better than you found it, and ensure it can continue improving when you're gone. This means fostering independence and ownership in teams so they can perform whether you're on vacation, in another meeting, or have moved to coaching other teams.  The opposite pattern—where everything falls apart when the Scrum Master isn't present—reveals someone who hasn't truly succeeded in the role. Natalia also emphasizes the importance of establishing metrics early, but not the traditional ones.  Using velocity as a metric is an anti-pattern that focuses teams on the wrong outcomes. Instead, she recommends metrics like predictability, team morale, psychological safety measured through 360 feedback, and the quality of conversations both within teams and with stakeholders. But metrics alone don't tell the story.  Natalia champions the concept of Gemba walks—going to see what's actually happening, talking to people, observing the reality rather than just reviewing dashboard numbers. Some metrics are easily gamed, others provide only narrow perspectives on reality. The most important practice is using metrics to trigger reflection and adaptation, not as fixed targets. Natalia believes strongly that the quality of conversations—how teams discuss options, make decisions together, and adapt when facing pressure—reveals more about a Scrum Master's success than any velocity chart ever could. The ultimate question: can your team succeed without you?   Self-reflection Question: If you disappeared from your team tomorrow, would they continue improving, or would progress stop until someone replaced you? Featured Retrospective Format for the Week: Spotify Squad Health Check "This is a multidimensional retro that I run with teams every 2 to 3 months—you need around 30 minutes for it, and I often get insights and new ideas from this retrospective that help me as a Scrum Master." - Natalia Curusi   The Spotify Squad Health Check is Natalia's favorite retrospective format because it provides a comprehensive view of team health across multiple dimensions. Unlike traditional retrospectives that might focus on a single sprint or specific issue, this format examines the team's overall state across areas like teamwork, support, mission clarity, and technical quality. Teams rate themselves on various health indicators, creating a visual representation that reveals patterns over time.  What makes this particularly valuable is that it works whether you know the team well or are just starting with them—either way, you gain insights and "aha moments" about where the team truly stands. The multidimensional nature prevents teams from optimizing just one aspect while neglecting others, and the regular cadence (every 2-3 months) allows you to track trends and celebrate improvements.  For Natalia, this format consistently surfaces the hidden challenges that teams might not raise in regular retrospectives, making it an essential tool in her Scrum Master toolkit.   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: Demonstrating Your Value When the Market Questions Agile 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.   "My challenging topic is about the demand of agility in the market—how do we fit ourselves as scrum masters in that AI era? How can we demonstrate our competence and contribution when there's a perception that agile roles bring little value?" - Natalia Curusi   Natalia faces the challenge every Scrum Master in 2025 grapples with: how to demonstrate value in an era when business perceives agile roles as optional overhead. The market has contracted, companies are optimizing budgets, and Scrum Masters often appear first on the chopping block.  There's talk of "blended roles" where developers are expected to absorb Scrum Master responsibilities, and questions about how AI might replace the human facilitation work that coaches provide. But Natalia believes the answer lies in understanding something fundamental: the Scrum Master is a deeply situational and contextual role that adapts to what the team needs each day.  Some teams need help with communication spaces, others need work structure like Kanban boards, still others need translation between technical realities and stakeholder expectations. The challenge is that this situational nature makes it incredibly hard to explain to business leaders who think in fixed job descriptions and measurable outputs. Natalia's approach involves bringing metrics—not velocity, which focuses on the wrong things, but metrics around team independence, continuous improvement, and organizational capability. She suggests concepts like Gemba walks—going to see what's actually happening rather than relying only on numbers. The real question Natalia poses is this: the biggest value we can bring to an organization is to leave it better than we found it, but how do we make that visible and tangible to business stakeholders who need justification for our roles?   Self-reflection Question: If you had to demonstrate your value as a Scrum Master using only observable evidence from the past month, what would you show your leadership?   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: The Dark Side of High-Performing Dream Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I was proud of this team—I helped form them from the start, we traveled to the client together, they were mature and independent, they even jelled outside the workplace. This was my dream team." - Natalia Curusi   Natalia had built something special. The team was technically strong, emotionally connected, and highly productive. They socialized outside work, traveled together to client sites, and operated with remarkable independence. But when a new junior developer joined, everything started to unravel.  The existing team members were like heroes—fast, skilled, confident. The newcomer couldn't keep pace, and slowly Natalia noticed something disturbing: the team started making fun of the new member during retrospectives and stand-ups. The person became an outlier, a black swan ignored by the group. Natalia conducted one-on-one meetings with both the new member and the team, but the situation only worsened. The new person insisted they were fine and didn't need help. The team members claimed they were just joking around. Meanwhile, the team structure and morale deteriorated.  Natalia realized she was watching her dream team self-destruct through a form of bullying—something she hadn't even recognized at the time. Finally, she understood she couldn't handle this alone and escalated to the head of discipline and the organizational psychologist. Together, they decided to rotate the person to another team where they felt more comfortable. Natalia learned a painful lesson: as Scrum Masters, we don't need to solve everything ourselves, and sometimes the best solution is recognizing when to use the support structure around us rather than treating it as a personal failure.   In this episode, we refer to Coaching Agile Teams by Lyssa Adkins and Training from the Back of the Room by Sharon Bowman.   Self-reflection Question: When have you witnessed subtle forms of exclusion in your team, and did you recognize them early enough to intervene effectively? Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins "This was the first book about agile coaching that I read, and it's how I understood that I was already playing the scrum master role without even knowing it—I understood that I was already acting like a glue for the team." - Natalia Curusi   Natalia discovered Coaching Agile Teams at a pivotal moment in her career. The book revealed something profound: if you're irreplaceable, there's a problem. A great Scrum Master or coach makes themselves obsolete by growing team members who can replace them. The team should be able to perform independently when you're on vacation or move to another assignment. Lyssa Adkins showed Natalia that she needed to let go of over-control and over-responsibility, focusing instead on growing the team's capabilities. The book remains one of Natalia's top recommendations for every junior Scrum Master wanting to embrace the role, alongside Training from the Back of the Room, which teaches facilitators how to run interactive workshops where people learn from each other rather than just listening to slides.   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: When Your Technical Expertise Becomes Your Biggest Scrum Master Weakness 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 thought my technical background was my biggest strength, but I understood that this was my biggest weakness—I was coming into stand-ups saying 'I know how we need to fix that issue,' and I was a Scrum Master." - Natalia Curusi   Natalia stepped into her first blended role as team leader and Scrum Master full of confidence. With years of programming experience behind her, she believed she could guide her team through any technical challenge. But during morning stand-ups, she found herself suggesting solutions, directing technical approaches, and sharing her expertise freely. The team listened—after all, she was their former leader. They implemented her suggestions, but when those solutions failed, the team didn't have the thinking process to adapt them to their context.  Natalia realized she was preventing the team's learning and ownership by taking control away from them. The turning point came when she made a deliberate choice: she selected the most technical person on the team to become the technical authority and committed to never stepping on his feet again. From that moment forward, she focused purely on the Scrum Master role—asking questions, fostering collaboration, and shutting up to listen actively.  Years later, that technical lead followed her to another job, and they remain friends to this day. Natalia learned that her contribution wasn't about giving solutions—it was about keeping the team from losing ownership of their work.   Self-reflection Question: When you attend your team's daily stand-up, are you contributing to collaboration, or is your contribution keeping the team from owning their work?   [The Scrum Master Toolbox Podcast Recommends]

Kirsten Maitland, co-founder and "CheeseMaster" of the critically acclaimed Rebel Cheese, recently joined The Ash Said It Show to pull back the curtain on the brand's meteoric rise. From military discipline to the largest vegan brie cavein the country, Maitland shared the surprising secrets behind her Shark Tank success and how she's converting die-hard dairy lovers one creamy, cultured wheel at a time. This episode is a must-listen for anyone interested in vegan food innovation, conscious business growth, and the power of a daring career pivot. Maitland was clear that the brand's success in creating the "world's best artisan vegan brie" comes from rejecting modern shortcuts. The company's commitment to traditional cheesemaking techniques—including the use of a temperature and humidity-controlled vegan brie cave—is non-negotiable. This meticulous aging process, she explained, is essential for cultivating the complex, "funky" flavor profiles and genuine textures that simply cannot be achieved with food science alone. The shocking truth? Most of Rebel Cheese's customers are not vegan. Maitland credited this conversion success to two key factors: flavor and familiarity. The cheeses are designed to function exactly like their dairy counterparts—they slice, melt, and hold up on a dairy-free charcuterie board. By focusing on replicating beloved classics like their Smoked Cheddar and Cave-Aged Brie, Rebel Cheese removes the intimidating element of the unknown for traditional cheese lovers. What non-obvious skill does a former Navy veteran entrepreneur bring to making plant-based cheese? Protocol Adherence and Adaptability. Maitland revealed that her experience as an Operations Specialist and later an Agile Coach in Big Tech taught her to build robust, repeatable processes (critical for food safety and quality control) while maintaining the agility to quickly iterate on recipes and scale production. This structure is the unseen foundation that supports the brand's artisanal quality at a mass scale. The Shark Tank investment from Mark Cuban and Lori Greiner caused an "explosion" in e-commerce orders. Maitland explained that scaling meant implementing a modular production system. Rather than sacrificing the small-batch, handcrafted process, they replicated it. They invested in equipment to handle the raw material processing (cashews) efficiently, but kept the culturing, aging, and finishing of the cheese strictly hands-on, ensuring the artisanal standard remains in every wheel shipped nationwide. Beyond the capital and media boost, Maitland's most valuable takeaway was the need for ruthless strategic focus. The Sharks' scrutiny forced the team to prioritize the most scalable, high-margin products—the ones that truly "rebelled" against expectations—allowing them to streamline their offerings and dominate the premium plant-based cheese market. In a transparent discussion, Maitland addressed the realities of running a high-growth business while staying true to its values. She emphasized that balancing the "values-led" mission with the demands of a "financially sustainable small business" requires transparent communication and strategic operational contractionswhen necessary. The core principle, she stated, is integrity—in their product, their financials, and their public messaging. Maitland sees the next major hurdle for high-end vegan food innovation not in replicating flavor, but in achieving price parity with dairy. The strategy for Rebel Cheese is to leverage increased volume and better supply chain relationships to drive down the cost of premium ingredients, ultimately making gourmet dairy-free foods accessible to the mass market and leading the charge into a truly plant-powered future. Web: https://rebelcheese.com Rebel Cheese is the critically acclaimed, Austin, Texas-based gourmet food company and brick-and-mortar bistro that is revolutionizing the plant-based cheese industry. Founded by the dynamic, globe-trotting duo, Kirsten Maitland and Fred Swar, Rebel Cheese has successfully challenged the notion that high-quality, artisanal cheese requires dairy, becoming a globally recognized brand in the vegan food and dairy-free charcuterie space. The brand was born out of co-founder Kirsten Maitland's personal journey to find flavorful, satisfying, and sophisticated vegan cheese alternatives after adopting a plant-based diet. She recognized a massive gap in the market: while basic dairy-free cheeses existed, none truly captured the complex textures, sharp flavors, and aging processes of traditional European cheeses. Rebel Cheese's mission is simple yet audacious: to create handcrafted, gourmet plant-based cheeses that are indistinguishable from their dairy counterparts in taste, texture, and melting properties. They achieve this by using old-world cheesemaking techniques—including culturing, aging, and ripening—but substituting cow or goat milk with a base of organic cashew milk and fava bean protein. Rebel Cheese gained massive national attention after appearing on the hit show Shark Tank. The company impressed the notoriously skeptical investors, with billionaire Mark Cuban quickly becoming an investor after declaring their products, particularly the Brie, tasted exactly like traditional cheese. For customers outside of Texas, Rebel Cheese ships its artisanal cheeses and curated gift boxes nationwide, bringing its award-winning plant-based cheese directly to consumers across the country. Ash Brown: Your Ultimate Guide to Inspiration, Empowerment & Action Looking for a motivational speaker, authentic podcaster, or influential media personality who can spark your journey toward personal growth? Meet Ash Brown — a dynamic American powerhouse known for her uplifting energy, relatable wisdom, and unwavering commitment to helping others unlock their full potential. Ash is a: Captivating event host Insightful lifestyle blogger Popular podcast creator Trusted voice in personal development Her mission? To empower individuals with real-world strategies, positive mindset tools, and actionable advice that lead to lasting transformation. Discover Ash Brown's World AshSaidit.com – Lifestyle Blog & Event Hub Explore exclusive event invites, honest product reviews, and daily inspiration through Ash's vibrant online platform. AshSaidit.com is your go-to destination for personal growth content, wellness tips, and authentic storytelling. The Ash Said It Show – Top-Ranked Podcast With over 2,100 episodes and 700,000+ global listens, Ash's podcast features inspiring interviews, life lessons, and empowerment stories from changemakers across industries. Each episode delivers practical tools and encouragement to help listeners thrive. Why Ash Brown Is a Leading Voice in Personal Development Ash Brown stands out for her: Authentic Optimism – Her contagious positivity helps audiences embrace challenges with confidence Relatable Advice – Ash shares unfiltered, honest insights that resonate across cultures and backgrounds Actionable Strategies – From mindset shifts to goal-setting, Ash equips listeners with tools to create real change Whether you're seeking career motivation, emotional resilience, or daily inspiration, Ash Brown is the trusted guide to help you rise. Website: AshSaidit.com Podcast: The Ash Said It Show (available on Spotify, Apple Podcasts, Google Podcasts) Connect with Ash Brown: Goli Gummy Discounts: https://go.goli.com/1loveash5 Luxury Handbag Discounts: https://www.theofficialathena.... Review Us: https://itunes.apple.com/us/po... Subscribe on YouTube: http://www.youtube.com/c/AshSa... Instagram: https://www.instagram.com/1lov... Facebook: https://www.facebook.com/ashsa... Blog: http://www.ashsaidit.com/blog #atlanta #ashsaidit #theashsaiditshow #ashblogsit #ashsaidit®Become a supporter of this podcast: https://www.spreaker.com/podcast/ash-said-it-show--1213325/support.

Darryl Wright: The PONO—Product Owners in Name Only and How They Destroy Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Collaborative, Present, and Clear in Vision   "She was collaborative, and that meant that she was present—the opposite of the MIA product owner. She came, and she sat with the team, and she worked with them side by side. Even when she was working on something different, she'd be there, she'd be available." - Darryl Wright   Darryl shares an unusual story about one of the best Product Owners he's ever encountered—someone who had never even heard of Agile before taking the role. Working for a large consulting company with 170,000 staff worldwide, they faced a difficult project that nobody wanted to do. Darryl suggested running it as an Agile project, but the entire team had zero Agile experience. The only person who'd heard of Agile was a new graduate who'd studied it for one week at university—he became the Scrum Master. The executive sponsor, with her business acumen and stakeholder management skills, became the Product Owner despite having no idea what that meant.  The results were extraordinary: an 18-month project completed in just over 7 months, and when asked about the experience, the team's highest feedback was how much fun they had working on what was supposed to be an awful, difficult project. Darryl attributes this success to mindset—the team was open and willing to try something new.  The Product Owner brought critical skills to the role even without technical Agile knowledge: She was collaborative and present, sitting with the team and remaining available. She was decisive, making prioritization calls clearly so nobody was ever confused about priorities. She had excellent communication skills, articulating the vision with clarity that inspired the team. Her stakeholder management capabilities kept external pressures managed appropriately. And her business acumen meant she instantly understood conversations about value, time to market, and customer impact.  Without formal training, she became an amazing Product Owner simply by being open, willing, and committed. As Darryl reflects, going from never having heard of the role to being an inspiring Product Owner in 7 months was incredible—one of the most successful projects and teams he's ever worked with.   Self-reflection Question: If you had to choose between a Product Owner with deep Agile certification and no business skills, or one with strong business acumen and willingness to learn—which would serve your team better? The Bad Product Owner: The PONO—Product Owner in Name Only   "The team never saw the PO until the showcase. And so, the team would come along with work that they deemed was finished, and the product owner had not seen it before because he wasn't around. So he would be seeing it for the first time in the showcase, and he would then accept or reject the work in the showcase, in front of other stakeholders." - Darryl Wright   The most destructive anti-pattern Darryl has witnessed was the MIA—Missing in Action—Product Owner, someone who was a Product Owner in Name Only (PONO). This senior business person was too busy to spend time with the team, only appearing at the sprint showcase. The damage this created was systematic and crushing. The team would build work without Product Owner engagement, then present it in the showcase looking to be proud of their accomplishment.  The PO, seeing it for the first time, would accept or reject the work in front of stakeholders. When he rejected it, the team was crushed, deflated, demoralized, and made to look like fools in front of senior leaders—essentially thrown under the bus. This pattern violates multiple principles of Agile teamwork. First, there's no feedback loop during the sprint, so the team works blind, hoping they're building the right thing. Second, the showcase becomes a validation ceremony rather than a collaborative feedback session, creating a dynamic of subservience rather than curiosity. The team seeks approval instead of engaging as explorers discovering what delivers customer value together. Third, the PO positions themselves as judge rather than coach—extracting themselves from responsibility for what's delivered while placing all blame on the team.  As Deming's quote reminds us, "A leader is a coach, not a judge." When the PO takes the judge role, they're betraying fundamental Agile values.  The responsibility for what the team delivers belongs strictly to the Product Owner; the team owns how it's delivered.  When Darryl encounters this situation as a Scrum Master, he lobbies intensely with the PO: "Even if you can't spare any other time for the entire sprint, give us just one hour the night before the showcase." That single hour lets the team preview what they'll present, getting early yes/no decisions so they never face public rejection. The basic building block of any Agile or Scrum way of working is an empowered team—and this anti-pattern strips all empowerment away.   Self-reflection Question: Does your Product Owner show up as a coach who's building something together with the team, or as a judge who pronounces verdicts? How does that dynamic shape what your team is willing to try?   [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: The Retrospective Formats That Actually Generate 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. "My success is, how much have I helped the team achieve what they want? If what they want is to uplift quality, or to reduce their time to market, well then, my success is helping them achieve that." - Darryl Wright When Darryl enters a new organization, he's often told his success will be measured by percentage of Agile adoption or team maturity assessment scores. His response is direct: those are vanity metrics that show something for its own sake, not real success. True success requires multiple measures, carefully balanced to prevent gaming and to capture both the human and business dimensions of work. Darryl advocates balancing quantitative metrics like lead time and flow efficiency with qualitative measures like employee happiness and team self-assessment of productivity. He balances business outcomes like customer satisfaction and revenue with humanity metrics that track the team's journey toward high performance. Most importantly, Darryl believes his success metrics should be co-created with the team. If he's there to help the team, then success must be defined by how much he's helped them achieve what they want—not what he wants. When stakeholders fixate on output metrics like "more story points," Darryl uses a coaching approach to shift the conversation toward outcomes and value. "Would you be happy if your team checked off more boxes, but your customers were less happy?" he asks. This opens space for exploring what they really want to achieve and why it matters. The key is translating outputs into impacts, helping people articulate the business value or customer experience improvement they're actually seeking. As detailed in Better Value, Sooner, Safer, Happier by Jonathan Smart, comprehensive dashboards can track value across multiple domains simultaneously—balancing speed with quality, business success with humanity, quantitative data with qualitative experience. When done well, Agile teams can be highly productive, highly successful, and have high morale at the same time. We don't have to sacrifice one for the other—we can have both. Self-reflection Question: If your team could only track two metrics for the next sprint, what would they choose? What would you choose? And more importantly, whose choice should drive the selection? Featured Retrospective Format for the Week: The 4 L's and Three Little Pigs Darryl offers two favorites, tailored to different contexts. For learning environments, he loves the 4 L's retrospective: Liked, Learned, Lacked, and Longed For. This format creates space for teams to reflect on their learning journey, surfacing insights about what worked, what was missing, and what they aspire to moving forward. For operational environments, he recommends the Three Little Pigs retrospective, which brilliantly surfaces team strengths and weaknesses through a playful metaphor. The House of Straw represents things the team is weak at—nothing stands up, everything falls over. The House of Sticks is things they've put structure around, but it doesn't really work. The House of Bricks represents what they're solid on, what they can count on every time. Then comes the most important part: identifying the Big Bad Wolf—the scary thing, the elephant in the room that nobody wants to talk about but everyone knows is there. This format creates psychological safety to discuss the undiscussable. Darryl emphasizes two critical success factors for retrospectives: First, vary your formats. Teams that hear the same questions sprint after sprint will disengage, asking "why are you asking me again?" Different questions provide different lenses, generating fresh insights. Second, ensure actions come out of every retro. Nothing kills engagement faster than suggestions disappearing into the void. When people see their ideas lead to real changes, they'll eagerly return to the next retrospective. And don't forget to know your team—if they're sports fans, use sports retros; if they're scientists, use space exploration themes. Just don't make the mistake of running a "sailboat retro" with retiring mainframe engineers who'll ask if you think they're kindergarten children. For more retrospective formats, check out Retromat. [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: Why AI Adoption Will Fail Just Like Agile Did—Unless We 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. "People are looking to AI to solve their problems, and they're doing it in the same way that they previously looked to Agile to solve their problems for them. The problem with that is, of course, that Agile doesn't solve problems for you. What it does is it shines a light on where your problems are." - Darryl Wright The world has gone AI crazy, and Darryl sees history repeating itself in troubling ways. Organizations are rushing to adopt AI with the same magical thinking they once applied to Agile—believing that simply implementing the tool will solve their fundamental problems. But just as Agile reveals problems rather than solving them, AI will do the same. Worse, AI threatens to accelerate existing problems: if you have too many things moving at once, AI won't fix that, it will amplify the chaos. If you automate a bad process, you've simply locked in badness at higher speed. As Darryl points out, when organizations don't understand that AI requires them to still do the hard work of problem-solving, they're setting themselves up for disillusionment, and in five or twenty years, we'll hear "AI is dead" just like we now hear "Agile is dead." The challenge for Scrum Masters and Agile coaches is profound: how do you help people with something they don't know they need? The answer lies in returning to first principles. Before adopting any tool—whether Agile or AI—organizations must clearly define the problem they're trying to solve. As Einstein reportedly said, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions." Value stream mapping becomes essential, allowing teams to visualize where humans and AI agents should operate, with clear handovers and explicit policies. The cognitive load on software teams will increase dramatically as AI generates more code, more options, and more complexity. Without clear thinking about problems and deliberate design of systems, AI adoption will follow the same disappointing trajectory as many Agile adoptions—lots of activity, little improvement, and eventually, blame directed at the tool rather than the system. Self-reflection Question: Are you adopting AI to solve a clearly defined problem, or because everyone else is doing it? If you automated your current process with AI, would you be locking in excellence or just accelerating dysfunction? [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: The Agile Team That Committed to Failure for 18 Sprints Straight 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. "As Deming said, a bad system will beat a good person every time." - Darryl Wright Darryl was called in to help a struggling team at a large energy retailer. The symptoms seemed straightforward—low morale, poor relationships, and chronic underdelivery. But as he asked questions, a heartbreaking pattern emerged. The team had been "committing" to 110 story points per sprint while consistently delivering only 30. For 18 sprints. When Darryl asked why the team would commit to numbers they couldn't possibly achieve, the answer was devastating: "The business needs that much." This wasn't a problem of skill or capability—it was learned helplessness in action. Sprint after sprint, the team experienced failure, which made them more despondent and less effective, creating a vicious downward spiral. The business lost trust, the team lost confidence, and everyone was trapped in a system that guaranteed continued failure. When Darryl proposed the solution—committing to a realistic 30 points—he was told it was impossible because "the business needs 110 points." But the business wasn't getting 110 points anyway. They were getting broken promises, a demoralized team, stress leave, high churn, and a relationship built on distrust. Darryl couldn't change the system in that case, but the lesson was clear: adult people who manage their lives perfectly well outside work can become completely helpless inside work when the system repeatedly tells them their judgment doesn't matter. As Ricardo Semler observes in Maverick!, people leave their initiative at the door when organizations create systems that punish honest assessment and reward false promises. Self-reflection Question: Is your team committing to what they believe they can achieve, or to what they think someone else wants to hear? What would happen if they told the truth? Featured Book of the Week: Better Value, Sooner, Safer, Happier by Jonathan Smart Darryl describes Better Value, Sooner, Safer, Happier by Jonathan Smart as a treasure trove of real-life experience from people who have "had their sleeves rolled up in the trenches" for decades. What he loves most is the authenticity—the authors openly share not just their successes, but all the things that didn't work and why. One story that crystallizes the book's brilliance involves Barclays Bank and their ingenious approach to change adoption. Facing resistance from laggards who refused to adopt Agile improvements despite overwhelming social proof, they started publishing lists of "most improved teams." When resisters saw themselves at the bottom of these public lists, they called to complain—and were asked, "Did you have improvements we didn't know about?" The awkward pause would follow, then the inevitable question: "How do I get these improvements?" Demand creation at its finest. Darryl particularly appreciates that the authors present at conferences saying, "Let me tell you about all the things we've stuffed up in major agile transformations all around the world," bringing genuine humility and practical wisdom to every page. [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: When Enthusiasm Became Interference—Learning to Listen as a Scrum Master Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Wait stands for Why Am I Talking? Just ask yourself, wait, why am I talking? Is this the right moment for you to give an idea, or is this the right moment to just listen and let them have space to come up with ideas?" - Darryl Wright   Early in his Agile journey, Darryl was evangelically enthusiastic about the principles and practices that had transformed his approach to leadership. He believed he had discovered the answers people were seeking, and his excitement manifested in a problematic pattern—he talked too much. Constantly jumping in with solutions, ideas, and suggestions, Darryl dominated conversations without realizing the impact. Then someone pulled him aside with a generous gift: "You're not really giving other people time to come up with ideas or take ownership of a problem."  They introduced him to WAIT—Why Am I Talking?—an acronym that would fundamentally shift his coaching approach. This simple tool forced Darryl to pause before speaking and examine his motivations. Was he trying to prove himself? Did he think he knew better? Or was this genuinely the right moment to contribute? As he practiced this technique, Darryl discovered something profound: when he held space and waited, others would eventually step forward with insights and solutions.  The concept of "small enough to try, safe enough to fail" became his framework for deciding when to intervene. Not every moment requires a Scrum Master to step in—sometimes the most powerful coaching happens in silence. By developing better skills in active listening and learning to hold space for others, Darryl transformed from someone who provided all the answers into someone who created the conditions for shared leadership to emerge.   In this episode, we refer to David Marquet's episodes on the podcast for practical techniques on holding space and enabling leadership in others.   Self-reflection Question: When was the last time you caught yourself jumping in with a solution before giving your team space to discover it themselves? What would happen if you waited just five more minutes?   [The Scrum Master Toolbox Podcast Recommends]

In this episode of the Agilists: Aspire and Achieve podcast, host Renae Craven chats to Anne Monterio about her move from her home country of Brazil to Germany. Anne shares practical advice and tips on what to do to prepare for a move and how to settle into a new country and environment. About the Featured Guest Anne is an expert in Agile methodologies, project management, and product development. As a Product and Agile Coach at HelloFresh with over ten years at IBM, Anne has led agile transformations to boost team performance and customer satisfaction. Anne advocates for diversity, openness, and empathy believing these values are key to overcoming challenges and is passionate about creating tech products that simplify life. Follow Anne on LinkedIn (www.linkedin.com/in/anne-bravieira) The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared. Podcast Library: www.womeninagile.org/podcast Women in Agile Org Website: www.womeninagile.org  Connect with us on social media! LinkedIn: www.linkedin.com/company/womeninagile/ Instagram: www.instagram.com/womeninagile/ Twitter: www.twitter.com/womeninagileorg    Please take a moment to rate and review the Women in Agile podcast on your favorite podcasting platform. This is the best way to help us amplify the voices and wisdom of the talent women and allies in our community! Be sure to take a screenshot of your rating and review and post it on social media with the hashtag #womeninagile to help spread the word and continue to elevate Women in Agile. About our Host Renae Craven has been coaching individuals, teams and organizations for over 13 years and has spent a lot of time investing in and formalizing her professional coaching skills in recent years. Renae's passion is leading and coaching organizations and as a Certified Team Coach with Scrum Alliance, she helps teams to find their rhythm and pace that balances learning with delivery. Renae established her own company NaeCrave Pty Ltd (www.naecrave.com.au) in 2020 and keeps herself busy with coaching and training delivery. Renae is also a certified BASI Pilates instructor and runs her own pilates studio in Brisbane, Australia. She has a YouTube channel called ‘Pilates for the Office Worker' which features short 5 minute guided sessions that anyone can incorporate into their day, especially those of us who have been sitting down for extended periods. Subscribe to her channel Crave Pilates. Renae has been organizing the Women in Agile group in Brisbane since 2018. You can follow Renae on LinkedIn (https://www.linkedin.com/in/renaecraven/).