Scrum Master Toolbox Podcast: Agile storytelling from the trenches

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: <a style="text-decoration: none;" href="http://bit.ly/SMTP_ShowNote

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"

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 m

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 <a style="text-decoration: none;" href= "ht

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 thei

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 <p dir="ltr" style= "line-height: 1.38; margin-top: 0pt; margin-bottom:

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. <p dir="ltr" style= "line-height: 1.38;

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

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. <p dir="ltr" style= "line-height: 1.38; margin

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

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 t

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 com

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 creat

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, o

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 princip

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!🔥 <p dir="ltr" style= "line-height: 1.38; margin

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

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 beautif

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

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 Tool

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 befo

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 abou

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: T

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: <a style= "text-decoration: none;" href= "https://en.wikipe

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 n

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

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

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 <a style

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

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 depe

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. M

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 "

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 P

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

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

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

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 askin

BONUS: From 3,000 Scripts to 3 Tools - Building AI-Last Software With Conversational AI Pioneer Peter Swimm In this special BONUS episode, Peter Swimm—conversational AI veteran, creator of BotKit (the open-source chatbot framework that powered Slack and Teams bots), and former Principal Product Manager at Microsoft Copilot Studio—shares what 25+ years in tech taught him about working with AI. From his brutal experiment of running an entire business on voice-based AI for a week, to why he treats AI more like R2-D2 than C-3PO, Peter offers a grounded, practical perspective on where AI fits in software development teams. From BotKit to Copilot Studio: A Front-Row Seat to the AI Evolution "We had the number one bot in the Slack app store, because there were only 8 bots, and ours used regex. To show you how far we've come." Peter's journey into conversational AI started with a newspaper ad and a creative writing background. When Slack launched its API, Peter and BotKit co-creator Ben Brown immediately saw that building bots wasn't just a technical challenge—it was a social and creative one, like writing scripts for plays that interface with people in their daily lives. That insight powered BotKit into becoming the backbone of Slack and Teams bots, and eventually led to Microsoft acquiring the company. Peter spent years inside Microsoft shaping Copilot Studio, working on connectors that bridge the gap between APIs and real-world work. But the experience also gave him a healthy dose of perspective: he can show you slide decks from 2016 that promise the same things today's AI pitches promise, always saying "within 5 years." That pattern recognition shapes his practical, no-hype approach. The 3,000 Scripts Experiment: Why AI-Last Beats AI-First "At the end of the day, if I've been prompting all day, I should have a computer program that works offline, that works without a subscription. Otherwise, I didn't really make anything." Peter ran a week-long experiment trying to run his entire business using only voice-based conversational AI. The result: 3,000 generated scripts. After static code analysis, he discovered it was really only 5 programs made thousands of times—and those 5 programs were really just 2 or 3 core abilities. He deleted 36 gigabytes of generated code and kept 50 megabytes of what actually worked. This brutal compression led him to an "AI-last" philosophy: build reliable runtime software that works confidently in one click, then use AI only for exploration, connection-making, and creative riffing. The payoff is striking

Efe Gümüs: The People-Pleasing Product Owner and the PO Who Understood User Value — Two Sides of Product Ownership In this episode, we refer to the SPIDR slicing method. The Great Product Owner: The PO Who Understood User Value Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "If your product owner can phrase what the user wants to do — not what the button should look like — it is going to be a night and day difference." - Efe Gümüs Efe describes the great product owner as someone who creates focus and a clear product vision, so the team knows what they're building and why. The foundation is simple but powerful: describe what the user will be able to do, not what the interface should look like. Instead of specifying a red subscribe button with exact text in three languages, say "as a user, I want to subscribe to my favorite channel." That shift unlocks the team's ability to contribute design insights, architecture decisions, and user journey thinking — the kind of expertise no product owner could anticipate alone. Efe highlights the SPIDR slicing method as one of his favorite tools for breaking product backlog items into consumable pieces — by interface (iOS, Android, web), by data, by rules. When the PO frames work around user value and slices it effectively, the team delivers visible value in iterations, and sprint goals become meaningful. Without this, the team becomes a ticket delivery machine. Self-reflection Question: When you look at your product backlog right now, are items described in terms of what users can do — or in terms of what the interface should look like? The Bad Product Owner: The People-Pleasing PO Who Says Yes to Everything Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "If you are d

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

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

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

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

BONUS: Why a Distinguished Engineer Stopped Reading Code — Lights-Out Codebases and the End of the IC Philip Su has spent two decades at the highest levels of software engineering — Microsoft, Meta (where he reached Distinguished Engineer, IC9), OpenAI, and now building his own product solo with AI. In this episode, he makes a provocative case: the individual contributor role as we know it is over, code reviews are becoming a liability, and the best engineers are already managing AI agents instead of writing code themselves. From Amazon Warehouse Floors to OpenAI "Every day at work, I lifted six tons of packages with my arms. No one learned my name. And it was the structure — the ability to leave work behind when I clocked out — that pulled me out of a spiral." Philip's path through tech is anything but typical. After scaling Facebook's London engineering office from a dozen engineers to 500+, he stepped away from Big Tech entirely. During Peak 2021, he worked the floor at Amazon's flagship warehouse south of Seattle — 11-hour shifts, processing 15,000 packages a day. He documented the experience in his Peak Salvation podcast, exploring depression, the divide between the wealthy and the working class, and the maddening inefficiencies inside one of the world's largest employers. That experience reshaped how he thinks about work, systems, and what actually matters when you strip away titles and stock options. He later joined OpenAI as an individual contributor — going from leading hundreds of engineers to writing code again — before leaving to build Superphonic, an AI-powered podcast player. No More Code Reviews: The Lights-Out Codebase "We'll one day be scared, positively petrified, to use any mission-critical software known to have allowed human interference in its codebase." Philip borrows the concept of "lights-out" from data centers that run with zero human workers and applies it to codebases. A lights-out codebase is one where no human ever sees or edits the code. He's already built two apps this way — Tanya's Snowfield and OTD: On This Day — without looking at a single line of code from repository creation through production release. His argument is not just about efficiency. Code reviewers are becoming the bottleneck. The volume of AI-generated code i

Nate Amidon: The Leadership Void — What Happens When Product Owners Forget They're Part of the Scrum Team In this episode, we refer to Nate's previous BONUS episode on the brief-execute-debrief cycle and alignment. The Great Product Owner: The Team Player Who Leads From the Trenches 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 product owners are really part of the team. They attend all the ceremonies, they give their daily stand-up status, they're shoulder-to-shoulder in the trenches." - Nate Amidon For Nate, the best product owners he's worked with share one defining trait: they act like teammates, not managers. They show up to daily stand-ups and report on what they worked on, what they completed, and what they're blocked on — just like everyone else. They listen to ideas from the team without being dismissive, recognizing that engineers often know the user just as well as they do. They don't treat the product owner role as a position of authority over the team, but as a different function within the same unit. Nate draws from his military background: leadership is "care and feeding of the people." When product owners internalize that the team's success is their success — when they feel genuine allegiance to the people they work with — backlogs get better organized, priorities become clearer, and collaboration happens naturally. As Vasco adds, alignment is the real purpose behind Scrum ceremonies, and when POs are there, alignment follows. Self-reflection Question: As a product owner, do your team members see you as someone who is part of the team — or as someone the team works for? The Bad Product Owner: The Leadership Void That Creates Corporate Game of Thrones 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 eventually becomes a leaders

Nate Amidon: Why Scrum Master Success Means Owning the Entire Idea-to-Deployed Pipeline 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. "Success for a Scrum Master is maximizing value of the product through the organization. That's a full stop statement." - Nate Amidon Running a company of contract Scrum Masters gives Nate a unique perspective on what success actually looks like. For him, it comes down to one thing: are you increasing the value of the product through the system? Everything else is either a leading or lagging indicator. Practically, this means starting with the most fundamental question: why does your team exist? Nate suggests asking three team members separately what the team does and who they do it for — and checking whether the answers match. Once you have clarity on purpose, you can work with product and the organization to figure out how to measure whether you're getting closer. But here's where Nate pushes boundaries: he believes a Scrum Master's scope isn't limited to the Scrum team. If success is measured by value flowing through the system, then you have to take ownership of the entire idea-to-deployed pipeline — product prioritization, cross-team dependencies, QA processes, CI/CD, release schedules. You happen to work as a Scrum Master on a team, but your responsibility extends to anywhere value gets stuck. In this episode, we refer to Vasco's OTOG (One Team, One Goal) principle and Nate's previous episode about the brief-execute-debrief cycle. Self-reflection Question: If someone asked three different members of your team what the team exists to do and who they do it for, would the answers match — and have you checked recently? Featured Retrospective Format for the Week: Meme Retro Nate's favorite retrospective format might surprise you: the Meme Retro. Give everyone 5-10 minutes to find a meme on the internet that describes the last sprint. Then go around the room, share the meme, and explain why yo

Nate Amidon: The Hidden Cost of Distributed Agile Teams — When Time Zones and Misaligned Incentives Silently Kill Value Delivery 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. "User stories are getting done, velocity is fine, people are fairly predictable — but features, epics, and value isn't getting delivered." - Nate Amidon Since the COVID shift to remote work, Nate has been seeing the same challenge across multiple clients: organizations spinning up engineering teams in opposite time zones, shrinking the overlap window from eight hours to barely one or two. But the time zone gap is only the surface problem. The real issue runs deeper — misaligned incentives between internal teams focused on value delivery and third-party vendors measured on output metrics like story completion counts. On the surface, everything looks fine: stories get done, velocity is stable, predictability is there. But zoom out and you see that features, epics, and actual customer value aren't being delivered. Nate shares a striking example: offshore QA testers incentivized by the number of bugs they found were creating Russian-doll ticket structures — bugs within bugs within bugs — flooding the system with noise while adding no value. His approach starts with making everyone feel like they're on one team — cameras on, real conversations about who people are, what they like, where they live. Then he works to expose the constraint: how is each group actually measured and incentivized? You can't always change the enterprise contract, but you can mitigate. In the QA case, he got leadership to communicate directly with the vendor that the new, leaner process wouldn't penalize their people. Self-reflection Question: Do you know how every member of your team — including vendors and contractors — is measured and incentivized, and have you checked whether those incentives are aligned with the value your team is trying to deliver? [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 te

Nate Amidon: When the Blame Game Between Product and Engineering Destroys Your Scrum Team From the Inside 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 and engineering are in the same boat. We need to visualize and internalize that it's one team, one fight." - Nate Amidon Nate was working as a Scrum Master on a full-stack team building an internal mobile application when he noticed tension forming between product and engineering. It started small — finger-pointing about missed requirements — but quickly escalated into a full-blown blame game. The QA started siding with product, creating a product-and-QA-versus-engineers dynamic. Engineers began refusing user stories unless they were "100% baked" with every detail spelled out, turning the team into lawyers negotiating contracts rather than collaborators building software. What's revealing about this pattern is what it looks like from the outside: a project manager might see meticulously detailed user stories and think the team is doing great work. In reality, it's a symptom of broken trust. Nate points out that in high-performing teams, you actually see less detail in the issue tracker — because people are talking, aligned, and adapting together in real time. His approach? He drew stick figures in a boat on sticky notes — one labeled PO, the other Engineering — and stuck them on people's monitors. Simple, visual, and direct: you're in the same boat. Self-reflection Question: What are the smells you're noticing in your team's interactions — and could overly detailed user stories actually be masking a deeper trust problem between product and engineering? Featured Book of the Week: Deep Work by Cal Newport Nate recommends every Scrum Master read Deep Work, and here's why: "Shoulder taps are expensive. If you go and bother an engineer that's in the zone, in deep work, you're adding about a 15-minute reset for them to get back into that zone." For Nate, safeguarding engineers' time is one of the most important things a Scrum Master can do. He also recommends Project to Product by Mik Kersten for Scrum Masters moving into Agile coaching — especially its emphasis on team structure and why "the team needs to be sacrosanct,

Nate Amidon: When Overconfidence Breaks the Trust You Worked So Hard to Build 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 had built up the trust quotient, but then I didn't think about continually maintaining it." - Nate Amidon Nate had done everything right. As a junior Scrum Master on an internal software team, he started by building trust — showing up, listening, and letting the team know he wasn't going to make things worse. He even managed to shift their reporting metrics from velocity to predictability, a move the team embraced because it focused on what they could actually control: how well they broke down and executed their plan. But then came the overconfidence. Riding on the capital he'd built, Nate proactively designed a "sprint churn" metric to track how much work swapped in and out of a sprint. The idea wasn't bad — but he rolled it out without consulting the team first. The pushback hit hard. Engineers pushed back: adding more work mid-sprint shouldn't automatically be negative, they argued. And they were right. The real failure wasn't the metric itself — it was bypassing the collaborative process that had earned him trust in the first place. Nate learned that trust isn't something you build once and bank on. It's an everyday job. As he puts it, the Scrum Master's role is to help the team, not direct it — and the moment you start solving problems the team hasn't agreed exist, you're directing. In this episode, we also refer to Nate's previous BONUS episode on the podcast, where he discussed the brief-execute-debrief cycle from military aviation. Self-reflection Question: When was the last time you introduced a change to your team without first checking if they saw the same problem you did — and what happened to your trust quotient as a result? [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.

BONUS: Why Your Plan Is Lying to You — #NoEstimates, Throughput, and the Superstition of Project Management This episode is a cross-post from The EBFC Show, Felipe Engineer-Manriquez's podcast exploring Lean and Agile in construction. In this conversation, Felipe interviews Vasco about the #NoEstimates movement, throughput-based planning, and why traditional project management is still stuck in the middle ages of managing creative work. The Human Side of Scrum That the Scrum Guide Doesn't Cover "When you go into a daily meeting and you start looking at the people in that room, maybe they are the exact same people that were there yesterday, but the team is totally different. Somebody might have had a bad night's sleep, somebody might have had an argument with their spouse. These are human beings. These are not machines that you can just distribute work to." Vasco's path to agile coaching started with a realization that most practitioners eventually reach: the problems in software development aren't technological. They're about people — getting agreements, sharing information at the right time, making the collective brain of a team actually function. The Scrum Guide gives you organizing principles — how many meetings, who's in them — but it says almost nothing about the real-time feedback cycle between humans that makes or breaks a team. That's why the Scrum Master role exists: to be the lubricant for human interactions, to break down complex ideas into items the collective mind can process. It's the piece that makes Scrum work, and it's the piece that's hardest to teach. From Project Manager to #NoEstimates — The Bet That Changed Everything "The PM wanted 15 items per sprint, and the team said 'yeah, we can do 15.' I said, this is not gonna happen. The team had been delivering between five and eight items per sprint. I said, I'm gonna be positive — I'm gonna say seven. And no surprise, by the end of the sprint, they delivered seven." Vasco started as a project manager — and not the easy certification kind. He went through IPMA, which means six months of training, a four-hour written exam, and an expert interview, just for the entry level. Planning and estimating was the job. Then he ran his first Scrum project, specifically to prove it couldn't work. By the second month, he couldn't understand how anything else