Podcasts about Scrum

Olaitan Fashanu: The PO Who Doesn't Care vs the PO Who Always Has the Answer Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   In this episode, we refer to a recurring theme in past podcast episodes—the proxy product owner who can't make decisions because they're not theirs to make. The Great Product Owner: Always Available, Always Decisive, Always Has the Context 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.   "There was nothing you tell, any questions you have about a particular feature that this guy doesn't have an answer to. And that really moved the team so fast." - Olaitan Fashanu   The best PO Olaitan ever worked with was the mirror opposite of every anti-pattern he'd seen. Deeply involved in refinement. Took backlog management seriously. Always brought the context. Always available to the team. And—maybe most importantly—always ready to make a decision when devs surfaced trade-offs. The team could ask any question about any feature, and the answer was right there. Not "let me check," not "I'll get back to you," not "what do you think?"—a decision. That single quality, Olaitan says, was what moved the team faster than anything else. As a Scrum Master, when you see a great PO at work, you also see the amplifying waves of impact: motivation rises, quality rises, ownership grows. Olaitan's takeaway is sharp: the success of our job depends on how well the product owner does theirs.   Self-reflection Question: When was the last time your PO made a real-time decision that unblocked the team in a single conversation—and what's preventing that from being the norm? The Bad Product Owner: Doesn't Care About Impact, Can't Make Decisions Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The product owner cares about delivery. We just need to release to the customer. That is something I don't like." - Olaitan Fashanu   Olaitan describes two anti-patterns wrapped into one bad-PO type. The first: the PO who doesn't care about the impact of their work on the team. Tickets dropped without context. No refinement. No problem framing. Just "ship by end of month." The data shows up in Jira if you're paying attention—patterns of churn, quality issues, customer complaints, slow market response. Beyond the numbers, the team loses motivation, frustration creeps in, and eventually you lose the team entirely. The second anti-pattern, layered on top: the PO who can't make decisions. Developers come back with two options and the trade-offs—and the PO can't pick one. Vasco connects it to the proxy PO pattern explored in past episodes—a PO whose decisions aren't actually theirs to make. The cost is the same either way: the team stalls, ownership erodes, and stakeholder conflict grows.   In this segment, we refer to the proxy PO anti-pattern explored in earlier episodes of the podcast.   Self-reflection Question: Is your PO unable to decide—or unable to be allowed to decide? The difference changes which conversation you need to have, and with whom.   [The Scrum Master Toolbox Podcast Recommends]

Most engineering teams are still optimizing for the wrong thing. They chase the speed of code when the real bottleneck is the speed of context. Matt Watson and Eban Bisong, founder and CEO of Senvi, get into what actually changes when AI moves from a coding tool to a teammate.Eban has spent his career as a founding engineer, and his approach is hands-on: don't tell skeptical engineers AI works, show them, every standup, until the pushback turns into excitement. At Park DNA he built "RTD2," an OpenClaw-powered droid wired read-only into their data sources, Slack, and Jira. It answered support questions before an engineer could, created its own bug tickets, and joined meetings through Fireflies so nothing got lost. The lesson underneath all of it: record everything, because the team that captures the most context ships the right thing fastest.Matt also shares his own three-week rabbit hole with Claude Cowork, $8K in tokens, a fully rebuilt Full Scale website, a thousand dead blog posts deleted, and 200 more rewritten. They go a few rounds on why it's a bad time to be a coder but a great time to be a builder, why "good enough" is a real standard and not a cop-out, and why ownership beats asking permission every time.If you build software or lead an engineering team, listen now. And if you want to try Eban's voice-first AI journal, visit senvi.ai.⏱️ Episode Breakdown00:42 From Founding Engineer to Solo Founder01:52 Using AI as an Engineering Leader03:24 Building RTD2: An AI Teammate for Support05:27 The Speed of Context, Not Code06:11 Why You Should Record Everything08:59 Winning Over AI-Skeptical Engineers11:50 The AI Spectrum Across 80 Clients13:35 A Bad Time to Be a Coder, a Great Time to Build14:03 Why "Good Enough" Is Good Enough14:52 Human-in-the-Loop and Reviewing AI's Work16:28 Going All-In on Senvi19:01 Validating the Product With a Beta Group21:01 Bootstrapping a Truly AI-Native CompanyLinks & ResourcesConnect with Eban Bisong on LinkedInSenvi.ai - senvi.aiWhat Smart CTOs Are Doing Differently With Offshore Teams in 2025Subscribe to the Global Talent SprintFull Scale – Build your dev team quickly and affordablyIf you're trying to get your team out of the basement and into real product ownership, this episode is your playbook. Stop being a ticket factory. Build teams that think, create, and lead.Follow the show, rate it, and send this to someone who's still trying to do “real Scrum.” They need it more than you do.

Olaitan Fashanu: I Love Data—Why Success for a Scrum Master Means Doing the Hard Measurement Work Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "You don't get better by not trying to be better." - Vasco Duarte (channeling Olaitan's own discipline)   For Olaitan, success as a Scrum Master comes down to two things—team effectiveness and team health—and he refuses to guess at either. Twice a year, in what he calls his winter and summer cycles, he runs a structured team health check survey to capture how confident people feel, whether they hold each other accountable, and whether psychological safety is real or theatrical. Between those checkpoints, he runs constant one-on-ones—and not just with developers. QAs, designers, the PO. Everyone gets the conversation. He pulls outside-in feedback from customers and partner teams too, because effectiveness measured only from the inside is fiction. "I love data. Maybe it's my background in mathematics. I love looking at patterns, comparing things." The work is real, the load is real—but for Olaitan, refusing to do it is the same as refusing to grow.   Self-reflection Question: If you had to prove to yourself today that your team is genuinely effective and healthy, what data would you actually have—and what would you only be guessing at? Featured Retrospective Format for the Week: Start / Stop / Continue (and a twist Vasco offers Olaitan) Olaitan's go-to is the simple Start / Stop / Continue format—the easiest way he's found to get even quiet developers to engage, especially at the start of a new iteration. Vasco offers him a twist mid-episode: what if you only used one of the three? When the team is overwhelmed, run a Stop-only retro. When a release just shipped and energy is high, run a Start-only retro. Breaking the format pattern creates a small spark of "wait, why is this different today?"—which is often exactly the energy a tired team needs. Olaitan also shares a second favorite: the Friction vs. Drivers (or Fuel) format—mapping what's slowing the team down on one side and what's actively energizing them on the other. The two sides of the same coin, made visible.   [The Scrum Master Toolbox Podcast Recommends]

Hour 4 -- Andrew Baggarly joins the show to break down Buster Posey's comments in yesterday's media scrum and what it might mean for the teams future.See omnystudio.com/listener for privacy information.

Olaitan Fashanu: Three Teams, Three Backlogs, One Feature—Can You Make Them See Each Other? 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.   "How do we ensure that these teams actually work together to show the same data?" - Olaitan Fashanu   Olaitan brings a problem most Scrum Masters in scaled environments will recognize. Three teams. Three separate backlogs. One product, accessed across app, web, and support channels. Leadership made a top-down team topologies decision: split the work to move faster. Predictable result—each team optimizes for their own backlog, blind to what the others are building, sometimes shipping the same feature twice with different behaviors. The product owners know there's overlap. The teams love the idea of linking tickets across backlogs. They just won't maintain the habit. Olaitan and Vasco walk through experiments together: a sync between POs, joint refinement sessions, linking tickets, putting "this is also being built by Team B" notes at the top of stories. The deeper insight: the Scrum Master's job is to keep surfacing information until a habit forms. As Vasco's old lifting coach put it—you find the imbalance, you get rid of the imbalance, one by one. That's how you get stronger.   In this episode, we refer to team topologies and the practice of surfacing information across team boundaries.   Self-reflection Question: Where in your organization are teams unknowingly building the same thing twice—and what's the smallest experiment you could run this week to make that visible?   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: When the New PO Stops Refining—and the Team Starts Self-Destructing 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 we're actually doing the job of refining this ticket properly, then we will not be creating this tension in the team." - Olaitan Fashanu   The team was working well. They had a strong PO who came to refinement with the problem clearly framed: this is what we want to solve, here's the context, here's the user story, here are the acceptance criteria. The team picked it up, refined it, ran with it. Then change came. A new PO joined—and the routine collapsed. The new PO cared about one thing: hitting the delivery date. Tickets dropped into Jira with no context, no problem statement, no acceptance criteria. Just "this needs to ship by end of month." Within weeks, Olaitan saw the symptoms cascade through the team. Developers asked designers what tickets even meant. QA struggled to maintain quality. Tension built. The diagnosis was clear: refinement had broken. His fix? Bring back the Definition of Ready as a non-negotiable shared standard, and introduce a product trio—business viability, technical feasibility, and design usability collaborating on every story before it reaches the rest of the team.   In this segment, we talk about the Definition of Ready and the product trio collaboration model.   Self-reflection Question: What's the symptom you're seeing in your team right now—and could the real source be how stories are getting refined, not how they're getting built? Featured Book of the Week: The Secrets of Facilitation by Michael Wilkinson Olaitan calls out The Secrets of Facilitation by Michael Wilkinson as the book that shaped how he handles difficult moments. The book teaches the power of asking the right question at the right time—clarifying questions, probing questions, the questions that drive a stuck group forward. "You will understand how, when to ask clarifying questions, ask really powerful questions that will help you drive or probably help you reach your goal in any session you find yourself." For Olaitan, the biggest payoff was learning to manage group dynamics in real time—what to do when something said in a meeting lands badly, when a comment threatens to derail the room. As a Scrum Master, you live in those moments. This book hands you a toolkit for them.   [The Scrum Master Toolbox Podcast Recommends]

Olaitan Fashanu: The Scrum Master Who Tried to Force His Way In—and Got Schooled 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 you want to make things work, you need to find a way to carry people along. Lead, not by forcing your way on the team, because you're working with smart people, you're working with professionals." - Olaitan Fashanu   When Olaitan transitioned from project management into the Scrum Master role, he carried his old habits with him: enforce, push, drive. Then he walked into a team of senior developers. In one retrospective, a team member casually suggested that someone could help set up Jira properly. Olaitan took it personally—wasn't that his job? The next day in the daily standup, he called it out publicly. The reaction told him everything. The team member shut down. The PO pulled him aside afterward to say, "We could have had a better discussion around this." That moment, Olaitan realized that having no formal authority isn't a weakness to compensate for with force—it's the whole point. The job is to influence, to nudge, to coach—even when the conversations are hard. Especially when they are hard.   Self-reflection Question: When was the last time you raised a difficult topic in a way that closed the conversation instead of opening it—and what would it have cost you to bring it up differently?   [The Scrum Master Toolbox Podcast Recommends]

“We have twelve scrum masters. Why is nothing working?” If you have ever asked some version of that question, this episode is for you.Kate Megaw, Anu Smalley and Ryan Smith dig into the challenge they hear in almost every class they teach, a real lack of role clarity. Companies send a strong project manager to a two day course, hand them a new title, and then wonder why nothing changes. The honest answer is that nobody ever defined what the role is actually accountable for. This episode unpacks the difference between roles and accountabilities, why a scrum master is not optional, and how to define seats around outcomes instead of titles. Along the way Kate and Anu have a friendly fight over RACI, whether it hardens into swim lanes or serves as a living guiding light, and what responsible really means at a startup versus a large enterprise.What we cover:“We have twelve scrum masters, why is nothing working?”Roles vs. accountabilities, and why the org chart liesThe RACI debate: swim lanes vs. guiding lightThe kitchen sink job description with 45 impossible dutiesStart with outcomes, not titles, and revisit at every kickoff

What happens when a team buys the board, holds the ceremonies, and completely misses the point?The team at EM Solutions Inc. officially went Agile. They have the Scrum board. They have the standups. They have the retrospectives. They even have an Elmo doll.What they don't have is the mindset.Meet Brett — the Product Owner who treats the backlog like a throne. Dina — the Scrum Master, five-foot-three and impossible to move. Henry — who eats half the croissants before anyone else arrives and grabs the cleanest stories before planning starts. Shri — who built a checklist for the checklist. Vlad — for whom everything is a fire alarm. Dominic — whose Daily Scrum updates reference events from 2019. Paula — who cannot write a single line of code without a pairing partner. Julia — who turns every sprint review into a three-course meal when everyone ordered a snack. And Barry — the VP who says he supports Agile and then tries to bribe Vlad in the parking lot.Into this beautifully broken team walks Phill — trainer, coach, and a man who has the laminated cards to prove he has seen all of this before.Agile Circus is a business fable built around twelve real dysfunctions that real teams live with every day. Every chapter delivers the chaos in full, hilarious detail — then lands the coaching lesson: Manifesto values, sprint mechanics, planning poker, velocity, user stories, retrospectives that produce real commitments, and the truth no certification exam covers: the badge is not the achievement. The behavior is.The Agile book that makes the learning stick because you will not stop laughing long enough to put it down.Perfect for: PMP® and PMI-ACP® candidates, Scrum Masters, Product Owners, Agile coaches, project managers, engineering leaders, and anyone who has ever survived a forty-seven-minute Daily Scrum.Phill Akinwale — OPM3, PMP®, PMI-ACP®, PMI-RMP®, CSM — trainer, coach, host of pmradio.org.Get your copy. Update your Elmo. Let's move on.

What happens when a team buys the board, holds the ceremonies, and completely misses the point?The team at EM Solutions Inc. officially went Agile. They have the Scrum board. They have the standups. They have the retrospectives. They even have an Elmo doll.What they don't have is the mindset.Meet Brett — the Product Owner who treats the backlog like a throne. Dina — the Scrum Master, five-foot-three and impossible to move. Henry — who eats half the croissants before anyone else arrives and grabs the cleanest stories before planning starts. Shri — who built a checklist for the checklist. Vlad — for whom everything is a fire alarm. Dominic — whose Daily Scrum updates reference events from 2019. Paula — who cannot write a single line of code without a pairing partner. Julia — who turns every sprint review into a three-course meal when everyone ordered a snack. And Barry — the VP who says he supports Agile and then tries to bribe Vlad in the parking lot.Into this beautifully broken team walks Phill — trainer, coach, and a man who has the laminated cards to prove he has seen all of this before.Agile Circus is a business fable built around twelve real dysfunctions that real teams live with every day. Every chapter delivers the chaos in full, hilarious detail — then lands the coaching lesson: Manifesto values, sprint mechanics, planning poker, velocity, user stories, retrospectives that produce real commitments, and the truth no certification exam covers: the badge is not the achievement. The behavior is.The Agile book that makes the learning stick because you will not stop laughing long enough to put it down.Perfect for: PMP® and PMI-ACP® candidates, Scrum Masters, Product Owners, Agile coaches, project managers, engineering leaders, and anyone who has ever survived a forty-seven-minute Daily Scrum.Phill Akinwale — OPM3, PMP®, PMI-ACP®, PMI-RMP®, CSM — trainer, coach, host of pmradio.org.Get your copy. Update your Elmo. Let's move on.

The Saturday Scrum crew were back where the focus was Queensland's big win over New South Wales in State of Origin Two and the guys had their say on what changes New South Wales should be making! Plus, the Knights cement their place in the four with a win over the Dragons, Queensland Assistant coach Ben Te'o joined the team and the guys delivered their mid-season report card! Plus, Believe It or Not, Tony's Quiz and much more! Check out Triple M NRL's Instagram, Facebook, TikTok and YouTube!See omnystudio.com/listener for privacy information.

The Saturday Scrum crew were back where the focus was Queensland's big win over New South Wales in State of Origin Two and the guys had their say on what changes New South Wales should be making! Plus, the Knights cement their place in the four with a win over the Dragons, Queensland Assistant coach Ben Te'o joined the team and the guys delivered their mid-season report card! Plus, Believe It or Not, Tony's Quiz and much more! Check out Triple M NRL's Instagram, Facebook, TikTok and YouTube!See omnystudio.com/listener for privacy information.

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

Aimé Flemm: When The Team Tells You You're Doing Too Much — That's The Success Signal Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "It's when you know you're on the right track — when the teams start complaining that you're doing too much." - Aimé Flemm   Aimé got the feedback nobody wants to hear: "You're being too much in the front of the group." His first reaction was to take it personally. Then he saw it for what it was — the success signal. The team was telling him: let us do it. After months of helping them build self-managing capability, they hit a tipping point. They wanted the floor. He stepped back, started "actively doing nothing," sat down and crossed his arms. When they brought a problem, he asked: "What are you going to do about this? Have you tried that already?" But Aimé pushed back on himself in this conversation, and accepted the reframe: the Scrum Master isn't less needed at the tipping point — they're needed differently. The shift is from teaching and facilitating ceremonies to nudging with questions, helping the team reach out when they're stuck, surfacing issues with the PO and outside stakeholders. The focus shifts when you reach success. Don't take "you're doing too much" as offense — take it as your cue to change levels.   Self-reflection Question: When the team last pushed back on something you were doing, did you take it as feedback to defend — or as a signal that they're ready to take more ownership? Featured Retrospective Format for the Week: Retromat + Liberating Structures Aimé's favorite retro? "If I don't have to do it myself." Once teams reach the tipping point, he uses a pull system — they run their own retros, he checks in a few days later. But when he does facilitate, he layers two tools. First, Retromat — not just for the techniques, but for the flow: check-in, gather data, generate insights, decide what to do, checkout. Second, Liberating Structures on top of that flow. His favorite is Impromptu Networking — small groups answer a question, then re-form in different groups. "It's like a beehive. There's so much energy. It's bubbling." He's used it cross-org, his team and the client team in the same room. And his strong recommendation: do retrospectives on-site whenever you can.   [The Scrum Master Toolbox Podcast Recommends]

Aimé Flemm: Renting The Change vs Owning It — Why LeSS Transformations Get Reversed 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 rented the change instead of owning it." - Aimé Flemm   A year ago Aimé helped his Dutch employer adopt LeSS. The teams are happy. They're performing well. And now, he's watching it all get pulled apart. The company was acquired by a German parent that's "actually really German" — traditional, command-and-control. The parent wants to "align" all its companies and is pushing to revert the LeSS structure back to component teams. Why? Because higher management never went to the trainings. They never went through the change themselves. They signed off on it, but they didn't internalize it. And now the loud-but-few voices of the status quo are reaching upward, and management is panicking. That's what Aimé means by "renting the change" — you got the lease, you never bought the building, and the moment pressure rises, you walk away. His experiment for the next sprint, sharpened in this conversation: stop trying to defend the structure. Start a conversation with management to co-create success metrics for the merger itself. Decouple the structure from the definition of success. As long as the merger succeeds, the structure can stay fluid. Speak their language. And remember: coaching is the cherry on top — about 5% of the real gains. The big improvements live in the structural changes.   Self-reflection Question: When you sold your last change to upper management, did they buy it — or are they renting? And what's your plan for the moment when they want to give back the keys?   [The Scrum Master Toolbox Podcast Recommends]

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

In this episode, Dave Prior chats with Alex Sloley, an agile coach and Scrum Alliance Board candidate, about the evolving landscape of Agile, Scrum, and the impact of AI on teamwork and project management. They explore how community involvement, technological innovation, and leadership can shape the future of Agile practices. Key Topics • The significance of community engagement and serving through roles like the Scrum Alliance board • The accelerating pace of iteration in Agile driven by AI and technological advancements • How AI is transforming Scrum practices, from sprint durations to team collaboration • The importance of adopting AI-guided discipline without losing human judgment • The evolving skills required for future developers and project managers • Vision for Scrum's evolution to keep pace with rapid technological change • The role of the Scrum Alliance in fostering innovation and listening to its members • Strategies for balancing Agile principles with modern remote, digital work environments • The necessity of healthy conflict within governance and leadership to drive progress • The importance of positivity and realism in navigating industry change Timestamps: 00:00 - Introduction to Alex Sloley and his background in Agile and Scrum 01:00 - The importance of community service and board participation in the Agile world 02:00 - Personal motivations for running for the Scrum Alliance Board 04:40 - Current state of the Agile community amid industry transformations 05:50 - Embracing change and the role of AI in agility and operations 09:55 - Integrating AI into Agile processes for discipline and efficiency 12:52 - AI as pair programmer and thinking partner for developers 17:40 - Rethinking Scrum practices in an AI-driven environment 20:26 - The potential for AI agents as part of Scrum teams and digital team members 24:56 - Revitalizing the Scrum Alliance: Listening to members and fostering innovation 28:08 - What members should expect from a visionary Scrum Alliance Board 32:25 - How to connect with Alex for insights into AI and Agile 33:01 - Closing remarks and encouragement to participate in the Scrum Alliance elections Contacting Alex • Web: https://alexsloley.com/ • LinkedIn : https://www.linkedin.com/in/alexsloley/ • Alex's book The Agile Community https://alexsloley.com/books Vote in the Scrum Alliance Board Election! Remember, voting ends June 24. Make your voice heard to shape the future of Agile leadership and community.

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]

Everything is a fire. Everything is priority number one.  And by tomorrow, the number one priority has changed again. Sound familiar?In this episode, Kate Megaw, Anu Smalley, and Ryan Smith dig into the challenge they hear at almost every client and leadership class: a real lack of prioritization.  Not just inside the sprint, but across the whole organization, where teams get handed a brand new top priority every single day.When everything is important, nothing is important.  Constant reprioritizing whipsaws teams, burns people out, and leaves a trail of half-finished work and rising tech debt.  Jerry Weinberg's research found you can lose 20 to 40 percent of productivity every single time you switch context, so three projects can leave you down 60 to 80 percent.In this episode, we discuss:Why a lack of prioritization is really a sign that your stakeholders are not alignedThe real cost: burnout, rework, tech debt, lost innovation, and the context-switching taxWhy this is a leadership problem, not a team problem, and why the team always gets blamedUsing the sprint to hold the line and protect work the team has committed toEmergent requests as a better signal than velocity for how often the team gets interruptedMoSCoW for sorting the must-haves from the nice-to-havesThe 20/20 approach from Innovation Games for a truly ordered backlogThe impact-effort matrix for spotting quick wins and killing low-value workBuy-a-feature with stakeholders and a limited budgetThe wins on the board debate: put easy wins up first, or dig into why the big thing is bigEvery time someone says yes, it consumes time, money, and attention.  Prioritization is the discipline of protecting all three.Referenced in this episode: Jerry Weinberg's research on the cost of context switching, the 20/20 prioritization method from Innovation Games, the MoSCoW method, and the Eisenhower impact-effort matrix.

The Saturday Scrum crew were back and started the show by talking to Frank Ponissi from the New South Wales Blues with some breaking news about a star being ruled out of the game on Wednesday night. The boys discussed the Broncos crisis as they struggle to reach the finals, but it's all good news for the Dolphins who are on the march to their first finals berth! Plus, all the latest news in the game from David Riccio, Believe It Or Not, and Tony's Quiz! Check out Triple M NRL's Instagram, Facebook, TikTok and YouTube!See omnystudio.com/listener for privacy information.

The Saturday Scrum crew were back and started the show by talking to Frank Ponissi from the New South Wales Blues with some breaking news about a star being ruled out of the game on Wednesday night. The boys discussed the Broncos crisis as they struggle to reach the finals, but it's all good news for the Dolphins who are on the march to their first finals berth! Plus, all the latest news in the game from David Riccio, Believe It Or Not, and Tony's Quiz! Check out Triple M NRL's Instagram, Facebook, TikTok and YouTube!See omnystudio.com/listener for privacy information.

Matt Watson sits down with Beth Epperson, founder and CEO of Legacy Purpose, here in the Kansas City area. Beth came up through marketing and branding, including the brand launch for Hyvee Arena, before deciding to build something of her own.Her company is built around two products. Aligned Legacy measures how people think in real time and helps teams see how aware, connected, and aligned they actually are. HICMIT, or Wisdom Illuminated, keeps a company's knowledge governed and accurate so nothing walks out the door when an employee leaves.Beth and Matt get into the messy reality of being a founder. She self-funded the whole thing, learned to code her own prototype, and pitched for over a year through a pile of rejections. She also walked away from a paid pilot because the people on the other side were not aligned on ethics and accountability.Matt shares why he thinks Beth represents a new kind of founder. Sales first, build second, now that AI can help build the thing. They also dig into validating an idea, the pull you want to feel from customers, and why getting your first case studies is the hardest part.If you have ever tried to get a product to market on your own, this one is for you.⏱️ Episode Breakdown00:38 Introduction to Legacy Purpose and Beth Epperson03:37 Beth's Entrepreneurial Journey and Corporate Experiences06:37 The Birth of Legacy Purpose and Its Mission09:52 Understanding Emotions and Accountability in the Workplace12:35 The Development of Innovative Tools for Corporate Growth15:38 Challenges in Building and Marketing the Software18:28 The Importance of Case Studies and Market Validation21:37 Future Aspirations and Closing ThoughtsLinks & ResourcesConnect with Beth Epperson on LinkedInLegacy Purpose Website - https://legacypurposed.com/Email - mailto:Beth@legacypurpose.comWhat Smart CTOs Are Doing Differently With Offshore Teams in 2025Subscribe to the Global Talent SprintFull Scale – Build your dev team quickly and affordablyIf you're trying to get your team out of the basement and into real product ownership, this episode is your playbook. Stop being a ticket factory. Build teams that think, create, and lead.Follow the show, rate it, and send this to someone who's still trying to do “real Scrum.” They need it more than you do.

In this episode, Jason explores how to apply Kanban at the crew level within construction projects. He explains how a Kanban or Scrum board can track work from backlog, to in-progress, to done, ensuring clarity and alignment across the office and field. What you'll learn in this episode: How Kanban and Scrum boards function in construction project delivery. Using boards to align project managers, engineers, and field crews. How to implement backlog, in-progress, and done columns for clarity. The benefits of crew-level Kanban for sequencing and pacing tasks. How real-time adjustments keep office and field work in sync. Are your crews seeing the work in real time and flowing efficiently or is your process creating confusion and wasted effort?   If you like the Elevate Construction podcast, please subscribe for free and you'll never miss an episode. And if you really like the Elevate Construction podcast, I'd appreciate you telling a friend (Maybe even two

Dave West sits down with Mik Kersten, author of Project to Product and the upcoming Output to Outcome, to explore why AI amplification is exposing the real bottlenecks in how organizations work. Mik shares data from over 3,600 value streams showing that development teams account for just 8% of end-to-end delivery time which means making those teams faster with AI doesn't move the needle if the constraints are upstream and downstream.The conversation digs into why most organizations are measuring the wrong things (hint: token consumption is not a productivity metric), why overlay agile structures have largely failed, and why the answer isn't fewer teams it's more empowered ones. Mik introduces the core models from his new book: the outcome loop, the outcome tree, and seven organizational shifts that together make up a new operating model designed for the age of AI.Key Takeaways:The bottleneck has moved from software delivery to planning, governance, and innovation and most organizations haven't caught upMaking development teams faster with AI delivers little value if the surrounding system isn't designed around outcomesAgile as an overlay structure doesn't work it has to become the primary operating model and the actual org chartEmpowered, autonomous teams are not optional in an AI-driven world the speed of feedback loops makes half-measures unsustainableLeadership roles need to be redefined and incentive structures realigned to match the way teams are actually workingThe theory of constraints still applies in the age of AI the constraint just keeps moving, and finding it is now the critical management skillLinkshttp://outputtooutcome.org/

Chris Lucian and Austin Chadwick discuss all things #agile and product development from a #MobProgramming perspective. What if you could decompose every agile method down to its essential building blocks and recombine them for your own specific context? In this episode, Chris and Austin are joined by Aria Omidvar to explore the HEXI method — a framework-agnostic approach to understanding and applying agile, lean, and software craftsmanship practices through physical hexagon objects and collective sense-making. Aria shares his journey from software craftsmanship and clean code, through Scrum and XP, to discovering Dave Snowden's HEXI method and building his own independent "Hexiverse" — a modular knowledge map that spans Software Teaming, Extreme Programming, Kanban, Modern Synthesis, the Agile Manifesto, and more. He unpacks how breaking methods into reusable hexagonal pieces allows teams (and individuals) to see the connections between ideas, surface what is missing, and navigate the overwhelming landscape of agile methods without falling into method wars. We dig into: What the HEXI method is and how Dave Snowden and Nigel Thurlow introduced it via Scrum.org How Aria independently adapted HEXI to create a Hexiverse for software teaming and mob programming Why decomposing methods into building blocks enables recombination for any specific context The spatial design choices behind the Hexiverse — and why dotted hexagons signal a concept shared across sets How Alistair Cockburn validated the Agile Manifesto hexiset (and why that meant the world to Aria) The learning journey metaphor of islands growing large enough to connect — and how the Hexiverse accelerates that Why "nice" doesn't cut it in high-collaboration environments — and how kindness, consideration, and respect offer a deeper model The "turn up the good" retrospective format and why it flips the traditional improvement lens How the Hexiverse serves both as a personal learning quest and a potential onboarding tool for teams new to agile methods Aria's call to action: check the original HEXI sources, play with the physical kits, and consider building your own Hexiverse Scaling Complex Systems by Building on Agile Frameworks with Dave Snowden and Nigel Thurlow: https://youtu.be/AEf1BCffimA Aria's Hexiverse on Miro: https://miro.com/app/board/uXjVKv84GGU= The Hitchhiker's Guide to Hexiverse on Medium: https://medium.com/@omidvar.aria/list/the-hitchhikers-guide-to-the-independent-hexiverse-fe509a7c46f8 The Hitchhiker's Guide to Hexiverse on LeanPub: https://leanpub.com/HG2H

En este episodio Oz conversa con Gina Paola Cárdenas (QA Manager, +12 años de experiencia) y Luis Contreras (Automation Lead en Capgemini, certificado ISTQB) sobre lo que realmente pasa cuando metes agentes de IA al proceso de testing. El 77.7% de los equipos de QA ya se movió a un enfoque AI-first y hay empresas donde el 85% del testing ya no es manual — pero sin criterio técnico, estrategia y gobierno, la IA acelera el caos en lugar de la productividad. Hablan de qué SÍ funciona (análisis de riesgos, self-healing, generación de datos), del peligro de la "pereza de pensar" y la falsa cobertura, de por qué los modelos alucinan entre 3% y 18% y suenan más seguros cuando se equivocan, y de cómo el rol del QA se vuelve más crítico que nunca.00:00 Intro: 77.7% de QA ya es AI-first02:27 ¿Qué cambió con la IA en QA?05:42 El criterio técnico como barrera06:28 El hype vs la realidad: ¿nos reemplaza?09:27 Qué SÍ funciona: análisis de riesgos con IA12:20 Self-healing: scripts que se autocorrigen16:24 Resistencia de los equipos18:18 Scrum ya murió (y los marcos que siguen)20:18 El ejemplo de las velas: evolución de roles22:37 El superpoder del economista en QA26:20 El riesgo: pereza de pensar y falsa cobertura30:56 Pruebas de integración con IA33:52 IA, usabilidad y accesibilidad36:25 Alucinaciones: 3-18% y suenan seguras40:13 "Los de QA no son ingenieros de verdad" + el mercado de $112B41:24 Backlog refinement con criterio crítico43:34 Sistemas críticos: rayos X, carros, vidas46:07 Consejos para QAs: prompt engineering e instinto probador50:01 Cierre✩ CURSOS DISPONIBLES

Welcome to Botched: A D&D Podcast! When a mysterious book appears at the front of their compound, in a langue that no one understands, Terry's Tough Guys are forced out on a quest. With their top crack Sky Yacht pilot, they head to the one place that has the wisest elders, New Monk City.With book in had, they fly north to New Monk City, hoping to get some new magical items because, oh yeah, Scrum a demon now.... Yeah so, Orlok did a deal with elder small g god, and used those powers to turn Scrum, it's a whole thing but yeah..Will the party be able to find someone who can read this old skin book? Will the shop have the magical items that Orlok thinks he deserves? Will Scrums new demon girlfriend be happy about his new look? Find out tonight, on Botched Podcast!Dennis has successfully completed a Kickstarter for his 4th graphic novel in his Lycan: Solomon's Odyssey series! Lycan is about the world's first werewolf! It's a mix of horror, mythology, adventure, and history. The 4th book in the series is all about ancient Egypt! Wanna read a story mixing a werewolf with Egyptian Gods? You can still back it on Kickstarter for the time being as we have Late Pledges enabled! ⁠Check it out on Kickstarter⁠!We now have a PO Box! Wanna send us something? PO BOX 3178 Gettysburg, PA 17325All of our previous seasons can be found on our new channel!⁠⁠⁠⁠⁠⁠⁠Botched Archives⁠⁠⁠⁠⁠⁠⁠!A special shout out and thank you to all of our supporters over on Patreon. You help us continue to churn out “quality” episodes. With your continued support we can take our show on the road! Check out our store over at ⁠⁠⁠⁠⁠⁠⁠⁠Botched Podcast⁠⁠⁠⁠⁠⁠⁠⁠ where you can find tshirts, stickers, pint glasses and more!Give us a 5 star review on Itunes. Doing so will help the show grow, but we will also read out whatever you write at the end of one of our episodes!Feel free to email us any questions, comments or suggestions at ⁠BotchedPodcast@gmail.com⁠Follow us on ⁠⁠⁠⁠⁠⁠⁠⁠Twitter⁠⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠⁠Instagram⁠⁠⁠⁠⁠⁠⁠⁠, subscribe on ⁠⁠⁠⁠⁠⁠⁠⁠Youtube⁠⁠⁠⁠⁠⁠⁠⁠, like us on ⁠⁠⁠⁠⁠⁠⁠⁠Facebook⁠⁠⁠⁠⁠⁠⁠⁠.You can watch the show live on ⁠⁠⁠⁠⁠⁠⁠⁠Twitch⁠⁠⁠⁠⁠⁠⁠⁠!Check out each of the hosts' Twitch streams! ⁠⁠⁠⁠⁠⁠⁠⁠Dennis⁠⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠⁠Phil⁠⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠⁠Tristan⁠⁠⁠⁠⁠⁠⁠⁠Hosts: ⁠⁠⁠⁠⁠⁠⁠⁠Dennis⁠⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠⁠Phil⁠⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠⁠Tristan⁠⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠⁠Steve⁠⁠⁠⁠⁠⁠⁠⁠Editor: Philip D Keating And Dennis RobinsonProducer: Philip and DennisExecutive Producers: ⁠⁠⁠⁠James Thatcher⁠⁠⁠⁠, Chronic Ejac, Jim Beverly,Disgruntled Furniture, Chris Wisdom, ShinigamiSPQR,  Jayson Haiss, Toaster Bath and Scabby GoosePublisher: Phil and DennisArt by ⁠⁠⁠⁠⁠⁠⁠⁠⁠Emily Swan⁠⁠⁠⁠⁠⁠⁠⁠⁠Music by ⁠⁠⁠⁠⁠⁠⁠⁠⁠Gozer⁠

AI can generate an answer in seconds. The harder question is whether it is the right answer to the right question, and what you actually do with it.In this episode, Kate Megaw, Anu Smalley, and Ryan Smith dig into what “human in the loop” really means, and why so many AI transformations are failing. Forbes puts enterprise generative AI failure near 95%, and RAND says more than 80% of AI projects miss. The pattern echoes the early Agile years: chasing a shiny tool without knowing what problem it solves.AI sees the data. Humans see the story behind it. The human brings context, ethics, and judgment, and stays the ethical guardian who catches the hallucination and the answer that is right for the wrong reasons.In this episode, we discuss:The human algorithm - turning AI outputs into real outcomes through context, ethics, and judgmentWhy AI sees the data but only humans see the story behind itAnu's five workflow principles for human-led AI, including protecting the retro and naming a human decision owner for every recommendationWhy so many AI transformations fail, and how it mirrors the early Agile yearsAI-enabled vs. AI-native organizations, and why native winsUsing AI as a tool versus trusting it to run the businessChoosing the right tool for the job instead of defaulting to one model for everythingThe ethical guardian role - catching not just what AI gets wrong, but what it gets right for the wrong reasonsKnowing when to trust AI, when to challenge it, and when to override it Just because AI can do something does not mean it should. That is where humans come in. We are not using AI to replace thinking. We are creating more space for higher quality thinking for the human in the loop.Referenced in this episode: the documentary How I Became an Apocalyptimist (Daniel Rohrer), the Conan O'Brien podcast on how tools change but the task doesn't, the New York Times feature on Box adding AI roles, and the AI-native shift discussed at the Miro Canvas conference.

Tony Squires is joined by Wade Graham, Shane Flanagan and Danny Weidler, once again. Nathan Hindmarsh is MIA! Tony praises the Dragons' win last weekend, and Wade lays a wager down with him and Flanno for this weekend's Sharks v Dragons game. Sharks CEO Dino Mezzatesta joins us to discuss the truth around Ocean Protect Stadium in Cronulla. We wrap the three games so far this weekend, critique Kalyn Ponga's tackle technique, ponder who gets the 6 and 9 jerseys for New South Wales, and ask if the Roosters are the real deal. Plus Tony's Quiz, Believe It or Not? and what's coming up for the rest of the weekend's footy. Check out Triple M NRL's Instagram, Facebook, TikTok and YouTube!See omnystudio.com/listener for privacy information.

Tony Squires is joined by Wade Graham, Shane Flanagan and Danny Weidler, once again. Nathan Hindmarsh is MIA! Tony praises the Dragons' win last weekend, and Wade lays a wager down with him and Flanno for this weekend's Sharks v Dragons game. Sharks CEO Dino Mezzatesta joins us to discuss the truth around Ocean Protect Stadium in Cronulla. We wrap the three games so far this weekend, critique Kalyn Ponga's tackle technique, ponder who gets the 6 and 9 jerseys for New South Wales, and ask if the Roosters are the real deal. Plus Tony's Quiz, Believe It or Not? and what's coming up for the rest of the weekend's footy. Check out Triple M NRL's Instagram, Facebook, TikTok and YouTube!See omnystudio.com/listener for privacy information.

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]

8:05PM: An upcoming Cold Case Video Series by Emily Sweeney of the Boston Globe is in the works. What you can expect! Guest: Emily Sweeney – Social Video Journalist for the Boston Globe (she just got promoted to this new title) 8:15PM: Around 1 in 5 young people use AI chatbots for mental health advice, survey finds. Guest: Alice Connors-Kellgren, PhD, Director of Psychology at Tufts Medical Center 8:30PM: The Squeeze on Mass. Drivers: Car Payments Are Skyrocketing. Average monthly payments for new vehicles have jumped to an all-time high. Guest: Mike Deehan – Axios Boston Reporter 8:45PM: The Scrum – A New Political Newsletter from The Boston Globe. The first issue: The quiet parts get loud in Markey-Moulton Senate primary. Guest: Kelly Garrity – Political Reporter for the Boston Globe – now writer behind The Scrum political newsletterSee omnystudio.com/listener for privacy information.

Data centers are multiplying fast, and the energy demands are staggering. Matt Watson sits down with Tim Tarver, founder and CEO of Exceed Geo Energy, to talk about one of the most underrated power sources in the conversation: geothermal. Tim breaks down how his company is adapting drilling technology from the oil and gas industry to generate clean, baseload energy almost anywhere in the country, why geothermal outlasts solar and wind by decades, and how it could be the right fit for the next wave of AI infrastructure.If you're watching energy costs climb and wondering where the power for all these data centers is actually going to come from, this one's worth your time.Listen now and learn why geothermal might be the energy answer nobody's talking about enough. And if you enjoyed this episode, leave us a review and subscribe so you never miss a conversation with the founders and operators building what's next.⏱️ Episode Breakdown00:44 Introduction to Data Centers and Energy Challenges03:40 Geothermal Energy: A Sustainable Solution06:33 The Role of Geothermal in Data Center Energy Needs09:41 Entrepreneurship in Geothermal Energy12:41 Water Usage and Cooling in Data Centers15:40 Cost Comparison: Geothermal vs. Other Energy Sources18:50 Technological Advances in Drilling and Geothermal Energy21:48 Future of Geothermal Energy and Closing ThoughtsLinks & ResourcesConnect with Tim Tarver on LinkedInExceed Geo Energy - http://www.exegeoenergy.comWhat Smart CTOs Are Doing Differently With Offshore Teams in 2025Subscribe to the Global Talent SprintFull Scale – Build your dev team quickly and affordablyIf you're trying to get your team out of the basement and into real product ownership, this episode is your playbook. Stop being a ticket factory. Build teams that think, create, and lead.Follow the show, rate it, and send this to someone who's still trying to do “real Scrum.” They need it more than you do.

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

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

Everyone knows that a Scrum team should do the value-added work of the product backlog. But there are other types of work that may or may not make it into that backlog, yet these types of work are critical for a well-functioning Scrum team. Join Construx's Earl Beede, Steve Tockey and Mark Griffin as they Inspect & Adapt four types of work that should be part of every sprint plan.

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]

Gareth Rhys Owen and Lauren Salter are joined by former Wales internationals James Hook and Scott Baldwin to assess the 4 Welsh regions' season and pick their player and combined team of the season.

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]

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]

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]

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]

Many leaders assume Agile breaks down in highly regulated environments. John Holmes has spent years proving the opposite inside aerospace, defense, and space programs where the cost of failure is extremely high.   Overview   In this episode, Brian Milner talks with Scrum Inc. Fellow John Holmes about what it actually takes to apply Scrum in complex defense and aerospace organizations. From military programs to space systems, John explains why Agile is often less about moving faster and more about creating visibility, improving communication, and reducing the risk of major surprises late in delivery.   John also shares practical lessons from coaching teams inside highly disciplined environments where command-and-control leadership has traditionally dominated. The conversation explores how Agile can strengthen discipline rather than weaken it, why trust and training matter more than process compliance, and how small operational changes can create meaningful improvements in delivery, alignment, and team effectiveness.   References and resources mentioned in the show:   John Holmes #107: Transforming Organizational Mindsets with Bernie Maloney #108: Adaptive Organizations with Ken Rickard There Is No End State When Transitioning to Agile by Mike Cohn Subscribe to the Agile Mentors Podcast   Want to get involved? This show is designed for you, and we'd love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. John Holmes is a Scrum Inc. Fellow who has spent decades helping aerospace, defense, and government organizations apply Agile and Scrum in some of the world's most complex environments. From launching Scrum for Space at Lockheed Martin to training thousands of leaders and teams since 2005, John brings a practical, field-tested perspective on what it really takes to make Agile work where the stakes are high.

Retrospectives are supposed to help teams improve, but for many teams they slowly become rushed, repetitive, or skipped altogether. In this episode, Brian Milner and Cort Sharp unpack why retrospectives lose their value and what Scrum Masters and leaders can do to make them useful again.   Overview When a team stops engaging in retrospectives, it is usually a symptom of something deeper. Sometimes the format has become stale. Sometimes the team no longer feels safe being honest. And sometimes the biggest issue is that retrospectives create plenty of discussion but very little meaningful change. In this conversation, Brian and Cort explore the most common reasons retrospectives begin to fail and how teams can rebuild trust in the process. They discuss the importance of psychological safety, why teams should focus on fewer actions instead of trying to fix everything at once, and how Scrum Masters can better tailor retrospectives to the personalities and working styles of their teams. They also share practical ideas for making retrospectives more engaging, more actionable, and more valuable over time.   References and resources mentioned in the show: Cort Sharp Amy Edmonson, Psychological Safety #139: The Retrospective Reset with Cort Sharp #141: Cooking Up a Killer Retrospective with Brian Milner The Empirical Retrospective Approach by Mike Cohn Subscribe to the Agile Mentors Podcast   Want to get involved? This show is designed for you, and we'd love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Cort Sharp is the Scrum Master of the producing team and the Agile Mentors Community Manager. In addition to his love for Agile, Cort is also a serious swimmer and has been coaching swimmers for five years.

AI can help product owners move faster, but faster is not always better. In this episode, Lance Dacy and Brian Milner explore where AI genuinely improves product work and where teams still need strong judgment, clear priorities, and real customer understanding.   Overview   As development teams adopt AI tools at a rapid pace, product owners are under pressure to keep up. Brian and Lance discuss how AI is already changing backlog refinement, product discovery, stakeholder communication, and day-to-day product work. They also explore why many teams are still using AI too narrowly and missing larger opportunities to improve decision-making and collaboration.   The conversation stays grounded in practical application rather than hype. Lance shares where AI can save product owners meaningful time, where human judgment still matters most, and why teams need to be careful about treating AI-generated output as automatically correct. If your team is trying to understand how AI fits into modern product leadership, this episode offers a realistic starting point.   References and resources mentioned in the show:   Lance Dacy #117: How AI and Automation Are Redefining Success for Developers with Lance Dacy #164: Why Innovation Efforts Fall Flat with Tendayi Viki AI Doesn't Eliminate Agile Teams — It Increases the Need for Great Ones by Mike Cohn Subscribe to the Agile Mentors Podcast   Want to get involved? This show is designed for you, and we'd love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you'd like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode's presenters are: Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®. Lance brings a great personality and servant's heart to his workshops. He loves seeing people walk away with tangible and practical things they can do with their teams straight away.

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]

Your Retrospective Never Actually Fixes the Alignment ProblemThe retrospective is one of the most protected ceremonies in agile. Scrum teams hold it every sprint. SAFe bakes it into every iteration. Coaches run workshops on how to run better ones. And yet, the same misalignment issues resurface sprint after sprint.This isn't a facilitation problem. It isn't a psychological safety problem. It is a structural mismatch: teams are applying a periodic, backward-looking review to a continuous, structural problem.How to connect with AgileDad:- [website] ⁠⁠⁠https://www.agiledad.com/⁠⁠⁠- [instagram] ⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠- [facebook] ⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠- [Linkedin] ⁠⁠⁠https://www.linkedin.com/in/leehenson/

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]

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]

Eric Ries wrote The Lean Startup. Sold 2 million copies. Helped hundreds of people build companies from nothing. Now he's back with a harder question: why do so many of those companies eventually go bad?In this episode, Matt Watson sits down with Eric to talk about his new book Incorruptible—a deep dive into the invisible forces that corrupt organizations, why profit-maximization becomes pathological, and what it actually takes to build a company that stays great.They get into why the stage-gate development model keeps failing founders, the story of Saul Price and how Costco was born from a betrayal, and what a real fiduciary duty to your customer looks like in practice. Plus, how to structure your company so your values outlast you.Listen to the full episode on Startup Hustle. And if Incorruptible sounds like your next read, pre-order it at incorruptible.co before May 26th.⏱️ Episode Breakdown00:37 Introduction to Eric Ries and The Lean Startup06:57 The Journey to Incorruptible: A New Perspective12:38 The Challenge of Short-Term Thinking in Business16:14 Understanding Corruption in Business Practices22:51 Building Trustworthy Organizations31:03 Who Should Read Incorruptible?Links & ResourcesConnect with Eric Ries on LinkedInWhat Smart CTOs Are Doing Differently With Offshore Teams in 2025Subscribe to the Global Talent SprintFull Scale – Build your dev team quickly and affordablyIf you're trying to get your team out of the basement and into real product ownership, this episode is your playbook. Stop being a ticket factory. Build teams that think, create, and lead.Follow the show, rate it, and send this to someone who's still trying to do “real Scrum.” They need it more than you do.