
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
by Vasco Duarte, Agile Coach, Certified Scrum Master, Certified Product Owner
Is this your podcast?Insights from recent episode analysis
Audience Interest
Podcast Focus
Publishing Consistency
Platform Reach
Insights are generated by CastFox AI using publicly available data, episode content, and proprietary models.
Most discussed topics
Brands & references
Total monthly reach
Estimated from 41 chart positions in 41 markets.
By chart position
- 🇺🇸US · Tech News#9130K to 100K
- 🇩🇪DE · Tech News#1015K to 30K
- 🇬🇧GB · Tech News#1175K to 30K
- 🇨🇦CA · Tech News#1305K to 30K
- 🇦🇺AU · Tech News#1925K to 30K
- Per-Episode Audience
Est. listeners per new episode within ~30 days
107K to 363K🎙 Daily cadence·200 episodes·Last published today - Monthly Reach
Unique listeners across all episodes (30 days)
357K to 1.2M🇧🇷25%🇺🇸8%🇳🇱8%+38 more - Active Followers
Loyal subscribers who consistently listen
143K to 484K
Market Insights
Platform Distribution
Reach across major podcast platforms, updated hourly
Total Followers
—
Total Plays
—
Total Reviews
—
* Data sourced directly from platform APIs and aggregated hourly across all major podcast directories.
On the show
From 10 epsHosts
Recent guests
Recent episodes
The PO Who Doesn't Care vs the PO Who Always Has the Answer | Olaitan Fashanu
Jun 26, 2026
Unknown duration
I Love Data—Why Success for a Scrum Master Means Doing the Hard Measurement Work | Olaitan Fashanu
Jun 25, 2026
Unknown duration
Three Teams, Three Backlogs, One Feature—Can You Make Them See Each Other? | Olaitan Fashanu
Jun 24, 2026
Unknown duration
When the New PO Stops Refining—and the Team Starts Self-Destructing | Olaitan Fashanu
Jun 23, 2026
Unknown duration
The Scrum Master Who Tried to Force His Way In—and Got Schooled | Olaitan Fashanu
Jun 22, 2026
Unknown duration
Social Links & Contact
Official channels & resources
Official Website
Login
RSS Feed
Login
| Date | Episode | Topics | Guests | Brands | Places | Keywords | Sponsor | Length | |
|---|---|---|---|---|---|---|---|---|---|
| 6/26/26 | ![]() The PO Who Doesn't Care vs the PO Who Always Has the Answer | Olaitan Fashanu | 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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Olaitan Fashanu Olaitan Fashanu is a customer-focused professional with expertise in product management, technology, and coaching. He drives digital and agile transformation, builds collaborative cross-functional teams, and delivers high-quality products across markets. Curious and strategic, he explores AI and data intelligence while balancing technical depth, business goals, culture, structure, and long-term vision. You can link with Olaitan Fashanu on LinkedIn. | — | ||||||
| 6/25/26 | ![]() I Love Data—Why Success for a Scrum Master Means Doing the Hard Measurement Work | Olaitan Fashanu | 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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Olaitan Fashanu Olaitan Fashanu is a customer-focused professional with expertise in product management, technology, and coaching. He drives digital and agile transformation, builds collaborative cross-functional teams, and delivers high-quality products across markets. Curious and strategic, he explores AI and data intelligence while balancing technical depth, business goals, culture, structure, and long-term vision. You can link with Olaitan Fashanu on LinkedIn. | — | ||||||
| 6/24/26 | ![]() Three Teams, Three Backlogs, One Feature—Can You Make Them See Each Other? | Olaitan Fashanu | 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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Olaitan Fashanu Olaitan Fashanu is a customer-focused professional with expertise in product management, technology, and coaching. He drives digital and agile transformation, builds collaborative cross-functional teams, and delivers high-quality products across markets. Curious and strategic, he explores AI and data intelligence while balancing technical depth, business goals, culture, structure, and long-term vision. You can link with Olaitan Fashanu on LinkedIn. | — | ||||||
| 6/23/26 | ![]() When the New PO Stops Refining—and the Team Starts Self-Destructing | Olaitan Fashanu | 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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Olaitan Fashanu Olaitan Fashanu is a customer-focused professional with expertise in product management, technology, and coaching. He drives digital and agile transformation, builds collaborative cross-functional teams, and delivers high-quality products across markets. Curious and strategic, he explores AI and data intelligence while balancing technical depth, business goals, culture, structure, and long-term vision. You can link with Olaitan Fashanu on LinkedIn. | — | ||||||
| 6/22/26 | ![]() The Scrum Master Who Tried to Force His Way In—and Got Schooled | Olaitan Fashanu | 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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Olaitan Fashanu Olaitan Fashanu is a customer-focused professional with expertise in product management, technology, and coaching. He drives digital and agile transformation, builds collaborative cross-functional teams, and delivers high-quality products across markets. Curious and strategic, he explores AI and data intelligence while balancing technical depth, business goals, culture, structure, and long-term vision. You can link with Olaitan Fashanu on LinkedIn. | — | ||||||
| 6/19/26 | ![]() Output Owners vs Activators — Two Product Owners Who Defined Aimé's Career | Aimé Flemm | 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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Aimé Flemm Aimé Flemm joins us from the Netherlands. Our guest is an organizational design coach who starts where most agile transformations stop. He works at the structural level: redesigning the incentives, reporting lines, and systems that either enable or quietly kill agility. His belief: you can't coach your way out of a broken org design. You can link with Aimé Flemm on LinkedIn. | — | ||||||
| 6/18/26 | ![]() When The Team Tells You You're Doing Too Much — That's The Success Signal | Aimé Flemm | 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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Aimé Flemm Aimé Flemm joins us from the Netherlands. Our guest is an organizational design coach who starts where most agile transformations stop. He works at the structural level: redesigning the incentives, reporting lines, and systems that either enable or quietly kill agility. His belief: you can't coach your way out of a broken org design. You can link with Aimé Flemm on LinkedIn. | — | ||||||
| 6/17/26 | ![]() Renting The Change vs Owning It — Why LeSS Transformations Get Reversed | Aimé Flemm | 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] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Aimé Flemm Aimé Flemm joins us from the Netherlands. Our guest is an organizational design coach who starts where most agile transformations stop. He works at the structural level: redesigning the incentives, reporting lines, and systems that either enable or quietly kill agility. His belief: you can't coach your way out of a broken org design. You can link with Aimé Flemm on LinkedIn. | — | ||||||
| 6/16/26 | ![]() Culture Follows Structure — Why Some Teams Self-Destruct By Design | Aimé Flemm | 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 the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Aimé Flemm Aimé Flemm joins us from the Netherlands. Our guest is an organizational design coach who starts where most agile transformations stop. He works at the structural level: redesigning the incentives, reporting lines, and systems that either enable or quietly kill agility. His belief: you can't coach your way out of a broken org design. You can link with Aimé Flemm on LinkedIn. | — | ||||||
| 6/15/26 | ![]() Why Solo Scrum Masters Get Fired — The Coalition Of The Willing | Aimé Flemm | Aimé Flemm: Why Solo Scrum Masters Get Fired — The Coalition Of The Willing Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "It doesn't make sense to try and change a system of 2,000 people on your own." - Aimé Flemm Three months into his first gig out of consultancy, Aimé got the call: you're fired. He was at a Dutch pension fund — 2,000 people, deeply ingrained legacy structure — serving as Scrum Master to three component teams, including a UX-only team that couldn't ship anything end-to-end. Full of ambition and fresh ideas from a meetup, he pushed to restructure the teams to be cross-functional. His manager said "yeah, go for it." But Aimé was the only one pushing. He was, in his words, "poking and fighting the system way too much that they had built." So they didn't extend the contract. The lesson he carries from that firing reshaped how he approaches every change initiative since: do not try to do it alone. Find the coalition of the willing first — other Scrum Masters, other change agents, the volunteers — and build a network before you start pushing structural change. Use Scrum Master Syncs, communities of practice, even pizza budgets. Let the change spread like an oil spill. It takes time. It doesn't happen overnight. But you'll still have a job at the end of it. In this episode, we refer to the coalition of the willing and change management tactics for Scrum Masters working in resistant systems. Self-reflection Question: Where in your current organization are you trying to change the system alone — and who could become your first ally if you stopped pushing and started recruiting? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Aimé Flemm Aimé Flemm joins us from the Netherlands. Our guest is an organizational design coach who starts where most agile transformations stop. He works at the structural level: redesigning the incentives, reporting lines, and systems that either enable or quietly kill agility. His belief: you can't coach your way out of a broken org design. You can link with Aimé Flemm on LinkedIn. | — | ||||||
Want analysis for the episodes below?Free for Pro Submit a request, we'll have your selected episodes analyzed within an hour. Free, at no cost to you, for Pro users. | |||||||||
| 6/12/26 | ![]() BONUS Why Your Organization Is Still a Factory — And What an Octopus Can Teach You About Transformation With Phil Le-Brun and Dr. Jana Werner | BONUS: Why Your Organization Is Still a Factory — And What an Octopus Can Teach You About Transformation Phil Le-Brun and Dr. Jana Werner both work inside Amazon, advising Fortune 500 leaders on transformation. But before Amazon, they spent decades in the trenches — Phil as International CIO of McDonald's, Jana leading change in banking and logistics. Together they wrote The Octopus Organization (HBR Press) to explain why most companies are still running on a hundred-year-old factory model, and what the alternative looks like. "We Want to Help You Make Your Own New Interesting Mistakes" "We keep saying, as Phil likes to say, can we help you make your own new interesting mistakes and avoid the mistakes that we see again and again." Jana and Phil are both practitioners who have led large-scale changes — and made mistakes they're now happy to share. Jana describes working with incredible, smart, thoughtful people inside large organizations who weren't trusted, weren't allowed to do the work they could do, and couldn't be their best selves. She managed to turn teams considered underperforming into rock stars simply by listening and giving them space. Phil saw the same pattern at McDonald's — incredible people who knew the answers but weren't allowed to act on them. A disastrous standardization push from 2002 to 2004 taught him that top-down efficiency mandates don't work. The CEO left, and Phil got the opportunity to tap into people lower in the organization, define a common mission, and start building from there. The Factory Model Nobody Questions "There was no upside for her people taking ownership because you could have career-limiting effects if you made a mistake, if you were seen to be making a mistake or overstepping." Jana shared two sides of the same problem. A CEO of a large investment company told her he has to sign off on every small decision — and his people assume he wants to. Neither side wants this, but nobody questions the processes in place. On the other side, a COO told Jana "my people don't want ownership." After half an hour of coaching, the COO realized there was no upside for her people to take ownership — mistakes meant career-limiting consequences. Jana is honest about her own experience too: a team member told her she was micromanaging, and she denied it. They created a secret signal — scratching an ear in meetings whenever she micromanaged. He was scratching a lot. Phil adds that what he calls "yoga babble" — abstractions like "we're going to become an agile platform-based culture" — lets leaders avoid saying what they actually mean. Nobody challenges it because the boss said it, and it sounds sort of right. The result: completely meaningless direction. The Octopus — Distributed Intelligence in Practice "It has two thirds of its intelligence, its neurons, in its arms. The arms connect independently — they don't always need a central brain, but they also have one, so they can stay aligned but also work independently." The octopus has distributed neural clusters in each arm. It can adapt, shape-shift, change the texture of its skin, and even alter its RNA to switch between cold and hot water within hours. For Jana and Phil, this is the organizational metaphor: teams that can think locally and act without waiting for permission from the center, while staying aligned on mission. Phil translates this for team leaders of 8-10 people inside traditional enterprises: Put together teams with cognitive diversity and encourage constructive conflict — what Linda Hill at Harvard Business School calls "creative abrasion" Invest in the storming, norming, performing cycle instead of cutting through it Leave the "how" to the team — the leader's job is the "why" and the "what" Don't jump to the answer — Einstein said if you have an hour to solve a problem, spend 55 minutes understanding the problem Start executing quickly through rapid experimentation; you can't plan your way to success in novel situations Don't Build the Pedestal — The Monkey Comes First "Get to the most tricky problems first, and try and solve them. If you can't, figure out fast — and if you can't, just stop, because your whole project is useless." Astro Teller, CEO of Alphabet X's Moonshot Labs, says: "If you want to teach a monkey on a pedestal to recite Shakespeare, don't start by building the pedestal." Jana explains that organizations, once they get a project through the gauntlet of approvals and business cases, start working on the easy, visible things to show progress — the pedestal. But if you can't get the monkey to speak, the pedestal is useless. The counterintuitive move: when passionate people dispassionately tell you the hard problem isn't solvable, give them hugs, put them on a pedestal themselves, give them bonuses — because they just freed up resources for something better. Phil reinforces that this isn't a money problem. At McDonald's, before building a handheld order-taking device, they built a block of wood to test how comfortable it was to hold. Organizations waste far more money trying to plan for things they can't possibly plan for than they would by running quick experiments. Single-Threaded Leaders — The Pig at Breakfast "Who's that person waking up every morning saying, are we actually putting the focus on the things that are going to get us to the finish line of delivering value — not within my function, but across the organization?" Phil tells the classic joke: a pig and chicken are walking down the road. The chicken says "let's open a restaurant." The pig asks what they'll sell. "Ham and eggs, of course," says the chicken. The pig stops: "I need to be far more committed than you." Organizations are full of chickens — people who lay their half-baked decisions, want to sign off, want to say no. What's needed are pigs. Amazon calls them single-threaded leaders. Apple calls them directly responsible individuals. The key: one person owns an initiative end to end, waking up every morning focused on delivering value across the organization, not just within their function. Mow the Lawn — Bureaucracy Grows While You Sleep "Your bureaucracy grows while you sleep. Think about your bureaucracy like mowing a lawn. You can't mow a lawn once." Jana references Parkinson's Law — a senior Royal Navy leader found that even as the fleet shrank, the number of administrators grew by 5-10% annually. This applies to every organization. Middle managers fill their time by adding processes. One person's mistake becomes a process that penalizes 10,000 people. The solution is continuous gardening. At Google, a senior leader added positive friction: if you want more than 5 interviews in the hiring process, you need my approval. At Amazon, the principle "invent and simplify" asks everyone every year: what are we simplifying? The simplification work has to come from those closest to the problems — most leaders don't know half of what people are actually doing. Innovation Belongs to Everyone — Not a Lab "Psychological safety — it's not even a prefrontal cortex thing, it's not a conscious thought, it's that fight-or-flight reaction you have in the moment." Phil makes the case that innovation starts with psychological safety at the team level, not an organization-wide mandate. It's the team leader asking questions, being humble, responding to disagreement with "tell me more" instead of "I don't agree." It means celebrating intelligent failures — someone who tested a hypothesis, found it didn't work, and stopped. At Amazon town halls, executives open by making fun of Amazon's failures, like the Fire Phone. The message: if you're thinking big, you'll also fail. The Fire Phone didn't work, but it informed future hardware investments. The only true failure is not learning from experimentation. Phil and Jana both emphasize that once leaders experience what happens when people are truly freed to do their best work, they get addicted to it. About Phil Le-Brun and Dr. Jana Werner Phil Le-Brun is the former International CIO of McDonald's and now leads the AWS Executives in Residence team, advising Fortune 500 leaders on transformation. Dr. Jana Werner is an Executive in Residence at AWS who built their EMEA transformation practice after leading digital change in financial services. Together they wrote The Octopus Organization: A Guide to Thriving in a World of Continuous Transformation (HBR Press). You can link with Phil Le-Brun on LinkedIn and Jana Werner on LinkedIn. Book site: theoctopusorganization.com Book on Amazon: The Octopus Organization | — | ||||||
| 6/10/26 | ![]() BONUS Why More Code Doesn't Mean Better Software — And Where AI Actually Helps Your SDLC With Mooly Beeri | BONUS: Why More Code Doesn't Mean Better Software — And Where AI Actually Helps Your SDLC Most teams are adopting AI to write code faster. But what if code generation isn't your bottleneck? Mooly Beeri has spent 25 years diagnosing where software organizations actually underperform — from Microsoft to Philips to automotive — and his message is clear: measure before you automate, and tie every AI investment to a business KPI. The Pattern Debugger's Origin Story "I've been identifying patterns way before AI was doing that. One of my first jobs was Microsoft, and I got the opportunity to work in engineering excellence. Every single simple improvement would make the lives of so many people better and the code better and the products better." Mooly's career started at Microsoft in engineering excellence, where he discovered his passion for finding process areas that need improvement. From there he built the first software centre of excellence for Philips, spawned it into a separate business, and has been doing the same process excellence work across healthcare, telecom, and automotive ever since. His framework: understand where you're bleeding quality, revenue, or budget — then intervene there, not everywhere. Improvement Doesn't Mean Progress "There are too many efforts to improve too many things that don't really matter. The ability to tie a specific improvement to what actually means progress for a business — that, for me, is one critical component that's missing in many transformations." Mooly's core insight applies directly to AI adoption: everyone has an improvement plan, but few can answer "how does this improvement improve business performance?" If you ask that one additional question, you can probably cancel half your improvement projects — the ones that make people feel good but don't move the needle on time to market, quality, or cost. The Code Generation Trap "It's like saying a book author is more productive because they write more words. The unit of work is not the number of lines of code they produce. The unit of work is a piece of code that works, that is tested, that is fully reliable, that meets a customer expectation, and eventually generates revenue." Data from Faros AI shows individual developer PRs went up 98% with AI tools — but organizational delivery actually dropped 1.5%. More code, same or worse outcomes. Mooly explains why: most organizations invest in code generation not because it's the most effective thing to improve, but because it's the easiest step to automate. There are 35 steps in the SDLC. Picking code generation gives you a 1-in-35 chance of striking gold. As the saying goes: hope is not a strategy. Where AI Actually Works in the SDLC "The best usages would be in areas of the SDLC where there is a lot of data that needs processing and needs some detection of patterns — where AI is really, really good." The most successful AI applications Mooly has seen with clients: Defect root cause analysis — training AI agents on thousands of Jira bugs to find patterns humans can't see. In one healthcare client, AI analysis revealed that "false positive" bugs were actually compromised requirements — the dev team was closing real deviations as unimportant because they didn't have time to fix them Code review enhancement — AI scans incoming defects and generates a live, evolving checklist so reviewers spend their limited time checking for the most probable problems Test generation — unit, component, and functional test creation where AI can leverage existing test patterns and requirement data Requirements review — correlating requirements against strategic objectives, OKRs, and historical defect patterns to find contradictions before coding begins The Thinking Process You Can't Automate "The developers going through the process of converting requirements into code — it's actually a thinking process. It creates a lot of discussions with the product managers, a lot of back and forth, which help refine the requirement. This entire exchange is gone out the window when you have AI generate the code in 5 minutes." When AI generates code instantly from requirements, it eliminates the human feedback loop that catches contradictions and incomplete specifications. The FDA has recognized this: every AI-assisted step in medical device software must be guardrailed by human activity. If you generate code quickly but still need a human review, the speed gain disappears. The value of coding was never just the code — it was the thinking. Map Every Investment to a Business KPI "If your uncle ran a bicycle repair shop and you said, let's advertise in the local newspaper, the first question he'd ask is: how many new customers will we get? The business logic hasn't evolved so much. If you want to do something — how will this impact your revenue, your customer retention, or your cost of producing goods? If you can't answer these things, don't invest." Mooly's advice is deceptively simple: before adopting any AI tool in your SDLC, ask yourself which of three business outcomes it will improve — faster time to market, higher quality (fewer customer issues), or better margins (lower execution cost). If you can't draw a direct line from the AI investment to one of those outcomes, you're doing improvement theatre. About Mooly Beeri Mooly Beeri is CEO and co-founder of BetterSoftware, a consulting firm with over 25 years helping companies across healthcare, telecom, and automotive transform how they build software. His work focuses on diagnosing where software organizations underperform and designing targeted interventions — not blanket transformations. You can link with Mooly Beeri on LinkedIn. | — | ||||||
| 6/9/26 | ![]() BONUS Why a Former Chess Champion Thinks Your Leadership Is Stuck in the Opening Game With John Whitt | BONUS: Why a Former Chess Champion Thinks Your Leadership Is Stuck in the Opening Game John Whitt spent 30 years managing billion-dollar construction portfolios in corporate America — sleeping five or six nights a week in hotel beds, traveling the country, winning at someone else's game. Then he walked away. In this episode, he breaks down what chess taught him about business phases, why generosity outperforms hustle in the long run, and how the "pause factor" keeps leaders from burning out while scaling their impact. From Corporate Construction to Coaching — The Move That Changed Everything "I spent 5, sometimes 6 nights a week, sleeping in a hotel bed, traveling around the country, and it really wasn't good for my sanity, it wasn't good for my family. And then the company decided to move from Southern California to Dallas, and so that was like the — I'm not going to Dallas move, and it's time to start something else." John's corporate career was successful by every external measure — managing $500 million construction portfolios at companies like CB Richard Ellis. But the lifestyle was hollowing him out. He'd been thinking about leaving for a while when the relocation to Dallas forced his hand. Through behavioral assessment work, he discovered coaching was where his strengths naturally pointed — it had been his primary leadership style all along. In 2010, he invested in a Focal Point coaching franchise, which gave him the tools and training without having to reinvent the wheel. Combined with 30 years of corporate relationships, it was enough to launch. His reflection on the transition is simple: "The cool thing about coaching is that we're just helping people." The Chess Game of Business — Opening, Middle, and End "The way the chess game is played at the higher levels has influenced my way of thinking essentially for the rest of my life. The opening is where you're getting started — startup business, takes a lot of hustle, a lot of energy. But then the transition happens to the middle game, where you have to think a lot more strategically, and tactically with the right move in the right order, because the wrong order will not get you the results you're looking for." John played in the United States Chess Championships in 1976, and the framework stuck. He maps business growth to three chess phases: the opening (startup hustle, high energy, you do everything), the middle game (strategic delegation, building systems, hiring people with an ownership mindset), and the end game (transitioning assets and resources to serve the life you actually want). The danger zone is the opening-to-middle transition. Founders and leaders get trapped being the go-to person for everything — solving everyone else's problems during business hours and doing their own work after hours and on weekends. The middle game demands a different skill: learning to operate on the business instead of always in it. And it can't happen overnight — you have to prioritize what to change, in what order, or it gets jumbled up. Accomplishing Goals Through Others — The Magic of Discretionary Effort "The magic is accomplishing goals through other people, because when you do that, you're going to do big things. As an individual, you can only do so much. There's only so many hours in a day." John keeps coming back to one idea: if you're doing it all yourself, your impact is capped at 24 hours. The real unlock is getting other people to give their discretionary effort — that extra gear where someone stays 20 minutes longer because they care, or thinks about the project at home because they're genuinely excited. Discretionary effort isn't something you can demand. It comes from inspiration. John frames it through WIIFM — "What's In It For Me?" — everybody's favorite radio station. Leaders who skip that question get compliance. Leaders who answer it get mountains moved. The flip side is equally important: many leaders have never been on a high-performing team, so they don't know what they're missing. They accept compliance as normal. Others are smart and capable but lack the relationship skills to inspire. John's point is clear: leadership through inspiration is a learnable skill, not an innate trait. Generosity as Strategy — Time, Talent, and Treasure "Generosity always — I mean, this is unequivocal — always gives you better long-term results. If you plan to be generous, if you say this is who I am and I will do the work that's necessary to be generous, then you will always get better long-term results." John's 4-Facet LifeShine Generosity Process puts generosity at the center of leadership — an unusual move in a world that defaults to performance metrics and execution frameworks. His argument is that generosity isn't soft. It's strategic. The framework starts with unique identity (who are you?), then moves through three dimensions: time, talent, and treasure. Most people think generosity means writing a check. John says time and talent are far more powerful. A leader who invests the time to communicate vision and inspire the team is being generous — and that generosity compounds into better team performance, stronger relationships, and less burnout over time. The risk, though, is over-giving. Agile coaches and scrum masters who tie their identity to the work are especially vulnerable — they give so generously at work that they burn out when results don't match expectations. That's where the plan matters: define the life you want, build the business or career to serve that life, and stay disciplined about boundaries. The Pause Factor — How Leaders Protect Their Thinking "You gotta learn to say pause. That's a great idea, I understand what you're saying, we need to spend a little more time on that — so let me schedule some time later. Because right now, if I spend all that time, it's not going to get my best thinking, it's not going to get my best response." People bring problems to leaders constantly — personal problems, business problems, urgent and not-urgent mixed together. The instinct is to solve immediately. John teaches leaders the "pause factor": acknowledge the importance of what someone brings you, then schedule dedicated time to address it properly. This isn't avoidance — it's quality control for your own thinking. When you're distracted and rushed, you give worse answers. When you pause, you also create space to ask: is this mine to solve, or does it belong to someone on my team? John extends this to how teams bring problems: train people to come with clarity — here's the problem, here's the challenge, here's some potential solutions. That way the leader can triage effectively in a short time instead of getting pulled into an unstructured conversation that eats an hour. About John Whitt John Whitt is a leadership strategist with 30+ years of business transformation experience, from managing $500 million construction portfolios at companies like CB Richard Ellis to coaching small business owners. He's the author of Checkmate!: Winning Tactics for Translating Ideas Into Money and creator of the Whole Life Leadership experience. You can link with John Whitt on LinkedIn. | — | ||||||
| 6/8/26 | ![]() BONUS The Communication Tax — Why Your Team Collaborates Too Much and What to Cut First With Roman Nikolaev | BONUS: The Communication Tax — Why Your Team Collaborates Too Much and What to Cut First In this BONUS episode, Roman Nikolaev challenges one of the most deeply held beliefs in the agile world: that more collaboration is always better. As Head of Technology at Cambri, Roman has watched teams burn their best hours in meetings and handoffs that create the feeling of productivity without the outcomes. He shares practical tools — from the vacation test to RFC processes — that help teams find the minimum viable level of collaboration. From Senior Engineer to Accidental Manager "I kind of accidentally ended up in management. I didn't want to lead anyone, I wanted to be just a senior engineer doing my stuff. But somehow, four months in the job, I was already leading a team, and then one year after, I was head of technology." Roman's career in engineering goes back to the early 2000s. When he changed jobs during COVID, he specifically didn't want a management role — he wanted to code. But within months he was leading a team, and within a year he was running the entire technical organization at Cambri. That unexpected shift from hands-on engineering to leading teams gave him a front-row seat to how collaboration actually works — and how often it doesn't. What he noticed was that the most important differentiator for technical teams isn't technical knowledge — it's communication, and the tax you pay when communication goes wrong. The Communication Tax Is Real "The communication tax is real. The less we need to pay for communication, the more we can concentrate and own things end to end." Roman describes a pattern most teams will recognize: stakeholders inside and outside the team — product managers, QA, scrum masters, product owners — and at some point, it becomes a game of telephone. The people doing the actual work don't have the context they need. The result? Unnecessary features, wrong implementations, suboptimal technical solutions that don't scale. His argument isn't that collaboration is bad. It's that every handoff, every meeting, every "quick sync" has a cost — and most teams aren't honest about how much they're paying. Handoffs Aren't Collaboration "If you look at a typical software development lifecycle — a ticket created by a product owner, refinement with the team, development, code review, QA, acceptance — there are quite many handoffs. If we can reduce some of this, we get a more effective workflow." Roman walks through the standard ticket lifecycle and counts the handoffs: PO creates ticket, team refines, developer picks it up, code review with other developers, QA phase, acceptance phase. Each transition is a potential information loss. His provocation: instead of involving more people when someone struggles with a task, give the person working on it the tools and knowledge to complete it independently. The trigger for his thinking was a real team conversation where someone suggested everyone should "jump on the ticket" to help. Roman's response: wouldn't it be better to equip the individual rather than create more dependencies? Async Tools That Actually Work "Instead of gathering a meeting where people come unprepared or with some raw ideas, we have ownership for a task. Someone takes their time, writes down their thoughts, options in a document, and then we assign people to review it." Roman shares two async practices his teams use at Cambri. First, the RFC (Request for Comments) process on Confluence — one person owns a decision, writes it up with options, and assigned reviewers sign off asynchronously. It turns out to be more effective at finding better technical solutions while spreading knowledge without requiring synchronous deep-dives. Second, his Monday written updates: every week, he spends about 90 minutes writing a detailed post covering all project statuses, what happened last week, what's coming, and business context. The team feedback in skip-level meetings is consistently positive, and he fields far fewer questions about business context and priorities than before the practice started. The Vacation Test "One heuristic would be that if one of the team members goes on vacation, the rest of the team can continue working on their task." Roman learned this the hard way. He went on a typical Finnish one-month vacation. Before leaving, he explained the architecture and intent for a key task to his team. He came back to discover they'd built the completely wrong thing — wasting one month of a two-month project. He spent the remaining time working weekends, on planes, on trains, just to hit the deadline. The lesson wasn't that he needed more collaboration or synchronous communication before leaving. It was that he needed better communication — and a way to test whether shared context actually exists. His heuristic: if Alice goes on vacation, can Bob continue from where she stopped? If not, you don't need more meetings. You need better async context-sharing. Where to Start: Ownership First, Then Cut Meetings "I would probably first look into if a particular initiative, a feature, or some kind of process has an owner and well-defined roles. Usually, if there is no clear owner, that leads to a lot of synchronous meetings." For Scrum Masters and team leads looking for a practical starting point, Roman offers a two-step approach. First, ensure every initiative, feature, and process has a clear owner with well-defined roles. Without clear ownership, meetings multiply because nobody is sure who's responsible, so everyone attends everything. Second, look at the team calendar starting with the biggest meetings and ask: can this be an RFC? A message? An email? Then experiment — cancel a meeting, replace it with an async channel, and see what happens. You can always bring it back. In the agile world, Roman argues, we should embrace experimentation with our own processes, not just our products. Recommended Resources Roman recommends Team Topologies by Matthew Skelton and Manuel Pais. The book gave him a clear mental model for independent teams that own their area end to end — teams aligned to value streams that own the customer problem completely. For more of Roman's thinking on collaboration, check out his Substack newsletter: Is Your Collaboration Good or Evil? on High Impact Engineering. About Roman Nikolaev Roman Nikolaev is Head of Technology at Cambri. He's spent his career thinking about how teams actually get work done — and his contrarian view that most teams collaborate too much has sparked real debate in the agile community. You can link with Roman Nikolaev on LinkedIn. | — | ||||||
| 6/5/26 | ![]() The Yes-Man Product Owner and the Scrum Master Who Became a Proxy for the Proxy | Maria Skvortsova | Maria Skvortsova: The Yes-Man Product Owner and the Scrum Master Who Became a Proxy for the Proxy In this episode, we refer to User Story Mapping and the MoSCoW prioritization method. The Great Product Owner: Structure Over Gut Feeling — When a Well-Shaped Backlog Speaks for Itself Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The indicator of a good product owner is a well-shaped backlog — with priorities, with values, with efforts. You definitely know that you pull from the top, and it is the most valuable thing you should work on." — Maria Skvortsova For Maria, the best product owners she's worked with share one trait: they bring structure. Not rigidity — structure. They use techniques like user story mapping to make priorities visual for everyone. They use value-effort matrices instead of gut feelings. They apply methods like MoSCoW to give the backlog a clear, unambiguous order. The result? A developer never has to ask "what should I work on next?" — the answer is always at the top of the backlog. Maria, drawing on her decade as a C++ developer, knows firsthand how frustrating it is to chase down a BA or PO just to figure out what to build next. A well-ordered backlog doesn't just help the team move faster — it also makes it easier for the product owner to communicate with the business, because every decision has data behind it, not just intuition. Self-reflection Question: Could a new team member look at your product backlog right now and immediately know what to work on next — and why that item is the most valuable? The Bad Product Owner: The Yes-Man Who Sank the Ship — When Saying Yes to Everything Means Delivering Nothing Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "He was always saying yes. And this led to the scope that grew and grew, until we realized we were not capable of delivering what we committed to." — Maria Skvortsova Maria returns to her SAP migration experience for this anti-pattern. The team had a team lead acting as product owner — someone technical who saw everything as important. Every new requirement got a "yes." The scope ballooned while the iron triangle held firm: fixed cost, fixed time, no room to breathe. The team reached a breaking point where they had to admit, to each other and to the client, that delivery was impossible. Maria stepped in as what Vasco called "a proxy for the proxy" — she helped the team lead build a user story map on Miro, then facilitated a workshop with the business. Her question was disarmingly simple: "If we don't deliver this by go-live, will your product still function? If yes, it goes to release two." That reframing — not "no" but "yes, later" — gave the client clarity without triggering defensiveness. The team lead learned that business stakeholders aren't the enemy; they just need someone to help them make honest trade-offs. And saying "not now" is infinitely more useful than saying "yes" to everything and delivering nothing on time. Self-reflection Question: When was the last time you or your product owner said "not now" to a stakeholder — and did it feel like a failure or a strategic decision? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Maria Skvortsova Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra. You can link with Maria Skvortsova on LinkedIn. | — | ||||||
| 6/4/26 | ![]() If Your People Feel Safe, You Succeed — Measuring What Matters as a Scrum Master | Maria Skvortsova | Maria Skvortsova: If Your People Feel Safe, You Succeed — Measuring What Matters as a Scrum Master Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "If your people feel safe and comfortable in the environment you built, then you succeed. If not, that's something you should change in your ways of working." — Maria Skvortsova For Maria, success as a Scrum Master has nothing to do with green reports or velocity charts. She's seen green dashboards masking miserable teams and sky-high velocity hiding terrible quality. Instead, her definition of success centers on one thing: can a developer honestly tell the product owner that a story isn't ready — and not be punished for it? That's psychological safety in action. Maria measures this through healthy conflict — the team's ability to disagree constructively, to challenge each other without fear. She uses the Vacation, Shopper, Prisoner, Explorer retrospective as a gauge: are people showing up as engaged shoppers and explorers, or as reluctant prisoners? She also emphasizes a practice that many Scrum Masters overlook — having regular one-on-ones with every team member. Not just for task alignment, but to understand their cultural background and personal context. Maria works with people from many different cultures and has learned that what feels like disengagement in one culture might be deep respect in another. Her tip: before assuming you understand someone's behavior, invest in learning where they come from. The cultural awareness you build through those conversations will make you a better Scrum Master than any framework ever could. Self-reflection Question: How do you know whether the people on your team feel safe enough to say "no" or "this isn't ready"? When was the last time you checked? Featured Retrospective Format for the Week: Stinky Fish Maria's favorite retrospective format is the Stinky Fish. The metaphor is simple and vivid: a stinky fish represents the things a team is trying to hide, the elephants in the room that everyone avoids. The longer you hide the fish, the worse it stinks. The exercise asks team members to put their "stinky fish" on the table and admit that something smells. Maria doesn't use this format every sprint — she saves it for when she senses there's something the team is avoiding. She also structures all her retrospectives using the Derby-Larsen model: opening, objective data (burn-downs, defect counts), subjective data, insights, decisions, and closing with a ROTI (Return on Time Invested) vote. For large teams, she uses breakout rooms in pairs — because when you're in a pair, it's impossible not to talk. She also uses Mentimeter for interactive slides, letting people grab their phones, relax, and contribute without the pressure of speaking up in front of 17 people. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Maria Skvortsova Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra. You can link with Maria Skvortsova on LinkedIn. | — | ||||||
| 6/3/26 | ![]() Breaking the Factory Mindset — When a 17-Person Scrum Team Treats Development Like an Assembly Line | Maria Skvortsova | Maria Skvortsova: Breaking the Factory Mindset — When a 17-Person Scrum Team Treats Development Like an Assembly Line Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "They wait for the story to be pushed to them, then they hand it to QAs and say 'it's not my business anymore.' We have not a Scrum team, but a factory." — Maria Skvortsova Maria's current challenge is one that many Scrum Masters will recognize: a large distributed team — 17 people, cameras always off, only four months together — that operates like a factory instead of a collaborative unit. In refinement sessions, only the Tech Lead, BAs, and QA speak. Everyone else stays silent. When the sprint starts, developers wait for the Tech Lead to assign stories, work on them in isolation, then toss them over the wall to QA with a "not my problem" attitude. Maria and Vasco explored this challenge through a coaching conversation, identifying information loss as the core issue. Every handoff between developer and tester destroys knowledge and slows the process. Maria had already introduced desk testing — pairing a developer with a QA before deployment to walk through the code on the developer's machine. It worked well in previous teams, but this team keeps forgetting, and in a recent retrospective they even proposed creating a "handover to QA" subtask — the exact opposite of what Maria is trying to build. The experiment that emerged: find a few early adopters willing to try a deeper collaboration model where developers participate in testing and testers participate in design — starting small, measuring what changes, and letting results speak louder than process mandates. Self-reflection Question: Where are the biggest information loss points in your team's development process, and what experiment could you run this sprint to reduce them? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Maria Skvortsova Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra. You can link with Maria Skvortsova on LinkedIn. | — | ||||||
| 6/2/26 | ![]() The Team That Gave Up — When Green Reports Mask a Sinking Ship | Maria Skvortsova | Maria Skvortsova: The Team That Gave Up — When Green Reports Mask a Sinking Ship Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "They said, 'Yeah, we know, but no one will listen to us.' And they just gave up — waiting for the ship to sink so they could swim away." — Maria Skvortsova Maria walked into a 20-person migration team where the PowerPoint reports glowed green but the reality on the ground was covered in red flags. Developers were building features against requirements that had already changed — nobody had told them. The scope was impossibly large, and when Maria asked the team why they hadn't raised a red flag, the answer shook her: "No one will listen to us." The team had given up. They were waiting for the project to fail so they could leave. Maria's first instinct was to observe — spend weeks understanding the dynamics, the communication patterns, the culture. But she learned the hard way that when a team is already drowning, there's no time for a slow ramp-up. She needed to act immediately. Her breakthrough came from a simple technique: replacing some daily standups with an async RAG (Red-Amber-Green) status system in Jira. Team members just chose a color for each story — no explanation needed. It gave them psychological safety to signal problems without speaking up in a 20-person meeting. From there, Maria broke the team into smaller cross-functional groups — one QA, one developer, one consultant — so they could actually discuss features instead of hiding behind silence. In this episode, we refer to Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem. Also check out the episode with Barry and Christiaan, authors of the book, on the podcast. Self-reflection Question: When you join a new team and sense that something is deeply wrong, how long do you wait before acting — and is that waiting period serving the team or just your own comfort? Featured Book of the Week: Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, and Barry Overeem Maria chose Zombie Scrum Survival Guide because, as she puts it, "Most Scrum Masters learn by the happy path. We all know how it should be. But we rarely think about how it should not be." The book focuses on detecting anti-patterns early — before they become entrenched behaviors that are much harder to break. Maria finds it especially valuable because it provides concrete experiments you can try with your team to shake off the zombie symptoms. Her advice: start here, because understanding what bad looks like is just as important as knowing the ideal. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Maria Skvortsova Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra. You can link with Maria Skvortsova on LinkedIn. | — | ||||||
| 6/1/26 | ![]() When Agile Labels Hide Waterfall Reality — A Scrum Master's Wake-Up Call in SAP Migration | Maria Skvortsova | Maria Skvortsova: When Agile Labels Hide Waterfall Reality — A Scrum Master's Wake-Up Call in SAP Migration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I realized that even if I like Scrum and Agile, and I think they are really good ways of thinking, some areas cannot adapt them because they are completely different from the mindset and ways of working." — Maria Skvortsova Maria came to Agile with the fire of a true believer. After a decade as a C++ developer, she'd found something that matched how she thought and felt about building software — something that went beyond controlling budgets and roadmaps. When a boutique SAP consulting company hired her as an Agile coach to transform their entire organization, she was all in. She built what she describes as a "really good" training for senior management, designed to sell them on Agile ways of working. But when she stepped out of the PMO role and into a real SAP migration project as delivery manager, the ground shifted beneath her. The iron triangle — fixed cost, fixed scope, fixed time — ruled everything. Teams ran "sprints" that were really just boxed iterations with no feedback loops, no value delivery, just a march toward a go-live date. Maria realized she was putting Agile labels on a fundamentally waterfall process. The hardest part wasn't the discovery — it was accepting that she needed to redirect her energy to environments where Agile could genuinely take root, rather than forcing it where the mindset simply didn't exist. Her advice: recognize when labels don't match reality as quickly as possible, and have the courage to choose environments that align with how you want to work. Self-reflection Question: Are you putting Agile labels on processes that are fundamentally waterfall? How quickly would you recognize the mismatch — and what would you do about it? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Maria Skvortsova Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra. You can link with Maria Skvortsova on LinkedIn. | — | ||||||
| 5/30/26 | ![]() BONUS How AI Is Reshaping Software Teams From the Inside With Dwarak Rajagopal | BONUS: How AI Is Reshaping Software Teams From the Inside — Lessons From Google, Meta, and Snowflake In this episode, Dwarak Rajagopal — VP of AI Engineering and Research at Snowflake — shares what he's seeing firsthand as AI agents become part of the software development process. From compressed sprint cycles to automated standups across time zones, Dwarak draws on two decades of building AI infrastructure at Google, Meta, Uber, and Apple to show what's actually changing inside engineering organizations today. From Compiler Engineer to AI Leader — The Thread That Connects Two Decades "In AI, the hardest part isn't just the models itself, it's making them work in real environments where data is messy, fragmented, and governed." Dwarak started his career as an open-source GCC compiler engineer over two decades ago, optimizing hardware performance. He moved into graphics at Apple, then pivoted to AI when AlexNet started running on GPUs around 2011-2012. From there, he built autonomous driving software at Uber, led Meta's PyTorch core framework team bridging research and production, and at Google led AI Frameworks including getting Gemini training on TPUs. The common thread: always working at the intersection of research and production, making powerful technology work in the real world. That focus on real-world application is what drew him to Snowflake — where enterprise data meets AI at scale. AI Is Changing What Engineers Actually Do All Day "Engineers are spending more time on system design, validation, production reliability — and less time doing the implementation itself, because AI is helping that." The shift Dwarak sees is concrete: AI is accelerating development, but the real value comes when it's grounded in enterprise data and context. At Snowflake, teams use tools like Cortex Code, Snowflake Intelligence, and other LLMs to generate code and tests faster — because the friction cost of development has dropped dramatically. Customer example: Whoop, the fitness band company, used Cortex Code with conversational data assistance and agents to reduce development cycles from weeks to hours, freeing teams to focus on high-value work. The End of "This or That" — Try Both, Kill Fast "There's a lot more choices now. You don't have to think about this versus that. Do both and then figure out what is the best." One of the most practical shifts Dwarak describes: teams no longer need to commit to one architectural approach upfront. Because AI reduces the cost of building, teams can pursue two designs in parallel and evaluate both. A concrete example: instead of choosing a cross-platform framework like Flutter or React Native for a mobile app, Snowflake's teams now build native iOS and Android apps simultaneously — one human-led, the other agent-built — at roughly the same speed. But this creates a new challenge: teams have to learn to kill projects faster. When you can build more, you also discard more — and engineers need to detach from "their baby." Smaller Teams, Bigger Output — The Cross-Functional Shift "You could build multiple products now faster with different smaller teams. One back-end person, one front-end person — build vertically end-to-end." Dwarak's teams moved from functional structures (separate backend, frontend, and feature teams) to project-based teams that own the full vertical stack. This isn't theoretical — Snowflake Intelligence was built this way. The result: fewer dependencies, faster delivery, more products in parallel. The tradeoff is coordination cost — more things running in parallel means more decisions to synchronize. Recruiting Has Fundamentally Changed — Systems Thinking Over Syntax "We used to ask an engineer to code a specific search algorithm. Now we ask them to build a whole search system within an hour." Dwarak is clear: fundamentals matter more than ever. Systems thinking, judgment, the ability to work with complex data and production systems — these are what hiring evaluates now. AI handles execution; humans need to define problems clearly and ensure systems behave at scale. For junior engineers, the news is encouraging: onboarding is faster because team-specific skills are codified and shared, and the barrier to building end-to-end systems has dropped. "Learning by building is more true than ever now." Monday Planning, Friday Demos — The Compressed Sprint "You basically decide what to do on Monday, and you're testing together as a team on Friday and getting the feedback for the next week." Daily work has transformed at Snowflake. The traditional multi-week sprint has compressed to a single week: Monday planning, Friday team demos and testing. Standups still happen — but faster, sometimes multiple times per day. For distributed teams across Bay Area, Seattle, and Poland, an automated skill scans each day's code changes and posts a summary in a shared Slack channel — so the next timezone knows exactly what happened without waiting for a meeting. This solves one of the oldest problems in distributed development. The Road to Lights-Out Codebases — Governance, Observability, Reversibility "Can agents take actions? Which of these actions cannot be taken back? You need the concept of committing actions or rolling back." Building on the "lights-out codebases" concept from Philip Su's episode, Dwarak agrees the direction is clear — agents are already writing more code than humans in some contexts. But enterprise adoption requires governance, observability, traceability, and reversibility of agent actions. The shift from "AI as a tool" to "AI as part of the system" is happening now, with the focus moving from getting answers to enabling actions at scale. What Most People Get Wrong About AI in Software "It's very easy to build prototypes, even end-to-end systems. But it's very hard to get it working in enterprises where the data is so messy." The gap between demo and production is where most organizations hit the wall. Enterprise data is scattered across invoices, factory outputs, and dozens of systems — combining it meaningfully for AI to generate insights and actions is the real challenge. This is different from the "AI will replace developers" narrative. The bottleneck isn't code generation; it's data integration, governance, and controlled execution at scale. About Dwarak Rajagopal Dwarak Rajagopal is VP of AI Engineering at Snowflake, where he leads the Cortex AI and AI Research teams. Before Snowflake, he led Google's AI Frameworks and On-Device ML teams (including Gemini), ran Meta's PyTorch Core Frameworks team, and built autonomous driving software at Uber. Two decades of shipping AI at the companies that define the field. You can link with Dwarak Rajagopal on LinkedIn. | — | ||||||
| 5/29/26 | ![]() The "Painting by Numbers" Scrum Master vs. The Quiet Leader Who Made the Team Self-Sufficient | Njegos Ilic | Njegos Ilic: The "Painting by Numbers" Scrum Master vs. The Quiet Leader Who Made the Team Self-Sufficient In this episode, we refer to the concepts of Scrum Master as facilitator and team empowerment. The Bad Scrum Master: The "Painting by Numbers" Approach That Leaves Product Owners Working Alone Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "You basically feel totally alone because you are trying to deliver value as a team, but if nobody asks anything and nobody challenges anything, you end up defining everything yourself." - Njegos Ilic Njegos describes the worst Scrum Master anti-pattern he's witnessed: the "painting by numbers" Scrum Master who runs every ceremony by the book — dailies, refinements, plannings, retros, reviews — but without understanding the purpose behind any of them. The meetings become a reporting cycle: "What did you do yesterday?" with no interaction, no challenging, no real engagement. From the product owner's perspective, this is devastating. Njegos describes feeling completely alone — trying to deliver value as a team while nobody engages, nobody asks questions, nobody pushes back on assumptions. The downstream effect is predictable: gaps that could have been caught early with a single conversation only surface during development or after deployment. Worse, the lack of engagement creates doubt and overthinking — the product owner starts over-defining requirements because there's no feedback loop, which reinforces the very passivity that caused the problem. Self-reflection Question: Are the ceremonies on your team creating genuine engagement and learning — or have they become a reporting cycle that nobody actually needs? The Great Scrum Master: The Quiet, Impactful Leader Who Made the Team Self-Sufficient Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The best Scrum Masters I worked with were invisible — they knew always when to speak, they sensed the pulse of the team, and they weren't afraid to jump in when needed." - Njegos Ilic The best Scrum Masters Njegos has worked with share a common trait: they were almost invisible. They didn't dominate meetings or insert themselves where they weren't needed. But they were always present — sensing the team's pulse, knowing when to step in, unafraid to say "we're out of time, let's take this offline." They were knowledgeable about the product, which earned them genuine respect from developers. And perhaps most powerfully, they delegated facilitation itself. Njegos shares an example where a Scrum Master introduced a round-robin system: when new developers joined the team, everyone took turns facilitating meetings — planning, retros, dailies. This wasn't just delegation for efficiency; it was empowerment by design. Team members who facilitated a retrospective suddenly understood how hard it is to lead one. That empathy changed how they participated when someone else was facilitating. The Scrum Master remained the guide, but the team grew its own capacity to self-organize. Self-reflection Question: If your Scrum Master disappeared tomorrow, would your team know how to facilitate its own ceremonies — and if not, what does that say about how the role is being used? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Njegos Ilic Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output. You can link with Njegos Ilic on LinkedIn. | — | ||||||
| 5/28/26 | ![]() Why Measuring Your Product Bets Is the Key to Product Owner Success | Njegos Ilic | Njegos Ilic: Why Measuring Your Product Bets Is the Key to Product Owner Success Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "If you cannot measure what you build, you will just be depending on who is screaming the loudest and using your gut feeling — which is not a good thing long term." - Njegos Ilic Njegos defines product owner success through three pillars: the ability to measure product bets, deep knowledge of the industry and product, and the humility to admit mistakes and be challenged. The measurement piece is central — without it, he argues, you're flying blind, making decisions based on opinions rather than evidence, reacting to whoever screams loudest rather than what the data shows. But Njegos is honest that not every environment makes measurement easy. Some companies lack the tooling, the culture, or the historical infrastructure to set up proper analytics. In those situations, he turns to user interviews as the next best thing — getting direct feedback from users, even though he acknowledges that opinions are still limited without data to fact-check them against. His most powerful suggestion: invite the whole team to user interviews, not just the product trio. When developers hear directly from users, they connect to real-world problems, and conversations during refinements become richer and more grounded. In this episode, we refer to The Mom Test by Rob Fitzpatrick and Shift: From Product to People by Michael Dougherty and Pete Oliver-Kruger. Self-reflection Question: How do you currently measure whether the features you shipped actually delivered the value you expected — and if you can't measure it, what's your fallback? Featured Retrospective Format for the Week: Start With a Relaxing Exercise Njegos doesn't advocate for a specific retrospective template — and that's the point. From his product owner perspective, he values retrospectives that begin with a relaxing, informal exercise to set the tone. Not everything needs to feel like business as usual. This casual opening allows people to connect as humans first, which opens them up to think differently about what they learned during the sprint. Njegos is candid about the reality: some teams love icebreakers, while others find them childish and just want to get to the point. His advice is to sense the pulse of the team and adapt. The format matters less than whether it creates an environment where people can be honest about what went well, what didn't, and what to improve. A Scrum Master who reads the team's vibe and adjusts accordingly — that's what makes the difference. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Njegos Ilic Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output. You can link with Njegos Ilic on LinkedIn. | — | ||||||
| 5/27/26 | ![]() How a Miro Board Experiment Changed the Way His Team Understood the Big Picture | Njegos Ilic | Njegos Ilic: How a Miro Board Experiment Changed the Way His Team Understood the Big Picture Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Every feature is a product bet. I would call this a process bet — just try to see what works best for you." - Njegos Ilic Njegos shares a change story from his time working with a tech lead who had previously been a Scrum Master — a partnership that made all the difference. Together, they introduced a simple but powerful change: visualizing the team's work on a Miro board instead of relying on a standard ticket board with cards and status columns. They mapped out concepts, connected ticket numbers to a visual representation of how different pieces of work fit together, and used this board during dailies and refinements to track progress in context. The change wasn't imposed top-down — Njegos and his tech lead simply said, "Give us one sprint to try this. If it doesn't work, we drop it." The result was immediate: dailies became more engaging, the team could see how their individual work connected to the bigger picture, and Njegos found it much easier to track progress as a visual thinker. His advice for Scrum Masters and product owners who want to introduce something similar is refreshingly simple — frame it as a "process bet," just like you'd frame a product bet. Try it, measure what happens, and if it doesn't work, drop it and try something else. The willingness to experiment with your own process is a prerequisite for experimenting with the product itself. Self-reflection Question: What "process bet" has your team been avoiding — and what would it take to just try it for one sprint? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Njegos Ilic Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output. You can link with Njegos Ilic on LinkedIn. | — | ||||||
| 5/26/26 | ![]() Why the Product Trio Breaks the Hand-Off Mentality That Kills Team Engagement | Njegos Ilic | Njegos Ilic: Why the Product Trio Breaks the Hand-Off Mentality That Kills Team Engagement Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I can't change people, but I can definitely involve them." - Njegos Ilic Njegos describes a pattern he's encountered multiple times as a product owner: teams where engagement is almost nonexistent. He walks into a refinement session, presents ideas, asks for feedback — and gets crickets. Nobody pushes back, nobody asks questions, nobody challenges the assumptions. The result is a product owner working in isolation, defining everything alone, only to discover gaps during development that could have been caught early with a single conversation. Njegos is honest about the limits of what any one person can do — you can't change people's personalities, and expecting a Scrum Master to do so is unrealistic. But what you can do is involve people. His approach when joining a new team: don't come in announcing how things will work. Instead, learn how the team already works, meet them where they are, and then find ways to fit new concepts into their existing rhythm. For the non-negotiable things — the red lines — he's precise, open, and always provides an alternative rather than just pushing his way. In this segment, we talk about Discovery and Delivery and the Product Trio concept. Self-reflection Question: When you join a team meeting and get silence instead of feedback, do you assume agreement — or do you treat it as a signal that something deeper needs to change? Featured Book of the Week: Inspired by Marty Cagan Njegos recommends Inspired by Marty Cagan as the book that most shaped his approach to product ownership. He highlights the entire SVPG series — including Empowered and Transformed (available as the Product is Hard SVPG Box Set) — but points to the Product Trio concept as especially powerful. As Njegos puts it, the Product Trio — bringing together a product manager, a tech lead, and a designer — removes the hand-off mentality where each discipline works in isolation. Instead of the product owner defining everything alone and handing it to the team, the trio shapes problems together during discovery, so that by the time work reaches the team, there's shared understanding of why they're building something, not just what to build. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Njegos Ilic Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output. You can link with Njegos Ilic on LinkedIn. | — | ||||||
| 5/25/26 | ![]() Why Saying Yes to Every Stakeholder Request Is the Fastest Way to Fail as a Product Owner | Njegos Ilic | Njegos Ilic: Why Saying Yes to Every Stakeholder Request Is the Fastest Way to Fail as a Product Owner Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The game is rigged because they are strong personalities, they want to get things done, but you don't have a magic stick — it's really hard to deliver results if you cannot say no." - Njegos Ilic Njegos shares a failure from early in his career as a product owner in startup environments, where he found himself saying yes to every stakeholder request. Working with strong-willed founders who expected things done their way, Njegos fell into the trap of trying to please everyone — building everything that was asked without pushing back. The result was predictable: scattered priorities, no room to pivot, and a product backlog driven by the loudest voice in the room rather than real user needs. But Njegos frames this failure with a perspective that product owners at any stage can learn from. He compares the learning process to watching children learn to walk — stumbling and falling is not a sign of weakness, it's a necessary step in the process of growing. His advice to product owners currently stuck in this pattern: don't try to avoid failures too hard, because you might prevent yourself from learning the most important lessons. Instead, treat failure as a feedback loop — something happened, you can measure it, and you can change your approach. The key is doing the actual work of reflection: What did I do? What should have been different? What wasn't possible to change, and why? Self-reflection Question: When was the last time you said yes to a stakeholder request even though your gut told you it wasn't the right call — and what would it take for you to say no next time? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Njegos Ilic Njegos is a motivated and forward-thinking Product Manager and Agile Project Manager with experience in fast-paced SaaS environments. He empowers teams through leadership and guidance across product development. With a Lean mindset, he simplifies complexity, delivers in small, testable increments, and leverages rapid feedback loops to prioritize outcomes over output. You can link with Njegos Ilic on LinkedIn. | — | ||||||
Showing 25 of 200
Pitch Fit is a Pro feature
See how bookable this show is for guests, which brands already advertise, the per-episode ad value, and the best-fit guest and sponsor profile. The numbers are blurred on the free plan.
How readily this show books outside guests like you.
How proven this show is for host-read sponsorships.
For Guests
ProFor Advertisers
ProUpgrade to Pro to unlock guest cadence, sponsor categories, fit scores, and per-episode ad value for this show.
Chart Positions
41 placements across 41 markets.
Chart Positions
41 placements across 41 markets.

























