Scrum Master Toolbox Podcast: Agile storytelling from the trenches

Episodios

• Why Solo Scrum Masters Get Fired — The Coalition Of The Willing | Aimé Flemm 15.06.2026 13m

  Aimé Flemm: Why Solo Scrum Masters Get Fired — The Coalition Of The Willing 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 doesn't make sense to try and change a system of 2,000 people on your own." - Aimé Flemm   Three months into his first gig out of consultancy, Aimé got the call: you're fired. He was at a Dutch pension fund — 2,000 people, deeply ingrained legacy structure — serving as Scrum Master to three component teams, including a UX-only team that couldn't ship anything end-to-end. Full of ambition and fresh ideas from a meetup, he pushed to restructure the teams to be cross-functional. His manager said "yeah, go for it." But Aimé was the only one pushing. He was, in his words, "poking and fighting the system way too much that they had built." So they didn't extend the contract. The lesson he carries from that firing reshaped how he approaches every change initiative since: do not try to do it alone. Find the coalition of the willing first — other Scrum Masters, other change agents, the volunteers — and build a network before you start pushing structural change. Use Scrum Master Syncs, communities of practice, even pizza budgets. Let the change spread like an oil spill. It takes time. It doesn't happen overnight. But you'll still have a job at the end of it.   In this episode, we refer to the coalition of the willing and change management tactics for Scrum Masters working in resistant systems.   Self-reflection Question: Where in your current organization are you trying to change the system alone — and who could become your first ally if you stopped pushing and started recruiting?   [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Aimé Flemm   Aimé Flemm joins us from the Netherlands. Our guest is an organizational design coach who starts where most agile transformations stop. He works at the structural level: redesigning the incentives, reporting lines, and systems that either enable or quietly kill agility. His belief: you can't coach your way out of a broken org design.   You can link with Aimé Flemm on LinkedIn.  
• BONUS Why Your Organization Is Still a Factory — And What an Octopus Can Teach You About Transformation With Phil Le-Brun and Dr. Jana Werner 12.06.2026 30m

  BONUS: Why Your Organization Is Still a Factory — And What an Octopus Can Teach You About Transformation Phil Le-Brun and Dr. Jana Werner both work inside Amazon, advising Fortune 500 leaders on transformation. But before Amazon, they spent decades in the trenches — Phil as International CIO of McDonald's, Jana leading change in banking and logistics. Together they wrote The Octopus Organization (HBR Press) to explain why most companies are still running on a hundred-year-old factory model, and what the alternative looks like. "We Want to Help You Make Your Own New Interesting Mistakes" "We keep saying, as Phil likes to say, can we help you make your own new interesting mistakes and avoid the mistakes that we see again and again."   Jana and Phil are both practitioners who have led large-scale changes — and made mistakes they're now happy to share. Jana describes working with incredible, smart, thoughtful people inside large organizations who weren't trusted, weren't allowed to do the work they could do, and couldn't be their best selves. She managed to turn teams considered underperforming into rock stars simply by listening and giving them space. Phil saw the same pattern at McDonald's — incredible people who knew the answers but weren't allowed to act on them. A disastrous standardization push from 2002 to 2004 taught him that top-down efficiency mandates don't work. The CEO left, and Phil got the opportunity to tap into people lower in the organization, define a common mission, and start building from there. The Factory Model Nobody Questions "There was no upside for her people taking ownership because you could have career-limiting effects if you made a mistake, if you were seen to be making a mistake or overstepping."   Jana shared two sides of the same problem. A CEO of a large investment company told her he has to sign off on every small decision — and his people assume he wants to. Neither side wants this, but nobody questions the processes in place. On the other side, a COO told Jana "my people don't want ownership." After half an hour of coaching, the COO realized there was no upside for her people to take ownership — mistakes meant career-limiting consequences. Jana is honest about her own experience too: a team member told her she was micromanaging, and she denied it. They created a secret signal — scratching an ear in meetings whenever she micromanaged. He was scratching a lot. Phil adds that what he calls "yoga babble" — abstractions like "we're going to become an agile platform-based culture" — lets leaders avoid saying what they actually mean. Nobody challenges it because the boss said it, and it sounds sort of right. The result: completely meaningless direction. The Octopus — Distributed Intelligence in Practice "It has two thirds of its intelligence, its neurons, in its arms. The arms connect independently — they don't always need a central brain, but they also have one, so they can stay aligned but also work independently."   The octopus has distributed neural clusters in each arm. It can adapt, shape-shift, change the texture of its skin, and even alter its RNA to switch between cold and hot water within hours. For Jana and Phil, this is the organizational metaphor: teams that can think locally and act without waiting for permission from the center, while staying aligned on mission. Phil translates this for team leaders of 8-10 people inside traditional enterprises:   Put together teams with cognitive diversity and encourage constructive conflict — what Linda Hill at Harvard Business School calls "creative abrasion" Invest in the storming, norming, performing cycle instead of cutting through it Leave the "how" to the team — the leader's job is the "why" and the "what" Don't jump to the answer — Einstein said if you have an hour to solve a problem, spend 55 minutes understanding the problem Start executing quickly through rapid experimentation; you can't plan your way to success in novel situations Don't Build the Pedestal — The Monkey Comes First "Get to the most tricky problems first, and try and solve them. If you can't, figure out fast — and if you can't, just stop, because your whole project is useless."   Astro Teller, CEO of Alphabet X's Moonshot Labs, says: "If you want to teach a monkey on a pedestal to recite Shakespeare, don't start by building the pedestal." Jana explains that organizations, once they get a project through the gauntlet of approvals and business cases, start working on the easy, visible things to show progress — the pedestal. But if you can't get the monkey to speak, the pedestal is useless. The counterintuitive move: when passionate people dispassionately tell you the hard problem isn't solvable, give them hugs, put them on a pedestal themselves, give them bonuses — because they just freed up resources for something better. Phil reinforces that this isn't a money problem. At McDonald's, before building a handheld order-taking device, they built a block of wood to test how comfortable it was to hold. Organizations waste far more money trying to plan for things they can't possibly plan for than they would by running quick experiments. Single-Threaded Leaders — The Pig at Breakfast "Who's that person waking up every morning saying, are we actually putting the focus on the things that are going to get us to the finish line of delivering value — not within my function, but across the organization?"   Phil tells the classic joke: a pig and chicken are walking down the road. The chicken says "let's open a restaurant." The pig asks what they'll sell. "Ham and eggs, of course," says the chicken. The pig stops: "I need to be far more committed than you." Organizations are full of chickens — people who lay their half-baked decisions, want to sign off, want to say no. What's needed are pigs. Amazon calls them single-threaded leaders. Apple calls them directly responsible individuals. The key: one person owns an initiative end to end, waking up every morning focused on delivering value across the organization, not just within their function. Mow the Lawn — Bureaucracy Grows While You Sleep "Your bureaucracy grows while you sleep. Think about your bureaucracy like mowing a lawn. You can't mow a lawn once."   Jana references Parkinson's Law — a senior Royal Navy leader found that even as the fleet shrank, the number of administrators grew by 5-10% annually. This applies to every organization. Middle managers fill their time by adding processes. One person's mistake becomes a process that penalizes 10,000 people. The solution is continuous gardening. At Google, a senior leader added positive friction: if you want more than 5 interviews in the hiring process, you need my approval. At Amazon, the principle "invent and simplify" asks everyone every year: what are we simplifying? The simplification work has to come from those closest to the problems — most leaders don't know half of what people are actually doing. Innovation Belongs to Everyone — Not a Lab "Psychological safety — it's not even a prefrontal cortex thing, it's not a conscious thought, it's that fight-or-flight reaction you have in the moment."   Phil makes the case that innovation starts with psychological safety at the team level, not an organization-wide mandate. It's the team leader asking questions, being humble, responding to disagreement with "tell me more" instead of "I don't agree." It means celebrating intelligent failures — someone who tested a hypothesis, found it didn't work, and stopped. At Amazon town halls, executives open by making fun of Amazon's failures, like the Fire Phone. The message: if you're thinking big, you'll also fail. The Fire Phone didn't work, but it informed future hardware investments. The only true failure is not learning from experimentation. Phil and Jana both emphasize that once leaders experience what happens when people are truly freed to do their best work, they get addicted to it. About Phil Le-Brun and Dr. Jana Werner Phil Le-Brun is the former International CIO of McDonald's and now leads the AWS Executives in Residence team, advising Fortune 500 leaders on transformation. Dr. Jana Werner is an Executive in Residence at AWS who built their EMEA transformation practice after leading digital change in financial services. Together they wrote The Octopus Organization: A Guide to Thriving in a World of Continuous Transformation (HBR Press).   You can link with Phil Le-Brun on LinkedIn and Jana Werner on LinkedIn.   Book site: theoctopusorganization.com Book on Amazon: The Octopus Organization
• BONUS Why More Code Doesn't Mean Better Software — And Where AI Actually Helps Your SDLC With Mooly Beeri 10.06.2026 40m

  BONUS: Why More Code Doesn't Mean Better Software — And Where AI Actually Helps Your SDLC Most teams are adopting AI to write code faster. But what if code generation isn't your bottleneck? Mooly Beeri has spent 25 years diagnosing where software organizations actually underperform — from Microsoft to Philips to automotive — and his message is clear: measure before you automate, and tie every AI investment to a business KPI. The Pattern Debugger's Origin Story "I've been identifying patterns way before AI was doing that. One of my first jobs was Microsoft, and I got the opportunity to work in engineering excellence. Every single simple improvement would make the lives of so many people better and the code better and the products better."   Mooly's career started at Microsoft in engineering excellence, where he discovered his passion for finding process areas that need improvement. From there he built the first software centre of excellence for Philips, spawned it into a separate business, and has been doing the same process excellence work across healthcare, telecom, and automotive ever since. His framework: understand where you're bleeding quality, revenue, or budget — then intervene there, not everywhere. Improvement Doesn't Mean Progress "There are too many efforts to improve too many things that don't really matter. The ability to tie a specific improvement to what actually means progress for a business — that, for me, is one critical component that's missing in many transformations."   Mooly's core insight applies directly to AI adoption: everyone has an improvement plan, but few can answer "how does this improvement improve business performance?" If you ask that one additional question, you can probably cancel half your improvement projects — the ones that make people feel good but don't move the needle on time to market, quality, or cost. The Code Generation Trap "It's like saying a book author is more productive because they write more words. The unit of work is not the number of lines of code they produce. The unit of work is a piece of code that works, that is tested, that is fully reliable, that meets a customer expectation, and eventually generates revenue."   Data from Faros AI shows individual developer PRs went up 98% with AI tools — but organizational delivery actually dropped 1.5%. More code, same or worse outcomes. Mooly explains why: most organizations invest in code generation not because it's the most effective thing to improve, but because it's the easiest step to automate. There are 35 steps in the SDLC. Picking code generation gives you a 1-in-35 chance of striking gold. As the saying goes: hope is not a strategy. Where AI Actually Works in the SDLC "The best usages would be in areas of the SDLC where there is a lot of data that needs processing and needs some detection of patterns — where AI is really, really good."   The most successful AI applications Mooly has seen with clients:   Defect root cause analysis — training AI agents on thousands of Jira bugs to find patterns humans can't see. In one healthcare client, AI analysis revealed that "false positive" bugs were actually compromised requirements — the dev team was closing real deviations as unimportant because they didn't have time to fix them Code review enhancement — AI scans incoming defects and generates a live, evolving checklist so reviewers spend their limited time checking for the most probable problems Test generation — unit, component, and functional test creation where AI can leverage existing test patterns and requirement data Requirements review — correlating requirements against strategic objectives, OKRs, and historical defect patterns to find contradictions before coding begins The Thinking Process You Can't Automate "The developers going through the process of converting requirements into code — it's actually a thinking process. It creates a lot of discussions with the product managers, a lot of back and forth, which help refine the requirement. This entire exchange is gone out the window when you have AI generate the code in 5 minutes."   When AI generates code instantly from requirements, it eliminates the human feedback loop that catches contradictions and incomplete specifications. The FDA has recognized this: every AI-assisted step in medical device software must be guardrailed by human activity. If you generate code quickly but still need a human review, the speed gain disappears. The value of coding was never just the code — it was the thinking. Map Every Investment to a Business KPI "If your uncle ran a bicycle repair shop and you said, let's advertise in the local newspaper, the first question he'd ask is: how many new customers will we get? The business logic hasn't evolved so much. If you want to do something — how will this impact your revenue, your customer retention, or your cost of producing goods? If you can't answer these things, don't invest."   Mooly's advice is deceptively simple: before adopting any AI tool in your SDLC, ask yourself which of three business outcomes it will improve — faster time to market, higher quality (fewer customer issues), or better margins (lower execution cost). If you can't draw a direct line from the AI investment to one of those outcomes, you're doing improvement theatre. About Mooly Beeri Mooly Beeri is CEO and co-founder of BetterSoftware, a consulting firm with over 25 years helping companies across healthcare, telecom, and automotive transform how they build software. His work focuses on diagnosing where software organizations underperform and designing targeted interventions — not blanket transformations.   You can link with Mooly Beeri on LinkedIn.
• BONUS Why a Former Chess Champion Thinks Your Leadership Is Stuck in the Opening Game With John Whitt 09.06.2026 31m

  BONUS: Why a Former Chess Champion Thinks Your Leadership Is Stuck in the Opening Game John Whitt spent 30 years managing billion-dollar construction portfolios in corporate America — sleeping five or six nights a week in hotel beds, traveling the country, winning at someone else's game. Then he walked away. In this episode, he breaks down what chess taught him about business phases, why generosity outperforms hustle in the long run, and how the "pause factor" keeps leaders from burning out while scaling their impact. From Corporate Construction to Coaching — The Move That Changed Everything "I spent 5, sometimes 6 nights a week, sleeping in a hotel bed, traveling around the country, and it really wasn't good for my sanity, it wasn't good for my family. And then the company decided to move from Southern California to Dallas, and so that was like the — I'm not going to Dallas move, and it's time to start something else."   John's corporate career was successful by every external measure — managing $500 million construction portfolios at companies like CB Richard Ellis. But the lifestyle was hollowing him out. He'd been thinking about leaving for a while when the relocation to Dallas forced his hand. Through behavioral assessment work, he discovered coaching was where his strengths naturally pointed — it had been his primary leadership style all along. In 2010, he invested in a Focal Point coaching franchise, which gave him the tools and training without having to reinvent the wheel. Combined with 30 years of corporate relationships, it was enough to launch. His reflection on the transition is simple: "The cool thing about coaching is that we're just helping people." The Chess Game of Business — Opening, Middle, and End "The way the chess game is played at the higher levels has influenced my way of thinking essentially for the rest of my life. The opening is where you're getting started — startup business, takes a lot of hustle, a lot of energy. But then the transition happens to the middle game, where you have to think a lot more strategically, and tactically with the right move in the right order, because the wrong order will not get you the results you're looking for."   John played in the United States Chess Championships in 1976, and the framework stuck. He maps business growth to three chess phases: the opening (startup hustle, high energy, you do everything), the middle game (strategic delegation, building systems, hiring people with an ownership mindset), and the end game (transitioning assets and resources to serve the life you actually want). The danger zone is the opening-to-middle transition. Founders and leaders get trapped being the go-to person for everything — solving everyone else's problems during business hours and doing their own work after hours and on weekends. The middle game demands a different skill: learning to operate on the business instead of always in it. And it can't happen overnight — you have to prioritize what to change, in what order, or it gets jumbled up. Accomplishing Goals Through Others — The Magic of Discretionary Effort "The magic is accomplishing goals through other people, because when you do that, you're going to do big things. As an individual, you can only do so much. There's only so many hours in a day."   John keeps coming back to one idea: if you're doing it all yourself, your impact is capped at 24 hours. The real unlock is getting other people to give their discretionary effort — that extra gear where someone stays 20 minutes longer because they care, or thinks about the project at home because they're genuinely excited. Discretionary effort isn't something you can demand. It comes from inspiration. John frames it through WIIFM — "What's In It For Me?" — everybody's favorite radio station. Leaders who skip that question get compliance. Leaders who answer it get mountains moved.   The flip side is equally important: many leaders have never been on a high-performing team, so they don't know what they're missing. They accept compliance as normal. Others are smart and capable but lack the relationship skills to inspire. John's point is clear: leadership through inspiration is a learnable skill, not an innate trait. Generosity as Strategy — Time, Talent, and Treasure "Generosity always — I mean, this is unequivocal — always gives you better long-term results. If you plan to be generous, if you say this is who I am and I will do the work that's necessary to be generous, then you will always get better long-term results."   John's 4-Facet LifeShine Generosity Process puts generosity at the center of leadership — an unusual move in a world that defaults to performance metrics and execution frameworks. His argument is that generosity isn't soft. It's strategic. The framework starts with unique identity (who are you?), then moves through three dimensions: time, talent, and treasure. Most people think generosity means writing a check. John says time and talent are far more powerful. A leader who invests the time to communicate vision and inspire the team is being generous — and that generosity compounds into better team performance, stronger relationships, and less burnout over time.   The risk, though, is over-giving. Agile coaches and scrum masters who tie their identity to the work are especially vulnerable — they give so generously at work that they burn out when results don't match expectations. That's where the plan matters: define the life you want, build the business or career to serve that life, and stay disciplined about boundaries. The Pause Factor — How Leaders Protect Their Thinking "You gotta learn to say pause. That's a great idea, I understand what you're saying, we need to spend a little more time on that — so let me schedule some time later. Because right now, if I spend all that time, it's not going to get my best thinking, it's not going to get my best response."   People bring problems to leaders constantly — personal problems, business problems, urgent and not-urgent mixed together. The instinct is to solve immediately. John teaches leaders the "pause factor": acknowledge the importance of what someone brings you, then schedule dedicated time to address it properly. This isn't avoidance — it's quality control for your own thinking. When you're distracted and rushed, you give worse answers. When you pause, you also create space to ask: is this mine to solve, or does it belong to someone on my team?   John extends this to how teams bring problems: train people to come with clarity — here's the problem, here's the challenge, here's some potential solutions. That way the leader can triage effectively in a short time instead of getting pulled into an unstructured conversation that eats an hour. About John Whitt John Whitt is a leadership strategist with 30+ years of business transformation experience, from managing $500 million construction portfolios at companies like CB Richard Ellis to coaching small business owners. He's the author of Checkmate!: Winning Tactics for Translating Ideas Into Money and creator of the Whole Life Leadership experience.   You can link with John Whitt on LinkedIn.  
• BONUS The Communication Tax — Why Your Team Collaborates Too Much and What to Cut First With Roman Nikolaev 08.06.2026 30m

  BONUS: The Communication Tax — Why Your Team Collaborates Too Much and What to Cut First In this BONUS episode, Roman Nikolaev challenges one of the most deeply held beliefs in the agile world: that more collaboration is always better. As Head of Technology at Cambri, Roman has watched teams burn their best hours in meetings and handoffs that create the feeling of productivity without the outcomes. He shares practical tools — from the vacation test to RFC processes — that help teams find the minimum viable level of collaboration. From Senior Engineer to Accidental Manager "I kind of accidentally ended up in management. I didn't want to lead anyone, I wanted to be just a senior engineer doing my stuff. But somehow, four months in the job, I was already leading a team, and then one year after, I was head of technology."   Roman's career in engineering goes back to the early 2000s. When he changed jobs during COVID, he specifically didn't want a management role — he wanted to code. But within months he was leading a team, and within a year he was running the entire technical organization at Cambri. That unexpected shift from hands-on engineering to leading teams gave him a front-row seat to how collaboration actually works — and how often it doesn't. What he noticed was that the most important differentiator for technical teams isn't technical knowledge — it's communication, and the tax you pay when communication goes wrong. The Communication Tax Is Real "The communication tax is real. The less we need to pay for communication, the more we can concentrate and own things end to end."   Roman describes a pattern most teams will recognize: stakeholders inside and outside the team — product managers, QA, scrum masters, product owners — and at some point, it becomes a game of telephone. The people doing the actual work don't have the context they need. The result? Unnecessary features, wrong implementations, suboptimal technical solutions that don't scale. His argument isn't that collaboration is bad. It's that every handoff, every meeting, every "quick sync" has a cost — and most teams aren't honest about how much they're paying. Handoffs Aren't Collaboration "If you look at a typical software development lifecycle — a ticket created by a product owner, refinement with the team, development, code review, QA, acceptance — there are quite many handoffs. If we can reduce some of this, we get a more effective workflow."   Roman walks through the standard ticket lifecycle and counts the handoffs: PO creates ticket, team refines, developer picks it up, code review with other developers, QA phase, acceptance phase. Each transition is a potential information loss. His provocation: instead of involving more people when someone struggles with a task, give the person working on it the tools and knowledge to complete it independently. The trigger for his thinking was a real team conversation where someone suggested everyone should "jump on the ticket" to help. Roman's response: wouldn't it be better to equip the individual rather than create more dependencies? Async Tools That Actually Work "Instead of gathering a meeting where people come unprepared or with some raw ideas, we have ownership for a task. Someone takes their time, writes down their thoughts, options in a document, and then we assign people to review it."   Roman shares two async practices his teams use at Cambri. First, the RFC (Request for Comments) process on Confluence — one person owns a decision, writes it up with options, and assigned reviewers sign off asynchronously. It turns out to be more effective at finding better technical solutions while spreading knowledge without requiring synchronous deep-dives. Second, his Monday written updates: every week, he spends about 90 minutes writing a detailed post covering all project statuses, what happened last week, what's coming, and business context. The team feedback in skip-level meetings is consistently positive, and he fields far fewer questions about business context and priorities than before the practice started. The Vacation Test "One heuristic would be that if one of the team members goes on vacation, the rest of the team can continue working on their task."   Roman learned this the hard way. He went on a typical Finnish one-month vacation. Before leaving, he explained the architecture and intent for a key task to his team. He came back to discover they'd built the completely wrong thing — wasting one month of a two-month project. He spent the remaining time working weekends, on planes, on trains, just to hit the deadline. The lesson wasn't that he needed more collaboration or synchronous communication before leaving. It was that he needed better communication — and a way to test whether shared context actually exists. His heuristic: if Alice goes on vacation, can Bob continue from where she stopped? If not, you don't need more meetings. You need better async context-sharing. Where to Start: Ownership First, Then Cut Meetings "I would probably first look into if a particular initiative, a feature, or some kind of process has an owner and well-defined roles. Usually, if there is no clear owner, that leads to a lot of synchronous meetings."   For Scrum Masters and team leads looking for a practical starting point, Roman offers a two-step approach. First, ensure every initiative, feature, and process has a clear owner with well-defined roles. Without clear ownership, meetings multiply because nobody is sure who's responsible, so everyone attends everything. Second, look at the team calendar starting with the biggest meetings and ask: can this be an RFC? A message? An email? Then experiment — cancel a meeting, replace it with an async channel, and see what happens. You can always bring it back. In the agile world, Roman argues, we should embrace experimentation with our own processes, not just our products. Recommended Resources Roman recommends Team Topologies by Matthew Skelton and Manuel Pais. The book gave him a clear mental model for independent teams that own their area end to end — teams aligned to value streams that own the customer problem completely. For more of Roman's thinking on collaboration, check out his Substack newsletter: Is Your Collaboration Good or Evil? on High Impact Engineering. About Roman Nikolaev Roman Nikolaev is Head of Technology at Cambri. He's spent his career thinking about how teams actually get work done — and his contrarian view that most teams collaborate too much has sparked real debate in the agile community.   You can link with Roman Nikolaev on LinkedIn.
• The Yes-Man Product Owner and the Scrum Master Who Became a Proxy for the Proxy | Maria Skvortsova 05.06.2026 15m

  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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Maria Skvortsova   Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra.   You can link with Maria Skvortsova on LinkedIn.
• If Your People Feel Safe, You Succeed — Measuring What Matters as a Scrum Master | Maria Skvortsova 04.06.2026 16m

  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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Maria Skvortsova   Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra.   You can link with Maria Skvortsova on LinkedIn.
• Breaking the Factory Mindset — When a 17-Person Scrum Team Treats Development Like an Assembly Line | Maria Skvortsova 03.06.2026 18m

  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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Maria Skvortsova   Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra.   You can link with Maria Skvortsova on LinkedIn.
• The Team That Gave Up — When Green Reports Mask a Sinking Ship | Maria Skvortsova 02.06.2026 15m

  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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Maria Skvortsova   Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra.   You can link with Maria Skvortsova on LinkedIn.
• When Agile Labels Hide Waterfall Reality — A Scrum Master's Wake-Up Call in SAP Migration | Maria Skvortsova 01.06.2026 14m

  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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Maria Skvortsova   Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra.   You can link with Maria Skvortsova on LinkedIn.  
• BONUS How AI Is Reshaping Software Teams From the Inside With Dwarak Rajagopal 30.05.2026 36m

  BONUS: How AI Is Reshaping Software Teams From the Inside — Lessons From Google, Meta, and Snowflake In this episode, Dwarak Rajagopal — VP of AI Engineering and Research at Snowflake — shares what he's seeing firsthand as AI agents become part of the software development process. From compressed sprint cycles to automated standups across time zones, Dwarak draws on two decades of building AI infrastructure at Google, Meta, Uber, and Apple to show what's actually changing inside engineering organizations today. From Compiler Engineer to AI Leader — The Thread That Connects Two Decades "In AI, the hardest part isn't just the models itself, it's making them work in real environments where data is messy, fragmented, and governed."   Dwarak started his career as an open-source GCC compiler engineer over two decades ago, optimizing hardware performance. He moved into graphics at Apple, then pivoted to AI when AlexNet started running on GPUs around 2011-2012. From there, he built autonomous driving software at Uber, led Meta's PyTorch core framework team bridging research and production, and at Google led AI Frameworks including getting Gemini training on TPUs. The common thread: always working at the intersection of research and production, making powerful technology work in the real world. That focus on real-world application is what drew him to Snowflake — where enterprise data meets AI at scale. AI Is Changing What Engineers Actually Do All Day "Engineers are spending more time on system design, validation, production reliability — and less time doing the implementation itself, because AI is helping that."   The shift Dwarak sees is concrete: AI is accelerating development, but the real value comes when it's grounded in enterprise data and context. At Snowflake, teams use tools like Cortex Code, Snowflake Intelligence, and other LLMs to generate code and tests faster — because the friction cost of development has dropped dramatically. Customer example: Whoop, the fitness band company, used Cortex Code with conversational data assistance and agents to reduce development cycles from weeks to hours, freeing teams to focus on high-value work. The End of "This or That" — Try Both, Kill Fast "There's a lot more choices now. You don't have to think about this versus that. Do both and then figure out what is the best."   One of the most practical shifts Dwarak describes: teams no longer need to commit to one architectural approach upfront. Because AI reduces the cost of building, teams can pursue two designs in parallel and evaluate both. A concrete example: instead of choosing a cross-platform framework like Flutter or React Native for a mobile app, Snowflake's teams now build native iOS and Android apps simultaneously — one human-led, the other agent-built — at roughly the same speed. But this creates a new challenge: teams have to learn to kill projects faster. When you can build more, you also discard more — and engineers need to detach from "their baby." Smaller Teams, Bigger Output — The Cross-Functional Shift "You could build multiple products now faster with different smaller teams. One back-end person, one front-end person — build vertically end-to-end."   Dwarak's teams moved from functional structures (separate backend, frontend, and feature teams) to project-based teams that own the full vertical stack. This isn't theoretical — Snowflake Intelligence was built this way. The result: fewer dependencies, faster delivery, more products in parallel. The tradeoff is coordination cost — more things running in parallel means more decisions to synchronize. Recruiting Has Fundamentally Changed — Systems Thinking Over Syntax "We used to ask an engineer to code a specific search algorithm. Now we ask them to build a whole search system within an hour."   Dwarak is clear: fundamentals matter more than ever. Systems thinking, judgment, the ability to work with complex data and production systems — these are what hiring evaluates now. AI handles execution; humans need to define problems clearly and ensure systems behave at scale. For junior engineers, the news is encouraging: onboarding is faster because team-specific skills are codified and shared, and the barrier to building end-to-end systems has dropped. "Learning by building is more true than ever now." Monday Planning, Friday Demos — The Compressed Sprint "You basically decide what to do on Monday, and you're testing together as a team on Friday and getting the feedback for the next week."   Daily work has transformed at Snowflake. The traditional multi-week sprint has compressed to a single week: Monday planning, Friday team demos and testing. Standups still happen — but faster, sometimes multiple times per day. For distributed teams across Bay Area, Seattle, and Poland, an automated skill scans each day's code changes and posts a summary in a shared Slack channel — so the next timezone knows exactly what happened without waiting for a meeting. This solves one of the oldest problems in distributed development. The Road to Lights-Out Codebases — Governance, Observability, Reversibility "Can agents take actions? Which of these actions cannot be taken back? You need the concept of committing actions or rolling back."   Building on the "lights-out codebases" concept from Philip Su's episode, Dwarak agrees the direction is clear — agents are already writing more code than humans in some contexts. But enterprise adoption requires governance, observability, traceability, and reversibility of agent actions. The shift from "AI as a tool" to "AI as part of the system" is happening now, with the focus moving from getting answers to enabling actions at scale. What Most People Get Wrong About AI in Software "It's very easy to build prototypes, even end-to-end systems. But it's very hard to get it working in enterprises where the data is so messy."   The gap between demo and production is where most organizations hit the wall. Enterprise data is scattered across invoices, factory outputs, and dozens of systems — combining it meaningfully for AI to generate insights and actions is the real challenge. This is different from the "AI will replace developers" narrative. The bottleneck isn't code generation; it's data integration, governance, and controlled execution at scale. About Dwarak Rajagopal Dwarak Rajagopal is VP of AI Engineering at Snowflake, where he leads the Cortex AI and AI Research teams. Before Snowflake, he led Google's AI Frameworks and On-Device ML teams (including Gemini), ran Meta's PyTorch Core Frameworks team, and built autonomous driving software at Uber. Two decades of shipping AI at the companies that define the field.   You can link with Dwarak Rajagopal on LinkedIn.  
• The "Painting by Numbers" Scrum Master vs. The Quiet Leader Who Made the Team Self-Sufficient | Njegos Ilic 29.05.2026 13m

  Njegos Ilic: The "Painting by Numbers" Scrum Master vs. The Quiet Leader Who Made the Team Self-Sufficient In this episode, we refer to the concepts of Scrum Master as facilitator and team empowerment. The Bad Scrum Master: The "Painting by Numbers" Approach That Leaves Product Owners Working Alone 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 basically feel totally alone because you are trying to deliver value as a team, but if nobody asks anything and nobody challenges anything, you end up defining everything yourself." - Njegos Ilic   Njegos describes the worst Scrum Master anti-pattern he's witnessed: the "painting by numbers" Scrum Master who runs every ceremony by the book — dailies, refinements, plannings, retros, reviews — but without understanding the purpose behind any of them. The meetings become a reporting cycle: "What did you do yesterday?" with no interaction, no challenging, no real engagement. From the product owner's perspective, this is devastating. Njegos describes feeling completely alone — trying to deliver value as a team while nobody engages, nobody asks questions, nobody pushes back on assumptions. The downstream effect is predictable: gaps that could have been caught early with a single conversation only surface during development or after deployment. Worse, the lack of engagement creates doubt and overthinking — the product owner starts over-defining requirements because there's no feedback loop, which reinforces the very passivity that caused the problem.   Self-reflection Question: Are the ceremonies on your team creating genuine engagement and learning — or have they become a reporting cycle that nobody actually needs? The Great Scrum Master: The Quiet, Impactful Leader Who Made the Team Self-Sufficient Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The best Scrum Masters I worked with were invisible — they knew always when to speak, they sensed the pulse of the team, and they weren't afraid to jump in when needed." - Njegos Ilic   The best Scrum Masters Njegos has worked with share a common trait: they were almost invisible. They didn't dominate meetings or insert themselves where they weren't needed. But they were always present — sensing the team's pulse, knowing when to step in, unafraid to say "we're out of time, let's take this offline." They were knowledgeable about the product, which earned them genuine respect from developers. And perhaps most powerfully, they delegated facilitation itself. Njegos shares an example where a Scrum Master introduced a round-robin system: when new developers joined the team, everyone took turns facilitating meetings — planning, retros, dailies. This wasn't just delegation for efficiency; it was empowerment by design. Team members who facilitated a retrospective suddenly understood how hard it is to lead one. That empathy changed how they participated when someone else was facilitating. The Scrum Master remained the guide, but the team grew its own capacity to self-organize.   Self-reflection Question: If your Scrum Master disappeared tomorrow, would your team know how to facilitate its own ceremonies — and if not, what does that say about how the role is being used?   [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Njegos Ilic   Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output.   You can link with Njegos Ilic on LinkedIn.  
• Why Measuring Your Product Bets Is the Key to Product Owner Success | Njegos Ilic 28.05.2026 14m

  Njegos Ilic: Why Measuring Your Product Bets Is the Key to Product Owner Success 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 cannot measure what you build, you will just be depending on who is screaming the loudest and using your gut feeling — which is not a good thing long term." - Njegos Ilic   Njegos defines product owner success through three pillars: the ability to measure product bets, deep knowledge of the industry and product, and the humility to admit mistakes and be challenged. The measurement piece is central — without it, he argues, you're flying blind, making decisions based on opinions rather than evidence, reacting to whoever screams loudest rather than what the data shows. But Njegos is honest that not every environment makes measurement easy. Some companies lack the tooling, the culture, or the historical infrastructure to set up proper analytics. In those situations, he turns to user interviews as the next best thing — getting direct feedback from users, even though he acknowledges that opinions are still limited without data to fact-check them against. His most powerful suggestion: invite the whole team to user interviews, not just the product trio. When developers hear directly from users, they connect to real-world problems, and conversations during refinements become richer and more grounded.   In this episode, we refer to The Mom Test by Rob Fitzpatrick and Shift: From Product to People by Michael Dougherty and Pete Oliver-Kruger.   Self-reflection Question: How do you currently measure whether the features you shipped actually delivered the value you expected — and if you can't measure it, what's your fallback? Featured Retrospective Format for the Week: Start With a Relaxing Exercise Njegos doesn't advocate for a specific retrospective template — and that's the point. From his product owner perspective, he values retrospectives that begin with a relaxing, informal exercise to set the tone. Not everything needs to feel like business as usual. This casual opening allows people to connect as humans first, which opens them up to think differently about what they learned during the sprint. Njegos is candid about the reality: some teams love icebreakers, while others find them childish and just want to get to the point. His advice is to sense the pulse of the team and adapt. The format matters less than whether it creates an environment where people can be honest about what went well, what didn't, and what to improve. A Scrum Master who reads the team's vibe and adjusts accordingly — that's what makes the difference.   [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Njegos Ilic   Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output.   You can link with Njegos Ilic on LinkedIn.  
• How a Miro Board Experiment Changed the Way His Team Understood the Big Picture | Njegos Ilic 27.05.2026 11m

  Njegos Ilic: How a Miro Board Experiment Changed the Way His Team Understood the Big Picture Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Every feature is a product bet. I would call this a process bet — just try to see what works best for you." - Njegos Ilic   Njegos shares a change story from his time working with a tech lead who had previously been a Scrum Master — a partnership that made all the difference. Together, they introduced a simple but powerful change: visualizing the team's work on a Miro board instead of relying on a standard ticket board with cards and status columns. They mapped out concepts, connected ticket numbers to a visual representation of how different pieces of work fit together, and used this board during dailies and refinements to track progress in context. The change wasn't imposed top-down — Njegos and his tech lead simply said, "Give us one sprint to try this. If it doesn't work, we drop it." The result was immediate: dailies became more engaging, the team could see how their individual work connected to the bigger picture, and Njegos found it much easier to track progress as a visual thinker. His advice for Scrum Masters and product owners who want to introduce something similar is refreshingly simple — frame it as a "process bet," just like you'd frame a product bet. Try it, measure what happens, and if it doesn't work, drop it and try something else. The willingness to experiment with your own process is a prerequisite for experimenting with the product itself.   Self-reflection Question: What "process bet" has your team been avoiding — and what would it take to just try it for one sprint?   [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Njegos Ilic   Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output.   You can link with Njegos Ilic on LinkedIn.  
• Why the Product Trio Breaks the Hand-Off Mentality That Kills Team Engagement | Njegos Ilic 26.05.2026 15m

  Njegos Ilic: Why the Product Trio Breaks the Hand-Off Mentality That Kills Team Engagement 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 can't change people, but I can definitely involve them." - Njegos Ilic   Njegos describes a pattern he's encountered multiple times as a product owner: teams where engagement is almost nonexistent. He walks into a refinement session, presents ideas, asks for feedback — and gets crickets. Nobody pushes back, nobody asks questions, nobody challenges the assumptions. The result is a product owner working in isolation, defining everything alone, only to discover gaps during development that could have been caught early with a single conversation. Njegos is honest about the limits of what any one person can do — you can't change people's personalities, and expecting a Scrum Master to do so is unrealistic. But what you can do is involve people. His approach when joining a new team: don't come in announcing how things will work. Instead, learn how the team already works, meet them where they are, and then find ways to fit new concepts into their existing rhythm. For the non-negotiable things — the red lines — he's precise, open, and always provides an alternative rather than just pushing his way.   In this segment, we talk about Discovery and Delivery and the Product Trio concept.   Self-reflection Question: When you join a team meeting and get silence instead of feedback, do you assume agreement — or do you treat it as a signal that something deeper needs to change? Featured Book of the Week: Inspired by Marty Cagan Njegos recommends Inspired by Marty Cagan as the book that most shaped his approach to product ownership. He highlights the entire SVPG series — including Empowered and Transformed (available as the Product is Hard SVPG Box Set) — but points to the Product Trio concept as especially powerful. As Njegos puts it, the Product Trio — bringing together a product manager, a tech lead, and a designer — removes the hand-off mentality where each discipline works in isolation. Instead of the product owner defining everything alone and handing it to the team, the trio shapes problems together during discovery, so that by the time work reaches the team, there's shared understanding of why they're building something, not just what to build.   [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Njegos Ilic   Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output.   You can link with Njegos Ilic on LinkedIn.
• Why Saying Yes to Every Stakeholder Request Is the Fastest Way to Fail as a Product Owner | Njegos Ilic 25.05.2026 14m

  Njegos Ilic: Why Saying Yes to Every Stakeholder Request Is the Fastest Way to Fail as a Product Owner 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 game is rigged because they are strong personalities, they want to get things done, but you don't have a magic stick — it's really hard to deliver results if you cannot say no." - Njegos Ilic   Njegos shares a failure from early in his career as a product owner in startup environments, where he found himself saying yes to every stakeholder request. Working with strong-willed founders who expected things done their way, Njegos fell into the trap of trying to please everyone — building everything that was asked without pushing back. The result was predictable: scattered priorities, no room to pivot, and a product backlog driven by the loudest voice in the room rather than real user needs. But Njegos frames this failure with a perspective that product owners at any stage can learn from. He compares the learning process to watching children learn to walk — stumbling and falling is not a sign of weakness, it's a necessary step in the process of growing. His advice to product owners currently stuck in this pattern: don't try to avoid failures too hard, because you might prevent yourself from learning the most important lessons. Instead, treat failure as a feedback loop — something happened, you can measure it, and you can change your approach. The key is doing the actual work of reflection: What did I do? What should have been different? What wasn't possible to change, and why?   Self-reflection Question: When was the last time you said yes to a stakeholder request even though your gut told you it wasn't the right call — and what would it take for you to say no next time?   [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Njegos Ilic   Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output.   You can link with Njegos Ilic on LinkedIn.  
• The Jazz Duo Effect and The Absent PO — Two Sides of Agile Product Ownership | Christian Thordal 22.05.2026 11m

  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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Christian Thordal   Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results.   You can link with Christian Thordal on LinkedIn.
• Structure Creates Freedom, How an Agile Coach Measures Success by Becoming Less Needed | Christian Thordal 21.05.2026 13m

  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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Christian Thordal   Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results.   You can link with Christian Thordal on LinkedIn.
• Managing Cross-Team Dependencies in Scaled Agile, From Planning to Real-Time Coordination | Christian Thordal 20.05.2026 16m

  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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Christian Thordal   Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results.   You can link with Christian Thordal on LinkedIn.  
• How "Fake Kanban" Fooled the Metrics, And What This Agile Coach Did to Fix It | Christian Thordal 19.05.2026 13m

  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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.   🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.   Buy Now on Amazon   [The Scrum Master Toolbox Podcast Recommends]   About Christian Thordal   Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results.   You can link with Christian Thordal on LinkedIn.