PODCAST · news
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
by Vasco Duarte, Agile Coach, Certified Scrum Master, Certified Product Owner
Every week day, Certified Scrum Master, Agile Coach and business consultant Vasco Duarte interviews Scrum Masters and Agile Coaches from all over the world to get you actionable advice, new tips and tricks, improve your craft as a Scrum Master with daily doses of inspiring conversations with Scrum Masters from the all over the world. Stay tuned for BONUS episodes when we interview Agile gurus and other thought leaders in the business space to bring you the Agile Business perspective you need to succeed as a Scrum Master. Some of the topics we discuss include: Agile Business, Agile Strategy, Retrospectives, Team motivation, Sprint Planning, Daily Scrum, Sprint Review, Backlog Refinement, Scaling Scrum, Lean Startup, Test Driven Development (TDD), Behavior Driven Development (BDD), Paper Prototyping, QA in Scrum, the role of agile managers, servant leadership, agile coaching, and more!
-
200
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.
-
199
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.
-
198
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.
-
197
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.
-
196
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.
-
195
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.
-
194
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.
-
193
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.
-
192
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.
-
191
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
-
190
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.
-
189
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.
-
188
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.
-
187
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.
-
186
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.
-
185
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.
-
184
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.
-
183
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.
-
182
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.
-
181
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.
-
180
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.
-
179
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.
-
178
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.
-
177
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.
-
176
The Jazz Duo Effect and The Absent PO — Two Sides of Agile Product Ownership | Christian Thordal
Christian Thordal: The Jazz Duo Effect and The Absent PO — Two Sides of Agile Product Ownership The Great Product Owner: Clarity, Accountability, and a Partnership That Fills in the Blanks Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "We kind of filled in the blanks for each other, and it felt very natural — it's grown organically into this partnership where we're extremely aligned on how we see and do things." - Christian Thordal Christian describes his best Product Owner as someone he currently works with — a person who combines deep product clarity with genuine leadership. This PO is fully accountable for the backlog, sets clear expectations toward the teams, and isn't afraid to push them. What makes this PO stand out is how they use reporting as a communication tool: alongside the backlog, they proactively communicate to the product leader whether things are within or outside scope, always with a plan ready. Christian and this PO hold weekly follow-ups to discuss the team, the backlog, and the product direction. Over time, their alignment has become so strong that during facilitation sessions they naturally fill in blanks for each other — one picks up where the other leaves off. Vasco compared it to a jazz duo, where each musician picks up on the other's leads in real time. This kind of organic partnership in leadership direction reflects positively on the entire team, creating a sense of coherence and momentum that everyone can feel. Self-reflection Question: How aligned are you with your Product Owner on leadership direction, and what would it take to build the kind of partnership where you naturally fill in the blanks for each other? The Bad Product Owner: When the PO Disappears and the Scrum Master Becomes the Glue Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "You can inspire, you can motivate, but you can't really do the work for them." - Christian Thordal Christian shares an experience from a larger logistics company in Denmark where the Product Owner was a great, likable person — but didn't understand the role. The backlog was high-level, consisting primarily of Epics with no acceptance criteria. Then the warning signs started: the PO became increasingly hard to get a hold of, started canceling refinement meetings (sometimes on the same day), began working more from home, and became physically more distant from the team. Christian and the team were left to navigate on their own, breaking down epics into stories and tasks without knowing if they were building the right product. Christian tried setting up weekly one-hour sessions to help the PO work through the backlog, but the fundamental problem remained — you cannot do the PO's work for them. Eventually, Christian found himself filling in for the PO, which is itself an anti-pattern: the Scrum Master becoming the glue that holds the product together. The symptoms to watch for are clear: a PO who starts missing meetings, backlog items that remain unrefined, a PO who becomes physically or remotely distant, and — the biggest red flag — a Scrum Master who feels compelled to step in and do the PO's job. Self-reflection Question: Are there signs that your Product Owner is drifting away from the team, and have you caught yourself filling in gaps that aren't yours to fill? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Christian Thordal Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results. You can link with Christian Thordal on LinkedIn.
-
175
Structure Creates Freedom, How an Agile Coach Measures Success by Becoming Less Needed | Christian Thordal
Christian Thordal: Structure Creates Freedom, How an Agile Coach Measures Success by Becoming Less Needed Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The less I shine and the more the team shines, the better I perform." - Christian Thordal Christian shares how his definition of success has fundamentally shifted over the years. Early in his career, the question was "How can I shine?" Today, it is the opposite — success means becoming invisible. For Christian, a high-performing Scrum Master builds teams that no longer depend on them, much like raising a child to become a functional adult by eighteen. They can always call dad for coaching or to borrow money, but they can stand on their own. He illustrates this with a team he moved from what he calls "cowboy loose Kanban" to an adapted Scrum framework. The structure gave the team freedom: he can now miss dailies and planning sessions, and the team still produces a solid plan, sprint backlog, and sprint goal. He drops by to give pointers and encourage good behaviors. Christian also highlights the importance of the Scrum Master and Product Owner partnership — "the mom and dad of the team" — and how building predictability and flow matters more than heroics. A key tactical insight: he created a one-pager roadmap for his domain leader showing issues, plans, milestones, and metrics. This simple artifact gave leadership the comfort that things were under control, buying Christian the autonomy to do his best work. This proved critical when his team was decimated by departures in late 2025 — he hired new people, stabilized the group, and got them delivering again. Self-reflection Question: What would it look like if your team could run a full sprint cycle without you present — and what is stopping that from happening today? Featured Retrospective Format for the Week: The Four-Box Retrospective Christian shares a retrospective format he calls the Four-Box Retrospective — a structured, pragmatic approach that resonates especially well with engineer-minded teams. The session begins with a team check-in to get the vibe in the room. Next, the team reviews last week's agreements: who was accountable, and are those items still alive or handled? Anything still alive moves forward automatically, ensuring nothing falls through the cracks. Then comes the core mechanic: topic creation divided into four boxes — Tech (tools and tech stacks), Team (issues within the team), Outside (external dependencies and blockers), and Parking Lot (everything else). Presenters explain their topics briefly to give context, and the group uses dot voting to surface the most pressing issues. Discussion follows, with clear accountability assignments and action items written down. The pre-grouping into four boxes saves significant time by giving topics a natural home before discussion begins. Named owners for every action item create real progress between retrospectives. Christian values this format because it is grounded in actual operational problems — people can see the direct application of every conversation, which keeps engagement high and outcomes tangible. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Christian Thordal Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results. You can link with Christian Thordal on LinkedIn.
-
174
Managing Cross-Team Dependencies in Scaled Agile, From Planning to Real-Time Coordination | Christian Thordal
Christian Thordal: Managing Cross-Team Dependencies in Scaled Agile, From Planning to Real-Time Coordination Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "When one team's plan failed, the rest collapsed — deliveries and outcomes were delayed across the entire domain." - Christian Thordal In this episode, Christian Thordal shares the biggest challenge he faced as an Agile Coach working within a large Danish broadcast company's technology division, where 32 teams operate across multiple domains. Within his domain of 10 teams, they plan in three-month cycles using OKRs, but a critical blind spot kept undermining their results: nobody had a clear grasp of the dependencies between teams and sister domains. When one team's delivery slipped in a previous cycle, it triggered a cascade of failures across the organization. Christian and the agile coaching community escalated the issue to the portfolio and delivery department, pushing to synchronize cycle timing across domains. He introduced a "big room planning" approach within his domain to map out which teams they impact and who impacts them, structured around a three-week cadence: define OKRs, align, then commit. A key coaching insight reshaped his thinking: dependencies are not facts — they are decisions. By naming the specific people involved (the person who needs resolution and the person who provides it), teams can manage dependencies in real-time rather than waiting for a program management layer that only addresses problems after escalation. Christian now plans to establish dedicated coordination days during each cycle where teams actively collaborate and resolve dependency issues together. Self-reflection Question: When dependencies between your teams cause delivery failures, do you treat them as coordination problems to solve in real-time, or do you wait for escalation through a management layer? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Christian Thordal Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results. You can link with Christian Thordal on LinkedIn.
-
173
How "Fake Kanban" Fooled the Metrics, And What This Agile Coach Did to Fix It | Christian Thordal
Christian Thordal: How "Fake Kanban" Fooled the Metrics, And What This Agile Coach Did to Fix It Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The team was like birds in a nest waiting to get fed — completely dependent on the PO for every piece of work." - Christian Thordal Christian tells us about a team that always appeared busy but was hiding serious dysfunction behind a single healthy metric. When he rated the system across his domain, he found the team scored low in process maturity, effectiveness, and learning — yet their cycle time looked good. The team claimed to practice Kanban, but in reality it meant "we can do whatever we want." Daily standups had become social check-ins. The backlog held over 100 items to do and 50+ in progress, most of them just headlines with no descriptions. Real work assignments happened through 30-minute Slack huddles between the PO and individual developers — pure push, no prioritization. Despite having OKRs, the team could only plan a week ahead. Christian's fix was radical: he restarted the backlog entirely, cutting 150 items down to roughly 30, established WIP limits to create a pull-based system, and brought the team into the process as active participants rather than passive recipients. In this segment, we refer to Kanban and OKRs. Self-reflection Question: When was the last time you looked beyond a single "green" metric to understand what was really happening in your team's workflow? Featured Book of the Week: Turn the Ship Around by David Marquet Christian recommends Turn the Ship Around by David Marquet, a former U.S. Navy submarine commander who transformed his crew's performance by replacing permission-seeking with intent-based leadership. Instead of waiting for orders, crew members were expected to say "I intend to..." — transferring ownership and making people accountable for their decisions. Christian says this deeply resonated with his own military background in the Danish Army, where leadership operated on similar principles. The book's core message — stop creating dependency and start building leaders at every level — connects directly to the team story in this episode, where passive dependency on the PO was the root of the dysfunction. You can also listen to previous episodes with David Marquet and explore more on intent-based leadership. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Christian Thordal Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results. You can link with Christian Thordal on LinkedIn.
-
172
When Applying Scrum By The Book Fails, Understanding Context Before Changing The System | Christian Thordal
Christian Thordal: When Applying Scrum By The Book Fails, Understanding Context Before Changing The System Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "I treated Scrum like a military SOP — follow the book, execute the steps. But I failed to see that the context was really the tipping point. What looked like a problem was actually their solution." - Christian Thordal Christian shares a hard-won lesson from his time coaching three RPA teams at one of Denmark's largest banks during the pandemic. He inherited teams running six-week sprints with half-hour planning sessions that amounted to little more than putting items on a calendar. As a former Danish Army officer, Christian's instinct was to fix the obvious deviation from the Scrum Guide — the sprint length. He advocated for shorter feedback loops and eventually convinced the Product Owner, who also served as the director, to try two-week sprints. The first planning session was a disaster. There was yelling and scolding, and it became clear that the real problem had nothing to do with sprint length. The teams had no proper backlog. The six-week sprints actually worked because they gave teams enough time to go out to the business, discover work, and deliver it within a single cycle. Christian realized he had been applying Scrum mechanically without understanding how work entered the system. He started attending business analyst and PO meetings, uncovered the backlog gap, and helped the teams build a proper one. His key insight: what looks like a symptom can actually be a pragmatic solution to real constraints. Understand the system before you change it. In this episode, we refer to the book Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland. Self-reflection Question: When was the last time you assumed a team's practice was wrong, only to discover it was a reasonable adaptation to their context? How might you investigate the "why" behind existing processes before proposing changes? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Christian Thordal Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results. You can link with Christian Thordal on LinkedIn.
-
171
BONUS Your Developers Got 20x Faster — Now Watch Your Product Managers' Heads Explode With Clarke Ching
BONUS: Your Developers Got 20x Faster — Now Watch Your Product Managers' Heads Explode Clarke Ching is "The Bottleneck Guy" — and he just spotted the bottleneck that AI is about to create in every software organization. It's not in the code. It's inside the heads of the people who decide what gets built. In this conversation, Vasco and Clarke unpack why speeding up developers with AI tools pushes the real constraint upstream — onto product managers, designers, and leaders — and what to do before cognitive overload crushes the people your organization depends on most. Every Business Has a Bottleneck — Most Are in the Wrong Place "Every single client I have is a detective puzzle. We're looking for this quiet killer sitting inside their business, siphoning off money. And if you look at them without the idea of going 'where's the bottleneck?' — you mistake the busyness for productivity." Clarke approaches Theory of Constraints like a detective story, not a physics lecture. Every business has a bottleneck — the narrowest point that chokes throughput. The question isn't whether you have one, it's whether it's in the right place. In software development, Clarke argues, the bottleneck should almost always be the developers. Not because they're slow, but because they're the pacing resource — like the aircraft carrier in a naval fleet that sets the speed for everything else. When developers are the bottleneck, the people upstream (product managers, designers, architects) have time to curate high-quality, high-value inputs. The people downstream (testers, ops) can deliver fast feedback. Everything flows. But when the bottleneck drifts somewhere else — and nobody notices — everyone gets busy, nothing flows, and the organization mistakes that busyness for productivity. Clarke's latest book, The Speed Book, lays out how to find where your bottleneck actually is and move it to where it belongs. AI Just Moved the Bottleneck — And Nobody's Talking About It "Just imagine one person trying to feed 100 developers. It's ridiculous. Everyone goes, 'oh, that's just crazy.' But that's kind of going to be what it's like." Here's the problem: AI coding tools — Claude Code, Cursor, Copilot — are making developers dramatically faster. If a team of 5 developers becomes 20x more productive, that's the equivalent of 100 developers. But you still have one product manager feeding them. The bottleneck hasn't disappeared — it's moved upstream. And when a bottleneck moves to the people who make product decisions, three things happen: they cut corners on requirements (shipping half-baked ideas because the team can turn them around fast), they feed developers busy work just to keep them occupied, and — worst of all — they lose the time needed to push through complexity to find elegance. Clarke references Steve Jobs's insight: Apple kept working past "peak complexity" until they reached "peak simplicity." That's where great products come from. But a product manager juggling work for 100 developers has no time for that journey. Elegance goes out the window. Why Giving AI to Product People Almost Makes Things Worse "If you want to wear your dog out so she sleeps, don't take her for long walks. Make the dog think. Brain games exhaust the dog faster than running." The obvious fix — give product people AI tools too — sounds right but misses the point. AI can handle the easy parts of product work: drafting user stories, generating specs, compiling research. That's the equivalent of taking the dog for a run. But the hard parts — the deep thinking about what to build, why it matters, how features interact — that's brain work. And brain work is exhausting in a way that volume work is not. Clarke works with senior leaders whose biggest challenge is pacing themselves. Heavy cognitive lifting burns through energy fast — your brain consumes 30-40% of your body's glucose when you're thinking hard. When AI handles the easy work, the proportion of your day spent on exhausting brain work jumps from maybe 15-20% to 50% or more. It's like lifting weights for six hours straight. You don't get stronger — you break down. On top of that, product people go from coordinating one stream of work to juggling many simultaneous initiatives. Clarke calls these "idea grenades" — and when you're juggling chainsaws with grenades attached, you start dropping things. The Real Danger: Going in the Wrong Direction, 100x Faster "If you change the relative capacities and make some of them much, much faster, the bottleneck's gonna move. My next book, jokingly, is gonna be called 'Who Moved My Bottleneck?'" There's an amplification effect that makes this worse than a simple throughput problem. An error in a line of code affects one line. An error in a design document ripples into hundreds of lines. An error at the strategic level — building the wrong features entirely — can be a disaster for the company. Now add AI speed to that equation. Overwhelmed product people making rushed decisions don't just slow things down — they point the entire organization in the wrong direction, and AI-powered developers execute that wrong direction at 20x speed. As Clarke puts it: you crash into the mountain, faster. The fundamental Theory of Constraints insight applies: if you speed up a non-bottleneck resource, you don't speed up the system. You just create more work-in-progress, more chaos, and more cognitive load for whoever the real bottleneck is. Four Experiments to Try Before Cognitive Crush Hits Your Team "Quality will come from actually slowing down. Money, profits will come from slowing down, building very good products, focusing on why we're building these products, not just how do we keep the AIs working." Clarke offers four practical experiments for teams navigating this shift: Get product people working with AI — as a thought partner, not a turbo boost. Teach them to delegate the routine work to AI so they can protect their cognitive energy for the decisions that actually matter. Think of AI as a delegation tool, not a productivity multiplier. Help product people find their sustainable pace. Like Clarke's gym trainer who said "don't come five days a week or you'll never come back" — the people doing heavy cognitive lifting need to pace themselves. Old-school agile called this sustainable pace. It's never been more relevant. Don't try to keep developers (or AI) busy all the time. The instinct to maximize utilization is the instinct that creates the problem. With AI, you're renting capacity by the minute, not paying salaries. Use it at the pace of good product thinking, not at maximum throughput. Turn the tap on and off as needed. Measure what matters: value delivered, not stories completed. If 60-70% of features rarely get used today, imagine what happens when you 20x the feature output without improving the decision quality upstream. More features, more waste — at scale. About Clarke Ching Clarke Ching is "The Bottleneck Guy" — a Theory of Constraints and lean expert who wrote Rolling Rocks Downhill, the agile+lean business novel that never mentions agile, and The Bottleneck Rules. Born in New Zealand, he spent 20 years abroad (15 of them in Scotland) before returning home. He's spent decades helping teams find and manage the one constraint that controls everything else. LinkedIn You can link with Clarke Ching on LinkedIn.
-
170
The Three Qualities That Separate Great Product Owners From Those Who Just Drop Tickets | Mukhtar Kadiri
Mukhtar Kadiri: The Three Qualities That Separate Great Product Owners From Those Who Just Drop Tickets The Great Product Owner: Decisive, Versatile, and Credible at Every Level Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "This person could hold his own at any level of the organization — with executives, with engineering leadership, and with the team." - Mukhtar Kadiri Mukhtar describes the best product owner he ever worked with through three distinct qualities. First, this person could operate at any level — equally comfortable in a strategic conversation with executives and in a tactical session with the engineering team. Second, they had vast cross-functional knowledge. They weren't a specialist in any one domain, but they could hold intelligent, credible conversations with marketing, go-to-market, customer success, and engineering alike. And third — perhaps most critically — they were decisive. In ambiguous environments where nobody has done this before, teams need someone who will pick a direction and say "let's find out," even if the decision might be wrong. That decisiveness, combined with the ability to course-correct early, is what separates great product owners from those who leave teams waiting for direction that never comes. Self-reflection Question: Which of these three qualities — operating at any level, cross-functional credibility, or decisiveness — is strongest in your product owner, and which one needs the most development? The Bad Product Owner: Not Owning the Backlog 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 don't have a strong product person, engineering just takes over the backlog. And that is dangerous, because it's product that is the representative of the customers." - Mukhtar Kadiri Mukhtar has seen it happen repeatedly: when a product owner doesn't truly own the backlog, a strong engineering lead steps in and takes over prioritization by default. Things still get built — often beautiful, technically elegant solutions — but they don't produce business value because engineering lacks the customer intimacy that product should bring. The fix isn't simple, but Mukhtar identifies three levers. First, mentorship — pairing a junior product person with a more senior one to build confidence and skills. Second, building technical literacy — a product owner who can't meet engineering halfway will always be seen as an outsider dropping tickets. And third, closing the relationship gap between product and engineering. As Mukhtar points out, a product owner is technically a part of the team, but if the team doesn't feel like they're a part of the team, that gap becomes a chasm. There needs to be real overlap between engineering and product — not just shared meetings, but shared understanding. Self-reflection Question: Is your product owner truly a member of the team — or are they just someone who shows up to drop tickets and disappear until the next sprint planning? [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 Mukhtar Kadiri Mukhtar Kadiri is a PM career coach with 15+ years in project management. He specializes in helping project and program managers land $100–300K roles. He's been named the #1 PM in Canada. He also has a LinkedIn following of 67K+ professionals. He shares practical insights for FREE on LinkedIn, where he talks about job search, career growth, and thriving as a PM. You can link with Mukhtar Kadiri on LinkedIn.
-
169
Why Success Means Nothing If the Project Doesn't Move the Business Forward — And How Public Commitments Keep You Honest | Mukhtar Kadiri
Mukhtar Kadiri: Why Success Means Nothing If the Project Doesn't Move the Business Forward — And How Public Commitments Keep You Honest 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're not careful with success, you can deliver a project, but the project will really not do much for the business." - Mukhtar Kadiri For Mukhtar, success is personal — he's the kind of project leader who gets emotionally invested, who thinks about the project after hours, who needs recovery time between engagements. And that emotional investment shapes how he defines success: not as hitting deadlines or completing tasks, but as delivering real business value. He breaks success metrics into three buckets using his signature rule of three: business and product metrics (NPS, revenue, market penetration), project management metrics (velocity, burn-down, risk scores), and software and system metrics (availability, transactions per second, platform health). But the real insight is in how he holds himself accountable. Mukhtar makes public commitments at the start of every project — "Expect status updates from me every week" — because he knows that the discipline of narrating the project's story every week forces him to truly understand what's happening. A status report isn't bureaucratic busywork when you approach it as storytelling: you have to make sense of the data, surface what's relevant, and articulate where the project actually stands. If you can't tell the story, something's missing from your understanding. That weekly narrative becomes both an accountability mechanism and an early warning system. Self-reflection Question: Can you tell the story of your project right now — not just the tasks completed, but the narrative of where it stands, why, and what that means for the business? Featured Retrospective Format for the Week: What Worked / What Didn't Work / Next Steps Mukhtar is a firm believer in simplicity, and his favorite retrospective format reflects that — the classic "What worked, what didn't work, and next steps." He applies his rule of three here as well: three categories are easy for humans to hold in their heads, removing cognitive overhead so the team can focus on the conversation itself. But Mukhtar is quick to point out that a simple structure can still produce terrible retrospectives. What matters more is the facilitation: making sure people feel safe at the very start, level-setting so participants can "land" into the retrospective after jumping from another meeting, giving everyone a moment of quiet introspection to write things down before discussion begins — ensuring both quiet and loud voices are heard. He prepares for every retrospective because, as he puts it, "if you run a bad retro, you could do damage to your team morale and your project." Active facilitation — watching for who isn't speaking, encouraging quieter voices, managing tone — is what transforms a simple format into a powerful conversation. [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 Mukhtar Kadiri Mukhtar Kadiri is a PM career coach with 15+ years in project management. He specializes in helping project and program managers land $100–300K roles. He's been named the #1 PM in Canada. He also has a LinkedIn following of 67K+ professionals. He shares practical insights for FREE on LinkedIn, where he talks about job search, career growth, and thriving as a PM. You can link with Mukhtar Kadiri on LinkedIn.
-
168
Merging Three Companies Into One Platform — When Founders Can't Let Go and Leaders Won't Decide | Mukhtar Kadiri
Mukhtar Kadiri: Merging Three Companies Into One Platform — When Founders Can't Let Go and Leaders Won't Decide Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "A lot of times, conflict arises because people don't understand each other. The first thing you need to do is make sure they understand each other." - Mukhtar Kadiri Mukhtar brings us a challenge from a merger and acquisition program where a dominant software company acquired two competitors simultaneously — both solving the same market gap, each with their own platform, their own founders still in place, and their own fierce loyalties. The mission: merge three platforms into one. But the technical challenge was the easy part. The real complexity was human — founders who'd built their companies from scratch watching their babies potentially get retired, teams losing people to low morale and uncertainty, and leadership paralyzed by the knowledge that every decision would make somebody unhappy. Together, Mukhtar and Vasco explore a four-step approach to navigating these high-stakes disagreements: first, create a feeling of time abundance — never rush a decision that requires buy-in. Second, get each side to present their perspective with only clarifying questions, no judgment. Third, name the disagreement explicitly — turn emotions into concrete, debatable statements. And fourth, co-create an alternative solution that doesn't come from either original position, because co-creation builds commitment. Mukhtar adds a critical fifth element: steel-manning — having each side articulate the other's argument as if defending it. When people feel genuinely understood, even "disagree and commit" becomes possible. In this episode, we refer to steel-manning and the concept of disagree and commit. Self-reflection Question: When you're facilitating a disagreement between two strong positions, do you rush toward a decision — or do you invest the time to make sure both sides can articulate each other's argument before you even think about next steps? [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 Mukhtar Kadiri Mukhtar Kadiri is a PM career coach with 15+ years in project management. He specializes in helping project and program managers land $100–300K roles. He's been named the #1 PM in Canada. He also has a LinkedIn following of 67K+ professionals. He shares practical insights for FREE on LinkedIn, where he talks about job search, career growth, and thriving as a PM. You can link with Mukhtar Kadiri on LinkedIn.
-
167
When the Smartest Person on the Team Becomes the Biggest Bottleneck — And Explodes in a Meeting | Mukhtar Kadiri
Mukhtar Kadiri: When the Smartest Person on the Team Becomes the Biggest Bottleneck — And Explodes in a Meeting Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "A lot of times, the problem is not necessarily technical. It's a human problem. Just figuring out the human dynamics removes the obstacles and makes the project flow." - Mukhtar Kadiri Mukhtar was brought into a healthcare software project where the team couldn't hit any of their milestones. The product manager, engineering team, and head of engineering were supposed to be self-sustaining, but chaos reigned. What Mukhtar found through his one-on-ones was a pattern of finger-pointing — product blaming engineering, engineering blaming product. Then, in one meeting, the head of engineering exploded. He burst out yelling in front of the entire team. In a private conversation afterward, Mukhtar discovered the root cause: this brilliant architect was a bottleneck. Everyone depended on him, he was stretched across multiple projects, and the frustration had been building with no outlet. Mukhtar's approach was direct — "Your name is on this project. Yelling is not going to help." But the real insight came from what happened next. Once the head of engineering started controlling his outbursts, team morale improved almost immediately. Combined with basic structure — regular meetings, low-hanging-fruit milestones — the team built momentum and eventually became self-sufficient. The lesson? No matter how technical the challenge looks, it's always a people problem. And one-on-ones aren't just status updates — they're pressure valves that prevent public explosions that can cause irreparable damage to team morale. Self-reflection Question: Is there someone on your team who's carrying too much load in silence — and what would it take for you to create a safe space where they can express that frustration before it boils over? Featured Book of the Week: HBR Project Management Handbook by Antonio Nieto-Rodriguez Mukhtar recommends the HBR Project Management Handbook because, as he puts it, "A lot of project management books, I can read them and it's almost like I'm not really learning anything new. But this one had substance." After stumbling into project management and leading projects for seven years before even pursuing his PMP, Mukhtar found that most PM books simply codified what he already knew from experience. The HBR handbook was different — it offered breadth, depth, and fresh approaches to common project management challenges. He also recommends the Rita Mulcahy PMP Exam Prep for those preparing for PMP certification, noting that studying for the exam crystallized frameworks around things he had been doing instinctively. [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 Mukhtar Kadiri Mukhtar Kadiri is a PM career coach with 15+ years in project management. He specializes in helping project and program managers land $100–300K roles. He's been named the #1 PM in Canada. He also has a LinkedIn following of 67K+ professionals. He shares practical insights for FREE on LinkedIn, where he talks about job search, career growth, and thriving as a PM. You can link with Mukhtar Kadiri on LinkedIn.
-
166
The Invisible Stakeholder Who Almost Derailed His First Big Project | Mukhtar Kadiri
Mukhtar Kadiri: The Invisible Stakeholder Who Almost Derailed His First Big Project 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. "Nobody really told me, okay, this is what success looks like. And that's a very dangerous thing, because you can just go in there and be busy and be executing." - Mukhtar Kadiri Early in his career, Mukhtar was sitting on the bench with nothing to do — and his days felt numbered. When a low-priority project came along, he jumped at it, eager to prove himself. He met the contract holder, understood the terrain, laid out a plan, and started executing. Then a stakeholder he hadn't even mapped called him into her office and blasted him. The project wasn't aligned with her vision — and it turned out she was more powerful than the contract holder, even though she appeared nowhere on the org chart. That moment forced Mukhtar to rethink everything. He started scheduling one-on-ones with every stakeholder he could find, asking each one what success looked like from their perspective, and then asking them to point him to the next person he should talk to. What emerged was a comprehensive success criteria that no single person had articulated before — because even the leaders hadn't sat down to define it. Mukhtar learned that in complex, ambiguous environments, success isn't handed to you. It's your job to surface it, articulate it, and get everyone aligned. As he puts it, don't be fooled by org charts — the real stakeholder map is one you have to build yourself through one-on-one conversations. Self-reflection Question: When was the last time you validated your stakeholder map beyond the org chart — and could there be an invisible stakeholder whose definition of success you haven't yet discovered? [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 Mukhtar Kadiri Mukhtar Kadiri is a PM career coach with 15+ years in project management. He specializes in helping project and program managers land $100–300K roles. He's been named the #1 PM in Canada. He also has a LinkedIn following of 67K+ professionals. He shares practical insights for FREE on LinkedIn, where he talks about job search, career growth, and thriving as a PM. You can link with Mukhtar Kadiri on LinkedIn.
-
165
From Desk-Pounding to Harmony — How the Game of Go Transformed a Violent Product Owner, and Why Every Employee Should Think Like an Owner | Peter Merel
Peter Merel: From Desk-Pounding to Harmony — How the Game of Go Transformed a Violent Product Owner, and Why Every Employee Should Think Like an Owner In this episode, we refer to The Agile Way by Peter Merel and The Great Game of Business by Jack Stack. The Great Product Owner: The Real Estate Visionary Who Built Channels of Learning 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 a product owner brings an attitude of learning together, it doesn't just create psychological safety — it creates an active experimental mindset and a network of trust relationships that support each other in the learning process." - Peter Merel The best product owner Peter has worked with is Ben White, one of three brothers and partners in Ray White — Australia's largest property management business, started by Ben's great-grandfather. Ben had a vision for transforming how property management works across the entire Australian industry. To realize this vision, he tried to bring an app to market — and failed. Not once, but twice, before succeeding on the third attempt. What made Ben exceptional wasn't his persistence alone, but that each failure became an opportunity to learn how to approach the problem differently. The product he finally brought to market was informed by all of that learning. Ben's real genius, Peter explains, is his ability to establish channels of learning — trust relationships that flow not just through the technical team, but throughout the entire business and back into product development. Without those trust relationships, psychological safety alone isn't enough. Peter also emphasizes that the product owner should be a servant leader, and points to Jack Stack's open book management model where every employee is motivated to think and act as a business owner. When everyone understands that the future of the business is their future, they all collaborate as product owners — and the need for desk-pounding disappears entirely. Self-reflection Question: How many channels of learning does your product owner currently have — and are there trust relationships in the organization that could become active channels but haven't been tapped yet? The Bad Product Owner: The Violent Visionary Who Didn't Understand Collaboration 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 problem isn't the role of product owner. The problem is the relationship between product owner and everybody else." - Peter Merel At Commonwealth Bank of Australia, Peter worked with a business executive who drove the development of a digital product that generated $2 billion in business for the bank. By any business measure, this person was extraordinarily successful. But as a product owner, he was terrible. He pounded desks, went red in the face, insisted that everything the team was doing was wrong, didn't trust anyone, and couldn't be trusted either. The core anti-pattern wasn't the shouting itself — it was that this person didn't understand what a collaborative relationship needed to be. Peter found a creative solution: he taught the executive the game of Go. Go rewards harmony — you lose by being too passive, and you lose by being too aggressive. Through Go, Peter taught the executive to create prompting questions, to work through others so they would carry concerns into meetings, and to provide answers rather than demands. Once the executive saw that collaboration was a more effective way to realize his own vision — faster, better, and more reliably — the behavior changed completely. The insight Peter shares is that before coaching behavior, you sometimes have to prove the business case for collaboration itself. In this segment, we refer to The Agile Way by Peter Merel, which Peter now gives to product owners as a framework for understanding collaborative relationships. Self-reflection Question: When you encounter a product owner who leads through demands rather than collaboration, have you considered showing them that collaboration is actually a faster path to getting what they want? [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 Peter Merel Credited in the first agile book (XP Embraced), keynoted the first agile conference, invented the first agile training game, founded the xscale alliance, authored the agile way, Peter developed software by hand for forty years, coached agile in person for twenty years, and is working now to revolutionize the AI alignment landscape. You can link with Peter Merel on LinkedIn. You can also find his work at agile.way.pm.
-
164
Leadership as a Service — Why Scrum Masters Should Work Themselves Out of a Job and How Quality Circles Make Learning Flow | Peter Merel
Peter Merel: Leadership as a Service — Why Scrum Masters Should Work Themselves Out of a Job and How Quality Circles Make Learning Flow Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "A Scrum Master is a self-defeating role. If you have worked yourself out of a job, then you've succeeded." - Peter Merel Peter Merel challenges the very notion of the Scrum Master as a permanent organizational role. He argues that calling someone a "master" makes everyone else a servant — the opposite of what agile teams need. Instead, Peter advocates for leadership as a service, where every team member provides leadership to their team and every member of a swarm provides leadership to their swarm. He points to the Haudenosaunee Confederacy — the successful direct democratic republic that existed in North America before the USA, and which influenced the American founding fathers — as a model for distributed leadership. The protocol is simple enough to apply universally, regardless of organizational structure. Peter's practical approach to success measurement is equally compelling: build a thin steel thread of alignment, prove it works in 8 to 12 weeks, then split it and backfill with the most progressive people in the organization. He describes growing a group of 300 in just 9 months using this approach. The key insight is that coaches should not think of themselves as change agents, but rather as people who transform change participants into change leaders. Once a team can self-organize without you, your job is to move on to the next challenge — and that's what success looks like. In this episode, we refer to the concept of leadership as a service and the XScale Alliance. Self-reflection Question: If you stepped away from your team tomorrow, could they self-organize effectively — and if not, what's the one thing you could teach them this week that would bring them closer to not needing you? Featured Retrospective Format for the Week: Quality Circles Peter Merel recommends quality circles as a cross-team retrospective format drawn from the Toyota Production System. The concept is simple but powerful: take three teams of six people and break them into six quality circles of three — one person from each team in each circle. These circles meet regularly for 10 to 30 minutes, ideally before team planning sessions, to share problems, ideas, and ways they can help each other. The magic of three people is that while one person explains, another listens, and the third is already thinking about where the conversation goes next — creating what Peter calls "a beautiful hum." Each circle brings two kinds of ideas back to their team: proposals for work that would benefit the teams as a whole, and treaties — working agreements between teams. The teams remain autonomous and can decide how to respond. Peter emphasizes that this approach scales naturally — representatives from groups of teams can form quality circles at higher levels, keeping face-to-face communication alive across entire organizations. As Peter puts it, "Learnings flow across the organization — and that's more valuable than anything you can come up with in a retrospective by yourself." [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 Peter Merel Credited in the first agile book (XP Embraced), keynoted the first agile conference, invented the first agile training game, founded the xscale alliance, authored the agile way, Peter developed software by hand for forty years, coached agile in person for twenty years, and is working now to revolutionize the AI alignment landscape. You can link with Peter Merel on LinkedIn. You can also find his work at agile.way.pm.
-
163
AI Alignment Is the Agile Coach's Next Frontier — Using Throughput Accounting and Pull-Based Transformation to Prove Value | Peter Merel
Peter Merel: AI Alignment Is the Agile Coach's Next Frontier — Using Throughput Accounting and Pull-Based Transformation to Prove Value Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Our jobs ARE about alignment. Alignment is how do we get all of the people and all of the tools to work together for mutual benefit." - Peter Merel Peter Merel brings a provocative perspective on the biggest challenge facing agile professionals today: AI and agile alignment. With AI rapidly advancing, Peter observes that everyone in the agile community is afraid for their jobs — but argues this fear is misplaced. The real challenge isn't replacement; it's alignment. How do we get biological and electronic entities to work together for mutual benefit? Peter's answer begins with pull-based transformation — building a thin steel thread from business through to DevOps, proving it works with a small group, then growing it. He connects this to Goldratt's throughput accounting, arguing that throughput (operating expense plus net profit) is the only metric immune to Goodhart's Law. From throughput, Peter derives three flows: value flow (throughput itself), workflow (the first derivative — what increases value flow), and learning flow (the second derivative — what improves workflow). He then introduces the pirate metrics (AARRR) — acquisition, activation, retention, referral, and revenue — as market constraints that can be analyzed through Theory of Constraints. Peter's frustration is that 25 years after Agile began, most business stakeholders still can't identify their market bottleneck. Without that knowledge, he argues, priorities are meaningless. The path forward for agile coaches? Bring scientific rigor to transformation, measure what matters, and prove value before scaling. In this episode, we refer to FAST Agile, Joe Justice's work with Tesla and WikiSpeed, and the connection between throughput accounting and agile transformation metrics. Self-reflection Question: Can you identify the single biggest market constraint limiting your organization's throughput right now — and if not, how confident are you that your current priorities are the right ones? [The Scrum Master Toolbox Podcast Recommends] 🔥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 Peter Merel Credited in the first agile book (XP Embraced), keynoted the first agile conference, invented the first agile training game, founded the xscale alliance, authored the agile way, Peter developed software by hand for forty years, coached agile in person for twenty years, and is working now to revolutionize the AI alignment landscape. You can link with Peter Merel on LinkedIn. You can also find his work at agile.way.pm.
-
162
When a Hub-and-Spoke Executive Hijacks Your Agile Transformation — And What to Do About It | Peter Merel
Peter Merel: When a Hub-and-Spoke Executive Hijacks Your Agile Transformation — And What to Do About It Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Either you're going to do what you know works, or you're going to step away. Either way, you're not going to do damage to your client." - Peter Merel After a successful transformation at Commonwealth Bank of Australia, Peter Merel moved to Westpac, another major Australian bank, expecting to replicate the same approach. He found an executive who appeared eager to support an agile transformation — but this executive saw agile as the ideal form of micromanagement. Everything and everyone revolved around this one individual, and as Peter began facilitating conversations that didn't hub on the executive, the executive felt disempowered. Peter was blind to this dynamic — he had never encountered it before. The situation deteriorated because Peter had been hired to run a push-based transformation, when he knew from experience that only pull-based transformation works. At Commonwealth Bank, he had built a thin steel thread from business through to DevOps with a small group, proved it worked, and then grown it organically. At Westpac, he let himself be persuaded to push change into the organization, and it compromised everything. The lesson Peter shares is stark: if you can't do what you know works, and you can't step away, then you are the problem. He also warns that when coaches fail this way, they make life harder for whoever comes next — a responsibility that's easy to overlook in the moment. In this segment, we talk about pull-based transformation and why push-based change programs consistently fail in large organizations. Self-reflection Question: Are you currently in a situation where you've compromised on your approach to change — and if so, are you doing more damage by staying than you would by stepping away? Featured Book of the Week: The Agile Way by Peter Merel Peter's own book, The Agile Way, is his modern translation of the Tao Te Ching — a 3,000-year-old text he argues was originally about how to achieve agile development in organizations large and small. Peter first started translating this text in 1989, and after decades of iteration, the book draws connections between ancient wisdom and modern agile practices — XP, Lean, Theory of Constraints, throughput accounting, and permaculture. As Peter explains, "The sage in Lao Tzu is Shang Ren — agile people. This is a book about agile people, agility, and it always was." The book is available at agile.way.pm, and Kent Beck, who wrote the foreword, calls it "a dangerous little book" — dangerous in the same sense as the word extreme. [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 Peter Merel Credited in the first agile book (XP Embraced), keynoted the first agile conference, invented the first agile training game, founded the xscale alliance, authored the agile way, Peter developed software by hand for forty years, coached agile in person for twenty years, and is working now to revolutionize the AI alignment landscape. You can link with Peter Merel on LinkedIn. You can also find his work at agile.way.pm.
-
161
When Telling a Manager "You Don't Have a Role" Backfires — A Lesson in Agile Coaching Humility | Peter Merel
Peter Merel: When Telling a Manager "You Don't Have a Role" Backfires — A Lesson in Agile Coaching Humility Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "A failure is not a failure. A failure is just the first step." - Peter Merel Peter Merel became a Scrum Master by stealth — long before the title existed. Credited in Kent Beck's first XP book and present at the first agile conference, Peter was practicing lightweight processes at Hewlett Packard in the late 1990s. When he took a role at GMAC, the residential finance arm of General Motors, he brought XP practices with him and found early success. After six months of strong results, the project manager, Mike Alakom, sat Peter down and asked the most dangerous management question: "What do I do?" Peter gave what he now calls the stupidest answer possible — "You don't really have a role in this process." The next day, Mike called an all-hands meeting and calmly maneuvered Peter into crediting the entire way of working as Mike's idea. Peter stayed on for another six months, but at arm's length. In hindsight, Peter recognizes Mike did exactly what he should have done. The second failure came at Commonwealth Bank of Australia, where Peter was brought in to coach agile but was actually being set up to fail — a ripcord the organization could pull when it wasn't ready for change. The delivery manager, Des Webster, told Peter directly: "You were set up to fail." Peter walked away, thinking he'd never return. But six years later, every person he had coached had moved up in the organization, and Peter came back as principal coach for 50,000 people. The CIO declared Agile one of the bank's five pillars. Just because you hit the wall doesn't mean it's the end — it might be the beginning. Self-reflection Question: When was the last time you failed at introducing change, and have you considered that the seeds you planted might still be growing in ways you can't yet see? [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 Peter Merel Credited in the first agile book (XP Embraced), keynoted the first agile conference, invented the first agile training game, founded the xscale alliance, authored the agile way, Peter developed software by hand for forty years, coached agile in person for twenty years, and is working now to revolutionize the AI alignment landscape. You can link with Peter Merel on LinkedIn. You can also find his work at agile.way.pm.
-
160
BONUS Why Your Agile Transformation Keeps Snapping Back — And What Systems Thinking Says About It With Natalia Curusi
BONUS: Why Your Agile Transformation Keeps Snapping Back — And What Systems Thinking Says About It Natalia Curusi co-authored a book that doesn't tell you what agile should look like — it tells you what actually happens when you try to transform an organization. Friday-night deployments, zombie teams going through the motions, transformations that met a wall of silence. In this episode, we unpack the real lessons from the front lines: how personal values drive the shift to agile, why some teams have all the ceremonies but none of the substance, and what systems thinking reveals about why transformations fail — or snap back. When Your Values Don't Match Your Ways of Working "I felt like there is a mismatch in my values, my moral values and principles, and customer-centric orientation. So when I found out about Agile around 2010, I understood — okay, this is the answer. Now I have the answer how I can map my moral values and principles with software delivery." Natalia's journey to agile didn't start with a methodology — it started with a gut feeling that something was wrong. Working in large corporations in the early 2000s with fixed-scope contracts, late deployments, and scripts running directly in production, she sensed a disconnect between how work was done and how it should be done. When she moved to a smaller company around 2010 and experienced transparency, collaboration, and the freedom to ask any question without fear, she realized this was the agile mindset — even before she knew the term. The key insight: agile isn't something you adopt, it's something that aligns with values you may already hold. That alignment between personal principles and ways of working is what makes the difference between going through the motions and genuinely transforming how a team operates. Don't Be an Agile Zombie "The first thing I observe — if I go to some of the ceremonies and I see that stand-up becomes like a status meeting, and everybody is reporting to somebody. People are afraid to say some of the things, afraid to escalate risks or assumptions." One of the strongest chapters in the book is titled "Don't Be an Agile Zombie." Natalia describes teams that have all the boards, all the roles, all the right meeting cadences — but nothing is actually changing. The Scrum Master becomes a secretary. The Product Owner is a proxy afraid to make decisions. The tell-tale signs? Fear and formality. When people report upward instead of collaborating sideways, when risks go unspoken because the environment punishes transparency, that's a watermelon project — green on the outside, red on the inside. Natalia's approach starts with observing the tone and dynamics in ceremonies. If the stand-up feels like a status report and not a coordination meeting, something deeper is broken. And her advice is direct: if an organization is delivering waterfall and happy with the predictability and value, that's fine — just call it what it is. Don't put lipstick on a pig. As Rebecca Homkes discussed on this podcast, the key is to communicate the truth with care, but communicate it nonetheless. Task-Driven vs. Value-Driven: The Real Spectrum "It's not right to say that you are agile if you are not. Just name the things how they are — name the things using the right word." Rather than the old waterfall-vs-agile binary, a more useful lens is the spectrum between task-driven and value-driven product development. On the task-driven side, somebody creates the list of tasks — requirements, architecture document, design document — and a project manager distributes them. Teams execute but aren't asked to be creative or adaptable. On the value-driven side, what matters is the impact of what teams build. Value is discovered through the dynamic interaction of functionality with customers — it can't be predetermined. Most organizations sit somewhere on this spectrum, and many are slowly moving toward the value-driven end even if they don't call it agile. The practical takeaway: transformation should be tailored to where an organization actually is, not where a framework says it should be. The book argues for a pragmatic, hybrid approach rather than evangelical purity. Systems Thinking: Why Transformations Snap Back "We did a big agile transformation — five years of real transformation. Then the company was bought, merged with a bigger payment provider. And now they are working with SAFe. And that's the end of the story." In the later part of the book, Natalia and her co-author move into systems thinking — Cynefin, the Iceberg Model, causal loop diagrams. Many agile practitioners stop before they get here because it feels academic. But Natalia argues it's essential, and she illustrates why with a real example: a payment company that went through five years of successful agile transformation using LeSS, only to be acquired by a larger organization that pushed SAFe — and the transformation snapped back. This is the basin of attraction concept: a system has to pass through a point of genuine disruption before it can settle into a new stable state. Without that, it returns to where it was. For practitioners looking to get started with systems thinking, Natalia recommends The Fifth Discipline by Peter Senge and learning to build causal loop diagrams — a practical tool that creates productive conversations about how organizational dynamics actually work. The Post-Agile Era: Beyond Labels "It's like comparing apples and orchestras. You cannot compare agile and AI — they are completely different things. Agile is not enough, but it's also not dead." Natalia addresses the "Agile is dead" debate head-on. Her argument: comparing agile to AI is a category error. An apple cannot play an orchestra, and an orchestra cannot replace an apple — they serve entirely different purposes. AI can handle a significant portion of day-to-day tasks, but it lacks common sense, empathy, and the ability to read a room. Rather than declaring agile dead, Natalia sees a post-agile era — not one where agile disappears, but where we move beyond the label wars. The trends that matter aren't about whether agile is popular; they're about collaboration, adaptability, and understanding how teams and organizations actually work. We can finally talk about what matters in our industry without being pressured to label it. About Natalia Curusi Natalia Curusi is an Agile Coach at Endava with over 20 years in software delivery, specializing in agile transformations, delivery optimization, and systems thinking. She leads Asia Pacific initiatives driving business agility. She is co-author of From Resistance to Resilience: Practical Agile Lessons for Transformation. You can link with Natalia Curusi on LinkedIn and visit her website at nataliacurusi.com. You can also join the Agile Continuum community on LinkedIn.
-
159
BONUS Agile in Construction Track Preview With Felipe Engineer-Manriquez At The Global Agile Summit
BONUS: Hard Hats and Standups — Why the Construction Industry Is Going Agile at GAS26 Felipe Engineer-Manriquez is one of the co-hosts of the Agile in Construction track at the Global Agile Summit 2026. In this preview episode, he and Vasco talk about why Agile belongs on the construction site, what the track's speakers discovered when they stopped following the plan, and why software people should pay close attention to an industry that builds hospitals, not apps. Construction Is 20 Years Behind — And That's the Opportunity "People don't realize that those ideas absolutely work in other industries. Agile's been successfully applied everywhere, and I think where it gets the least amount of publicity is in the construction sector." When most people hear "Agile," they think standups in a tech office, not concrete and rebar. Felipe wants to change that. Construction, he says, is always about 20 years behind whatever process or technology the rest of the world adopts — a "very safe stock of keeping tradition." That gap is exactly what makes this track valuable. Agile is alive and growing in construction, and the translation turns out to be simpler than you'd expect. Most of what needs to change isn't the framework — it's the vocabulary. The sessions in this track show how practitioners made that jump with surprisingly small tweaks. The Speakers Don't Know How Good They Are "Half the speakers that I asked were like, 'what, me? Do I have a story to share?' I was like, yeah, you have this really amazing... people just don't realize how awesome they are." One of the things that struck Felipe while assembling the track was how humble the speakers are. People who have transformed how their companies deliver work — including the keynote speaker, Brian, whose organization celebrated 10 years and saw dramatic before-and-after results — genuinely didn't think their stories were remarkable. They grew up in an industry with 100 years of project management tradition, where PMI-style thinking is the water they swim in. They don't see how different things look from the outside. Some of these practitioners couldn't even work across projects before adopting Agile — and now they're doing it routinely. That capacity shift alone is a data point worth paying attention to. Stop Following the Plan — Start Responding to Change "It's just ground into you, that thou shalt follow a plan. But in reality... they have to do heroic things to make those plans happen. Because the plans are just wrong." Felipe zeroed in on the Agile value of responding to change over following a plan as the single biggest shift his speakers experienced. In construction, plan adherence is gospel — you follow the schedule, period. But in practice, teams were performing heroics just to make flawed plans appear to work. As speakers adopted Agile, they stopped forcing broken plans and started adapting. Felipe gives a nod to #NoEstimates — calling Vasco "the granddaddy of #NoEstimates" — as part of the same insight: the plans are wrong, and the sooner you accept that, the sooner you can respond to what's actually happening. The second pattern was equally powerful: for the first time, construction workers started thinking about who actually uses what they build. You'd think building a school or hospital makes the end user obvious, but Felipe says people in the industry can work for years and never once consider who receives their work. Agile forced that question, and the answers changed how they prioritize. What Software People Should Steal From Construction "Inside of every process are people. Everyone faces resistance to change... when I stopped trying to teach people, and I started inviting people, things changed." Here's the cross-industry lesson Felipe wants software practitioners to hear: resistance to change is universal, and the breakthrough is the same everywhere. Every speaker in the track had a moment where they learned something new and didn't want to go back to the old way. That's the same moment every Scrum Master, product owner, and developer has lived through. The universal tactic that worked? Showing rather than telling. Case study after case study revealed that the real breakthroughs came not from training sessions or slide decks, but from demonstrating results and inviting people in. Stop teaching, start inviting — that's a principle that works whether you're pouring concrete or shipping code. Come Monday, You'll Ask Better Questions "The best thing you're gonna do on Monday after the summit is you're gonna start to ask really intelligent questions. That is gonna be priceless. That's something that AI doesn't even do for people." Felipe's take on what attendees will walk away with isn't a new framework or a certification. It's a shift in the questions they ask. Twenty years into practicing Lean Construction, Agile, and Scrum, Felipe says asking better questions is the one thing that has stuck with him the entire time. Better questions melt away resistance, open up new perspectives, and make new ways of working accessible. The ideas in the track are, in his words, "not terribly complicated — they're actually quite simple, and I would even say elegant." And the speakers are approachable — Felipe personally vouches that every speaker in his track answers emails. There will also be live Q&A sessions during the summit for direct interaction. When Your AI Agent Tells You to Build a Website, You Listen "My chief orchestrator said, you should have your own website. So felipe.engineer was built." In a delightful closing moment, Felipe shared that his personal website at felipe.engineer was built by his AI agent. Not suggested and then hand-coded — fully built, complete with a style guide the agent had strategically created two weeks earlier. Felipe jokes that the AI was setting him up: first planting the seed that he needed a style guide, then recommending it be applied to a brand-new personal site. Felipe also has a session in the track about building an AI bot for construction sites — another reason to check out the full lineup at globalagilesummit.com. About Felipe Engineer-Manriquez Felipe Engineer-Manriquez is a best-selling author, international speaker, and host of The EBFC Show. A force in Lean and Agile, he helps teams build faster with less effort. Felipe trains and coaches changemakers worldwide — and wrote Construction Scrum to make work easier, better, and faster for everyone. You can link with Felipe Engineer-Manriquez on LinkedIn. You can also find Felipe at thefelipe.bio.link, check out The EBFC Show podcast, and join the EBFC Scrum Community of Practice.
-
158
BONUS Agile in Gaming Track Preview With Eagan Rackley At The Global Agile Summit
BONUS: The Game Industry Is Ending — And Why That Might Be the Best Thing for Agile Teams In this BONUS episode, we preview the Agile in Gaming track at the Global Agile Summit 2026 with track host Eagan Rackley. Eagan shares how he curated a lineup of speakers that spans indie studios, AI-driven game platforms, and multi-studio leadership — all focused on the human side of game development during one of the industry's most turbulent periods. If you've ever wondered what Agile looks like when artists, designers, sound engineers, and programmers all need to ship together under pressure, this is the episode. From Agile Coach Client to Track Host "You helped me recognize strengths I'd been dismissing in myself as a leader that I could turn the volume up on, and helped turn me on to some of my more people-first instincts into actual leadership accents." Eagan's path to hosting the Agile in Gaming track started when he worked with Vasco at Malwarebytes in the early 2020s. That coaching relationship shifted how he thought about leadership — moving from dismissing his people-first instincts to leaning into them. When the Global Agile Summit opened up volunteer spots in 2025, he jumped in and co-hosted the development track. Game dev speakers drew strong audience engagement, and when the team suggested a dedicated gaming track for 2026, it was an easy yes. For Eagan, hosting is not just about giving — it is about learning from peers in an industry he transitioned into and loves deeply. Why Agile in Gaming Deserves Its Own Track "A lot of the problems we solve in gaming are the same problems people are solving in Agile everywhere, just with a different space. But also, Agile is very specific in gaming — even something like storyboarding is functionally different because you're describing a car in a city that makes these sounds, that drives with physics in this way." Gaming sits at a unique intersection of disciplines — art, sound, design, engineering, narrative — all collaborating under tight constraints. Agile shows up differently here. The frameworks are similar, but the mechanics of how multidisciplinary teams coordinate are distinct. At gaming conferences, you rarely hear people talk about agility the way the Agile community does, and at Agile conferences, gaming is almost never represented. Eagan saw that gap and built a track to bridge it. The problems — building trust under pressure, introducing change to skeptical teams, managing cross-discipline dependencies — are universal. The context just makes them more vivid. The Producer Who Hates Agile but Runs an Agile Shop "He doesn't like Agile at all. He runs a really humanist-centered version of waterfall that can pivot quickly, which my argument is it's fairly agile, but it's not something he believes in — but it's also one of the most agile places I've ever worked." One of Eagan's most striking observations comes from his current studio, led by an executive producer named Chris Whiteside. Chris explicitly rejects Agile as a label — likely burned by past implementations where someone tried to install a framework rather than nurture a mindset. Yet the way he runs teams is deeply human-centered, responsive, and adaptive. It is a useful reminder that the label matters far less than the behavior, and that some of the most agile organizations don't call themselves agile at all. The pattern Eagan has seen across studios mirrors what happens everywhere: framework-only installations that generate resistance, versus environments where the mindset develops organically. Accessible Excellence: The Skateboard Video Philosophy "I wanted to create a track that felt like accessible excellence. Just pushing beyond right where we were, but you could watch these talks and say, I could do that, that could be me. On Monday morning, I want to go in and try to be that person a little more." When selecting speakers, Eagan drew on an unlikely reference point: a 1990s skateboard video called Zero Hero by a company called Zoroac. The skaters were not doing impossible three-story drops — they were doing moves that felt just one or two steps beyond what you could already do. That is the energy Eagan wanted for the track. Not aspirational keynotes from unreachable experts, but stories from people whose work makes you think: I could try that on Monday. He deliberately chose speakers across a range of experience levels and industry positions to hit that sweet spot. The Speakers and What to Expect "I want this track to be the answer to the question of whether it's worth it to stay in the industry and keep going — with some evidence that there are people out there doing this work thoughtfully, doing it well, and finding ways to remain human." The track features a deliberately diverse lineup. Clinton Keith delivers the keynote, titled "The Game Industry As We Know It Is Ending — And the Future Could Be Much Better," which examines why the old AAA model is failing and where the industry is heading. Umar Ajaz focuses on building Agile into indie studios from the ground up — a timely topic as the industry shifts toward smaller, more agile teams. Kat Antonovich brings a social work background to team dynamics and change management, and Eagan intentionally sought an associate-level speaker because junior professionals have been disproportionately hit by industry layoffs. Marcos Jordt presents on Bitmagic, a fully AI-driven game development platform, along with his experience setting up Agile in Finland. And Kari Koivistoinen addresses the macro level: how to run multiple studios while preventing crunch and keeping team environments healthy. Who Should Register "These are the same problems everyone is solving in Agile. How do you build trust on teams under pressure? Introducing change when people are resistant or skeptical. Those show up everywhere." This track is for curious people — whether they work in gaming or not. If you are interested in how teams solve problems with creativity and constraints, how multidisciplinary collaboration actually works (or breaks down), and what happens when an industry goes through a genuine transformation, there is something here for you. The goal is not prescriptive solutions. It is about getting down to fundamentals: what makes people do their best work and what makes teams function well. For people already in the gaming industry, Eagan designed this track to be the answer to the question many are asking after years of layoffs, studio closures, and canceled projects — is it still worth it? The track says yes, and backs it up with evidence. About Eagan Rackley Eagan Rackley is the track host for the Agile in Gaming track at the Global Agile Summit and a seasoned software engineer and Agile leader with 24+ years of experience spanning game development, enterprise architecture, graphics, and highly parallel programming. A passionate problem-solver, he excels in building collaborative teams, driving innovation, and turning conflict into opportunity. He thrives on creating software that empowers people and transforms ideas into impact. You can link with Eagan Rackley on LinkedIn.
-
157
BONUS People Track Preview With Pete Oliver-Krueger and Alina Thapliyal At The Global Agile Summit
BONUS: Why the People Track Exists — And What It Will Help You See at GAS26 The Global Agile Summit kicks off on May 4th, and the People track is one of the most loaded lineups this year. In this episode, track co-hosts Pete Oliver-Krueger and Alina Thapliyal share the story behind the track, the sessions they're most excited about, and why — in a world increasingly focused on technology and AI — the people dimension is more critical than ever. The Story Behind the People Track "Every transformation still comes down to how people feel, how they communicate, how they work with each other, how decisions are made, and how leaders can create a space and conditions for them to thrive." The People track isn't new to the Global Agile Summit — it's been part of the event for several years, sometimes combined with the Product track. But this year, the volume and quality of submissions made it clear that the topic deserves its own dedicated space. Alina frames it in terms of the VUCA world we operate in: volatility, uncertainty, complexity, and ambiguity make the people dimension more important, not less. Pete picks up the thread with a sharper edge — as AI and technology increasingly dominate the conversation, it's easy to lose sight of the people creating, designing, using, and selling the products. That tension is exactly why he wrote Shift: From Product to People with his co-author Michael. The book exists to pull practitioners out of product-as-a-thing thinking and into product-as-people thinking. Product as a Thing vs. Product as People "When we lose sight of the people around the product is when things start to suffer." When Pete reviewed the track submissions, he noticed a telling pattern — a divergence that confirmed the track's reason for existing. Many submissions talked about product as an artifact, focused on deliverables and outcomes, with no connection to the humans involved. Then there was a second group that immediately saw themselves in the People track. Pete explains the dynamic: we all start by caring about people and solving problems, but at some point we pick a solution and the work of getting it done becomes all-consuming. The task becomes the goal and the people become objects. Unless we consciously leave space to think about relationships and human dynamics, we drift into laser focus on things. The sessions in this track are designed to be the antidote. Marcus Bullock's Keynote — A People-First Success Story "It's so inspiring to just listen to it and think that I can also do it. We can give people a second chance. We can focus on what's good and increase the good, rather than focus on what's bad." Both Alina and Pete highlighted Marcus Bullock's keynote as a must-watch. Marcus, CEO of Flikshop, started from a deeply difficult place and built his way to leading a business and empowering others. What makes his story stand out isn't the arc from adversity to success — it's the honesty. Pete, who has known Marcus for over 15 years, points out that Marcus's story includes genuine ups and downs, and his people-first approach is what helped him weather all of them. Alina was struck by the energy Marcus brings and his focus on amplifying what's good in people rather than minimizing what's bad. It's a message that resonates whether you lead a team of five or an organization of five thousand. Usability Theater — The Courage to Shut Up and Listen "Take a product, give it to a customer, and don't say anything. Just let the customer try it, let the customer experience the product. We need to have the courage to shut up." Alina's second highlight was the session on usability theater, where the core idea is deceptively simple: put your product in front of a customer and resist the urge to explain anything. No "look what we did here," no guided tour. Just observe how people actually interact with what you've built. It takes real courage, Alina says, because our instinct is to showcase and defend our work. But the insights you gain from silence and observation are worth far more than the comfort of narration. This is one of those sessions that sounds simple but could change how you run your next product review or demo. Agency — Breaking the Permission Loop "There is a necessity to understand ourselves and have some of this confidence, but that's true for everybody, even our leaders. They may be stuck in permission loops with their own bosses." Tara Scott's session on agency and breaking the permission loop touched a nerve for both hosts. Alina shared that in companies she's worked for, drawn-out decision processes wasted resources and drove people to leave. Tara's session tackles how to empower people to actually make decisions. Pete adds a crucial nuance: the permission loop isn't just a top-down problem. Leaders are stuck in their own permission loops too. Everyone in the chain faces the same challenge, and the solution can't be found in a vacuum — it requires understanding where each person is coming from and building flexibility across the team and organization. If this topic hits close to home, Tara is also doing a live Q&A during the summit. Neurodiversity, Jeff Patton, and the Full Lineup "Every time I have a conversation with Jeff Patton, it just goes in all kinds of directions, and I have so much fun." Pete flagged two more sessions worth watching. The neurodiversity session with Anita promises to open up a topic that deserves more airtime in the agile community — how different minds experience and contribute to team dynamics. And Jeff Patton, whose conversations with Pete apparently never follow a straight line, brings his signature blend of product thinking and people awareness. The full track covers a wide range: trust, leadership, inclusion, decision-making, neurodiversity. As Alina puts it, these topics are universal — they're about human behavior, and that's valuable in any field where you work with people. A New Lens for Monday Morning "I think people can take away from the track the ability to see other dynamics in their workplace that maybe they currently aren't spending a lot of time paying attention to, or didn't even realize were there." When asked what attendees will walk away with, both Alina and Pete landed on the same metaphor: a new lens. Alina described it as a better understanding of how human dynamics shape culture and performance, paired with practical tips that can be applied immediately — no theory, just real-life stories from real practitioners. Pete took the metaphor further, comparing it to putting on night vision goggles. After watching these sessions, you'll start noticing dynamics you'd been walking past every day — relationship patterns, permission loops, communication gaps. And with that new visibility comes influence. You'll realize you have more ability to shape your environment than you thought, simply because you can now see what was always there. About Pete Oliver-Krueger Pete Oliver-Krueger is an Executive Coach with the Library of Agile, and co-author of the book "Shift: From Product to People", a novel that tells the complex story of how leading "people-first" is required to solve tomorrow's biggest problems. You can link with Pete Oliver-Krueger on LinkedIn, and visit Pete OK's website at https://www.shiftingpeople.com/. About Alina Thapliyal Alina Thapliyal is the Scrum Master for a team within the public sector. Her aspiration is to become an agile coach. She grew up in Romania and has been living in Germany for 13 years. She loves jogging, reading and actively listening to people's life stories. You can link with Alina Thapliyal on LinkedIn.
-
156
BONUS AI in Organizations Track Preview With Michał Parkoła and Michael Dougherty
BONUS: AI Won't Just Change How You Work — It Will Reshape Your Organization The Global Agile Summit is around the corner, and the AI in Organizations track is one you don't want to miss. In this episode, track co-hosts Michael Dougherty and Michał Parkoła walk us through what they've built — from the thinking behind the track name to the sessions that stood out, and why this isn't just another AI conference lineup. Why "AI in Organizations" — Not Just "AI" "AI will not only be useful to existing organizations, but it will reshape organizations in a very significant way, the same way cars reshaped cities." Michael and Michał drew a deliberate line with the track name. Michael points out that AI has been around for decades — it didn't start with ChatGPT. The real shift now is AI agents scaling to enterprise level, replacing automation that used to require specialized tools. Claude Enterprise holds about 29% of the enterprise AI market, Gemini around 15%. But Michał pushes the framing further: the first-order effect is applying AI to existing work. The second-order effect — the one he's most interested in — is how AI will reshape organizations themselves. New species of companies will emerge, smaller teams will achieve what used to require hundreds of people, and some existing organizations won't survive the transition. That's the conversation this track is designed to start. Filtering the Signal From the Slop "There was a bit of AI slop in the submissions. There was a lot of talk that, unfortunately, was meta-talk — there was no real value that I could glean." When session submissions came in, Michael was disappointed by how many were surface-level — big promises with no practical takeaway. The ones that stood out were practitioners showing what they actually do. Dave Westgarth, for example, demonstrated how he uses AI with Lovable and Claude embedded in Miro whiteboards to enhance real team interactions. On Michał's side, the standout was Max Pirata, who challenged the "vibe coding is slop" narrative. His argument: the quality of large-scale software has never depended on the infallibility of individual engineers — it depends on disciplined engineering processes. The same applies to agentic engineering. Your first attempt at vibe coding will be rough, but there are ways to apply engineering discipline to AI-assisted development. That's what Max will be talking about at the summit. Prototyping at the Speed of Thought — And the Human Bottleneck "Now I've got 20 prototypes that I can choose from. Which ones are the best? Which ones do I need to clear out? Product managers now have a different game they play." Two sessions capture opposite sides of the AI-in-organizations tension. Dave Westgarth's "Vibe UX: Prototyping at the Speed of Thought" shows how vibe coding lets you build full working systems instead of Figma mockups — so fast that the bottleneck shifts from creation to selection. Product managers and product owners now face a new challenge: clearing the closet of AI-generated options rather than validating a single bet. On the other side, Shawn Wallack's session — "Even With AI, Your System Will Never Be Better Than Its People" — brings the counterpoint. Michael explains the systems-thinking angle: AI does what you tell it, fast and accurately, but that speed reveals human bottlenecks everywhere else. He shares the cautionary example of AI declining twice the insurance claims humans did, with the human-in-the-loop rubber-stamping instead of actually checking — leading to a class action lawsuit. The lesson: AI doesn't remove the need for human judgment, it makes it more critical. Gojko Adzic on Spec-Driven Development and Building AI Products "True to his roots, he is exploring spec-driven development now, which is one of the popular threads in agentic engineering." Gojko Adzic — the author of Specification by Example and Impact Mapping — brings heavyweight credibility to the track. Michał reveals that while Gojko is exploring spec-driven development in the context of agentic engineering, the interview focused more on his hands-on experience building his own AI products. For attendees, this means real practitioner insights from someone who literally wrote the book on how specifications drive software quality — now applying those principles in an AI-first world. From Beginner to Builder — Who This Track Is For "My favorite case would be people who will quit their jobs and start new companies that will be able to achieve wonderful things with much smaller teams than we would otherwise imagine possible." The track is designed to meet people wherever they are. Pierre Beaning covers the basics of using Claude for beginners. Jason Little — who Michael describes as a "techno nerd" and "grand poobah" — shows how to build and scale multi-agent systems for business. The spectrum runs from "I've only used AI to plan a vacation" to "I'm orchestrating agent teams." But Michał's vision for the ideal attendee is bolder: someone who walks away ready to start a company. Michael backs this up with the story of an AI unicorn — $1.8 billion valuation, one guy and his brother, in the pharmaceutical industry, just a few months old. Hype? Maybe. But Michał's pragmatic take lands it: "If you make a few million, even if it dies later, that's not such a bad thing." The goal of the track is to blow away the fog — throw flares into key spots so people can sketch a map of what's possible and decide which areas deserve a follow-up. About Michael Dougherty Michael Dougherty is the Co-author of Shift: From Product to People, leadership coach with 30+ years helping organizations adopt people-centered, agile ways of working. Co-owner of the Global Agile Summit. You can link with Michael Dougherty on LinkedIn and find out more at shiftingpeople.com. About Michał Parkoła Michał Parkoła is an Agile practitioner based in Warsaw, Poland. Previously hosted the Value-Centric Product Development track at Agile Online Summit 2024. He is building Tapestry, an AI planning assistant. You can link with Michał Parkoła on LinkedIn and check out Tapestry at growwithtapestry.com.
-
155
The Curious Product Owner and the Disempowered One — How Scrum Masters Can Help POs Find Their Voice | Viktor Glinka
Viktor Glinka: The Curious Product Owner and the Disempowered One — How Scrum Masters Can Help POs Find Their Voice In this episode, we refer to product owner anti-patterns and product owner interviews on the Scrum Master Toolbox Podcast. The Great Product Owner: The Curious Negotiator Who Uses Data and Passion 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. "Great product owners are always asking: what if? How can we do it differently? How can we simplify?" - Viktor Glinka Viktor describes great product owners as fundamentally curious people who constantly look for simpler, better ways to do things. But curiosity alone isn't enough — they're also skilled negotiators who navigate conversations with teams, stakeholders, and customers. In scaled setups, their work shifts from clarification to prioritization, and they delegate effectively. Viktor highlights their visualization skills with a concrete example: one product owner showed stakeholders a work composition chart revealing that more than 50% of the team's work was technical debt, making it impossible to deliver new features. That single visualization changed the conversation. Great product owners are also systems thinkers who understand dynamics and root causes, avoiding local optimization. Viktor adds something rarely discussed in frameworks: mindfulness. Product owners face constant pressure, and the ability to make peace with decisions — to move forward without regret — is critical. They also share their passion and vulnerability with development teams, telling them personally why they want to build something. It's the emotional complement to data-driven negotiation. Self-reflection Question: Does your product owner use data and visualization to negotiate with stakeholders, or do they rely on authority and deadlines? How could you help them build those skills? The Bad Product Owner: The Disempowered Middleman Who Can't Give Direction Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "This fear of not being allowed — it's an illusion. You can always do more. Just try. No one will fire you for a suggestion." - Viktor Glinka For Viktor, the worst product owner anti-pattern isn't about skill or knowledge — it's about empowerment. He believes every person can learn to become a great product owner if they are empowered and trusted by the organization. The red flags are clear: when a product owner talks about deadlines and commitments but never about return on investment or outcomes, that's a sign they're being pushed rather than empowered. Viktor shares the story of a product owner who was struggling to give direction because stakeholders just wanted their features delivered. He was a middleman — afraid to communicate his own vision to the team, afraid to challenge stakeholders. But inside, there was a spark of passion about the product. Viktor helped him uncover it using a simple tool: the product vision canvas. They sat down together and put his thoughts on paper. Once the vision was written, the product owner started thinking about the next step on his own: "What if I show this to stakeholders? What if I tell them there's a better way?" The product vision canvas became the bridge from learned helplessness to ownership. Self-reflection Question: Is your product owner telling themselves "I'm not allowed to" when they actually could do more? What's the smallest experiment you could run together to test that assumption? [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 Viktor Glinka Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life. You can link with Viktor Glinka on LinkedIn.
-
154
Why Context Is King for Scrum Master Success — Building Capabilities That Drive Business Goals | Viktor Glinka
Viktor Glinka: Why Context Is King for Scrum Master Success — Building Capabilities That Drive Business Goals 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. "Product management skills are crucial for Scrum Masters. Once you understand how retention impacts your return on investment, you will be able to coach your product owner." - Viktor Glinka Viktor offers a nuanced perspective on Scrum Master success by distinguishing between short-term and long-term success. On the long-term side, he argues that the purpose of a Scrum Master extends beyond working with teams — it's about helping improve the system as a whole. To do that, you need to connect your contribution to the product's success by helping build specific capabilities. Viktor grounds this in practical terms: start by asking what the business goal of your company is, and check whether people around you actually know it. Never assume everyone does. That simple act of curiosity gives you the information you need to figure out how to contribute. In his experience, the key capability his teams needed to develop was multi-learning — the ability to work across components — and that directly served the business goal. Viktor makes a strong case that Scrum Masters need product management skills. Understanding how metrics like retention impact long-term success allows you to coach product owners and analyze product dynamics. His practical advice: if you're not experienced in this, go shadow your product owner, spend time with the sales department, and look through customer support tickets. You'll understand far more about the system than staying at the development organization level. Self-reflection Question: Can you clearly explain how your work as a Scrum Master contributes to your product's success? What specific capability are you helping the system build right now? Featured Retrospective Format for the Week: Data-Driven Discussions with Actionable Outcomes Viktor's approach to retrospectives is refreshingly pragmatic: it depends on the team. For teams not yet used to actionable improvements, he starts simple — review previous retro decisions, ensure new concrete ones are created, and bring data as food for thought. He particularly likes using the cumulative flow diagram and time distribution histogram to help teams reflect on consistency in delivery. One team he worked with adopted this as a natural habit over time. For mature teams, format matters less — one team ran a simple "good, bad, to improve" retro in 30 minutes on their own, without a Scrum Master, and it was one of the most engaged and effective retrospectives Viktor had ever seen. He also values the free-talk format when first meeting a new team, coming in with genuine curiosity and no biases. And when something clearly went wrong — an incident, a failure — Viktor drops whatever format he had prepared. "In those moments, it's important to trust your instinct, read the room, sense the tension, and step into the danger directly." [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 Viktor Glinka Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life. You can link with Viktor Glinka on LinkedIn.
-
153
From Component Teams to Cross-Functional Teams — How to Navigate the Hardest Agile Transformation | Viktor Glinka
Viktor Glinka: From Component Teams to Cross-Functional Teams — How to Navigate the Hardest Agile Transformation Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Our customers do not buy our components. They use the product as a whole. And when it comes to integration, the real problem pops up." - Viktor Glinka Viktor brings a challenge many Scrum Masters face: transitioning from component teams to cross-component, cross-functional teams in a large-scale Scrum setup. Picture 8 to 10 teams, each owning their own part of the system, never touching anything else — and the company stuck in delivery for months. The premise behind component teams sounds logical: specialization leads to speed. But as Viktor explains, that speed is local — optimized for the component, not the product. When integration time arrives, responsibility gaps appear, rework multiplies, and teams start identifying with their components rather than the product. "We're the billing team — we don't deal with anything else." When they reorganized into cross-functional teams, the complaints were immediate: "I was really productive before, and now I can't finish anything." Viktor and his fellow Scrum Masters took a two-pronged approach. First, they secured time credit from leadership — a couple of months where learning was prioritized over deadlines. They ran mob programming sessions, coached teams, and removed impediments. Second, they shifted focus from outputs to outcomes, organizing customer interviews that helped developers understand what users actually needed. The development director reinforced this by joining refinement sessions, telling teams: "You might not develop anything if it still satisfies the customer need." The result was a shift from transactional stakeholder relationships to genuine cooperation, and teams that began to see beyond their component boundaries. Self-reflection Question: If your teams are organized around components, what would it take to run one experiment — just one sprint — where a team picks up work outside their usual component? What would you need to make that safe? [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 Viktor Glinka Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life. You can link with Viktor Glinka on LinkedIn.
-
152
When Internal and External Team Members Have Divergent Goals — The Silent Killer of Agile Teams | Viktor Glinka
Viktor Glinka: When Internal and External Team Members Have Divergent Goals — The Silent Killer of Agile Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The root causes for destructive team patterns often lie outside the team itself." - Viktor Glinka Viktor shares a story from a manufacturing organization where one team stood out — and not in a good way. The team was composed of both internal and external members, and what no one saw coming was that their implicit goals were fundamentally divergent: the external members were focused on maximizing revenue for their own company, while the internal members cared deeply about product quality. The signs were visible to anyone who approached them — they barely talked to each other and preferred to work individually. When Viktor tried to raise the topic of cooperation and trust, he was met with awkward silence. One team member finally told him: "I don't want the team to blow up. In my previous experience, I raised this topic and that was the end of the team." Fear kept the truth underground. Viktor brought his observations to the manager, who acknowledged the lack of a shared goal as the root cause — but couldn't fix it because he wasn't authorized to manage the external people. The takeaway was clear: three key success factors for any team are the right team composition with people who want to work together, a shared goal that unites diverse perspectives, and clear expectations set by their manager. In this segment, we talk about LeSS self-designing team workshops and the importance of team composition in scaled setups. Self-reflection Question: Does your team have a shared goal that everyone — including external members and contractors — genuinely understands and cares about? When was the last time you checked? Featured Book of the Week: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland Viktor recommends The Art of Doing Twice the Work in Half the Time by Jeff Sutherland as the book that sparked his passion for Scrum. As he puts it: "I know the title is very controversial and often criticized, but I could deeply relate to the stories inside the book. They sparked a passion that is still with me." Viktor also recommends a bonus book: Reinventing Organizations by Frederic Laloux, which showed him the real power of self-organization and validated what he had already started experimenting with in his project management career. It pushed him to explore holacracy, sociocracy, intent-based leadership, and coaching. [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 Viktor Glinka Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life. You can link with Viktor Glinka on LinkedIn.
-
151
When Passion Becomes the Problem — How Pushing for Agile Change Too Fast Creates Resistance | Viktor Glinka
Viktor Glinka: When Passion Becomes the Problem — How Pushing for Agile Change Too Fast Creates Resistance 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 wanted to change the organization overnight with my eagerness and passion. Instead of helping the system to evolve, I created resistance. I became the problem myself." - Viktor Glinka Viktor shares one of the most honest failure stories we've heard on the show. Early in his Scrum Master career, he joined a finance organization as a Scrum Master for a newly created department — his first experience in a scaled setup. Each team owned a particular part of the user journey, organized around components. After getting exposed to Large-Scale Scrum (LeSS) through a colleague, Viktor became overexcited. He started pushing for structural changes daily, telling the head of department that the current team composition was wrong and they needed cross-functional feature teams. But he was disconnected from reality. For this particular organization, even having partially cross-functional teams was already a big stretch. Worse, the head of department wasn't even authorized to make the changes Viktor was pushing for. Instead of helping the system evolve, he created resistance. What proved his approach wrong? That same department later received a European Award for being the best mortgage department. It took Viktor a few more years and similar cases to fully absorb the lesson: read the room, develop sensitivity to the system's pace, and stimulate reflection in decision makers rather than pushing your own agenda. In this episode, we refer to organizational development, LeSS (Large-Scale Scrum), and systems analysis. Viktor also mentions the interview with Bas Vodde on the Scrum Master Toolbox Podcast. Self-reflection Question: When was the last time you pushed for a change because you believed it was right, without checking whether the system was ready for it? What would happen if you started by asking decision makers what they think would be a good next step? [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 Viktor Glinka Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life. You can link with Viktor Glinka on LinkedIn.
We're indexing this podcast's transcripts for the first time — this can take a minute or two. We'll show results as soon as they're ready.
No matches for "" in this podcast's transcripts.
No topics indexed yet for this podcast.
Loading reviews...
ABOUT THIS SHOW
Every week day, Certified Scrum Master, Agile Coach and business consultant Vasco Duarte interviews Scrum Masters and Agile Coaches from all over the world to get you actionable advice, new tips and tricks, improve your craft as a Scrum Master with daily doses of inspiring conversations with Scrum Masters from the all over the world. Stay tuned for BONUS episodes when we interview Agile gurus and other thought leaders in the business space to bring you the Agile Business perspective you need to succeed as a Scrum Master. Some of the topics we discuss include: Agile Business, Agile Strategy, Retrospectives, Team motivation, Sprint Planning, Daily Scrum, Sprint Review, Backlog Refinement, Scaling Scrum, Lean Startup, Test Driven Development (TDD), Behavior Driven Development (BDD), Paper Prototyping, QA in Scrum, the role of agile managers, servant leadership, agile coaching, and more!
HOSTED BY
Vasco Duarte, Agile Coach, Certified Scrum Master, Certified Product Owner
CATEGORIES
Loading similar podcasts...