Scrum Master Toolbox Podcast

BONUS: Your Developers Got 20x Faster — Now Watch Your Product Managers' Heads Explode Clarke Ching is "The Bottleneck Guy" — and he just spotted the bottleneck that AI is about to create in every software organization. It's not in the code. It's inside the heads of the people who decide what gets built. In this conversation, Vasco and Clarke unpack why speeding up developers with AI tools pushes the real constraint upstream — onto product managers, designers, and leaders — and what to do before cognitive overload crushes the people your organization depends on most. Every Business Has a Bottleneck — Most Are in the Wrong Place "Every single client I have is a detective puzzle. We're looking for this quiet killer sitting inside their business, siphoning off money. And if you look at them without the idea of going 'where's the bottleneck?' — you mistake the busyness for productivity."   Clarke approaches Theory of Constraints like a detective story, not a physics lecture. Every business has a bottleneck — the narrowest point that chokes throughput. The question isn't whether you have one, it's whether it's in the right place. In software development, Clarke argues, the bottleneck should almost always be the developers. Not because they're slow, but because they're the pacing resource — like the aircraft carrier in a naval fleet that sets the speed for everything else. When developers are the bottleneck, the people upstream (product managers, designers, architects) have time to curate high-quality, high-value inputs. The people downstream (testers, ops) can deliver fast feedback. Everything flows. But when the bottleneck drifts somewhere else — and nobody notices — everyone gets busy, nothing flows, and the organization mistakes that busyness for productivity. Clarke's latest book, The Speed Book, lays out how to find where your bottleneck actually is and move it to where it belongs. AI Just Moved the Bottleneck — And Nobody's Talking About It "Just imagine one person trying to feed 100 developers. It's ridiculous. Everyone goes, 'oh, that's just crazy.' But that's kind of going to be what it's like."   Here's the problem: AI coding tools — Claude Code, Cursor, Copilot — are making developers dramatically faster. If a team of 5 developers becomes 20x more productive, that's the equivalent of 100 developers. But you still have one product manager feeding them. The bottleneck hasn't disappeared — it's moved upstream. And when a bottleneck moves to the people who make product decisions, three things happen: they cut corners on requirements (shipping half-baked ideas because the team can turn them around fast), they feed developers busy work just to keep them occupied, and — worst of all — they lose the time needed to push through complexity to find elegance. Clarke references Steve Jobs's insight: Apple kept working past "peak complexity" until they reached "peak simplicity." That's where great products come from. But a product manager juggling work for 100 developers has no time for that journey. Elegance goes out the window. Why Giving AI to Product People Almost Makes Things Worse "If you want to wear your dog out so she sleeps, don't take her for long walks. Make the dog think. Brain games exhaust the dog faster than running."   The obvious fix — give product people AI tools too — sounds right but misses the point. AI can handle the easy parts of product work: drafting user stories, generating specs, compiling research. That's the equivalent of taking the dog for a run. But the hard parts — the deep thinking about what to build, why it matters, how features interact — that's brain work. And brain work is exhausting in a way that volume work is not. Clarke works with senior leaders whose biggest challenge is pacing themselves. Heavy cognitive lifting burns through energy fast — your brain consumes 30-40% of your body's glucose when you're thinking hard. When AI handles the easy work, the proportion of your day spent on exhausting brain work jumps from maybe 15-20% to 50% or more. It's like lifting weights for six hours straight. You don't get stronger — you break down. On top of that, product people go from coordinating one stream of work to juggling many simultaneous initiatives. Clarke calls these "idea grenades" — and when you're juggling chainsaws with grenades attached, you start dropping things. The Real Danger: Going in the Wrong Direction, 100x Faster "If you change the relative capacities and make some of them much, much faster, the bottleneck's gonna move. My next book, jokingly, is gonna be called 'Who Moved My Bottleneck?'"   There's an amplification effect that makes this worse than a simple throughput problem. An error in a line of code affects one line. An error in a design document ripples into hundreds of lines. An error at the strategic level — building the wrong features entirely — can be a disaster for the company. Now add AI speed to that equation. Overwhelmed product people making rushed decisions don't just slow things down — they point the entire organization in the wrong direction, and AI-powered developers execute that wrong direction at 20x speed. As Clarke puts it: you crash into the mountain, faster. The fundamental Theory of Constraints insight applies: if you speed up a non-bottleneck resource, you don't speed up the system. You just create more work-in-progress, more chaos, and more cognitive load for whoever the real bottleneck is. Four Experiments to Try Before Cognitive Crush Hits Your Team "Quality will come from actually slowing down. Money, profits will come from slowing down, building very good products, focusing on why we're building these products, not just how do we keep the AIs working."   Clarke offers four practical experiments for teams navigating this shift:   Get product people working with AI — as a thought partner, not a turbo boost. Teach them to delegate the routine work to AI so they can protect their cognitive energy for the decisions that actually matter. Think of AI as a delegation tool, not a productivity multiplier. Help product people find their sustainable pace. Like Clarke's gym trainer who said "don't come five days a week or you'll never come back" — the people doing heavy cognitive lifting need to pace themselves. Old-school agile called this sustainable pace. It's never been more relevant. Don't try to keep developers (or AI) busy all the time. The instinct to maximize utilization is the instinct that creates the problem. With AI, you're renting capacity by the minute, not paying salaries. Use it at the pace of good product thinking, not at maximum throughput. Turn the tap on and off as needed. Measure what matters: value delivered, not stories completed. If 60-70% of features rarely get used today, imagine what happens when you 20x the feature output without improving the decision quality upstream. More features, more waste — at scale. About Clarke Ching Clarke Ching is "The Bottleneck Guy" — a Theory of Constraints and lean expert who wrote Rolling Rocks Downhill, the agile+lean business novel that never mentions agile, and The Bottleneck Rules. Born in New Zealand, he spent 20 years abroad (15 of them in Scotland) before returning home. He's spent decades helping teams find and manage the one constraint that controls everything else. LinkedIn   You can link with Clarke Ching on LinkedIn.  

Mukhtar Kadiri: The Three Qualities That Separate Great Product Owners From Those Who Just Drop Tickets The Great Product Owner: Decisive, Versatile, and Credible at Every Level Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "This person could hold his own at any level of the organization — with executives, with engineering leadership, and with the team." - Mukhtar Kadiri   Mukhtar describes the best product owner he ever worked with through three distinct qualities. First, this person could operate at any level — equally comfortable in a strategic conversation with executives and in a tactical session with the engineering team. Second, they had vast cross-functional knowledge. They weren't a specialist in any one domain, but they could hold intelligent, credible conversations with marketing, go-to-market, customer success, and engineering alike. And third — perhaps most critically — they were decisive. In ambiguous environments where nobody has done this before, teams need someone who will pick a direction and say "let's find out," even if the decision might be wrong. That decisiveness, combined with the ability to course-correct early, is what separates great product owners from those who leave teams waiting for direction that never comes.   Self-reflection Question: Which of these three qualities — operating at any level, cross-functional credibility, or decisiveness — is strongest in your product owner, and which one needs the most development? The Bad Product Owner: Not Owning the Backlog Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If you don't have a strong product person, engineering just takes over the backlog. And that is dangerous, because it's product that is the representative of the customers." - Mukhtar Kadiri   Mukhtar has seen it happen repeatedly: when a product owner doesn't truly own the backlog, a strong engineering lead steps in and takes over prioritization by default. Things still get built — often beautiful, technically elegant solutions — but they don't produce business value because engineering lacks the customer intimacy that product should bring. The fix isn't simple, but Mukhtar identifies three levers. First, mentorship — pairing a junior product person with a more senior one to build confidence and skills. Second, building technical literacy — a product owner who can't meet engineering halfway will always be seen as an outsider dropping tickets. And third, closing the relationship gap between product and engineering. As Mukhtar points out, a product owner is technically a part of the team, but if the team doesn't feel like they're a part of the team, that gap becomes a chasm. There needs to be real overlap between engineering and product — not just shared meetings, but shared understanding.   Self-reflection Question: Is your product owner truly a member of the team — or are they just someone who shows up to drop tickets and disappear until the next sprint planning?   [The Scrum Master Toolbox Podcast Recommends]

Mukhtar Kadiri: Why Success Means Nothing If the Project Doesn't Move the Business Forward — And How Public Commitments Keep You Honest Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "If you're not careful with success, you can deliver a project, but the project will really not do much for the business." - Mukhtar Kadiri   For Mukhtar, success is personal — he's the kind of project leader who gets emotionally invested, who thinks about the project after hours, who needs recovery time between engagements. And that emotional investment shapes how he defines success: not as hitting deadlines or completing tasks, but as delivering real business value. He breaks success metrics into three buckets using his signature rule of three: business and product metrics (NPS, revenue, market penetration), project management metrics (velocity, burn-down, risk scores), and software and system metrics (availability, transactions per second, platform health). But the real insight is in how he holds himself accountable. Mukhtar makes public commitments at the start of every project — "Expect status updates from me every week" — because he knows that the discipline of narrating the project's story every week forces him to truly understand what's happening. A status report isn't bureaucratic busywork when you approach it as storytelling: you have to make sense of the data, surface what's relevant, and articulate where the project actually stands. If you can't tell the story, something's missing from your understanding. That weekly narrative becomes both an accountability mechanism and an early warning system.   Self-reflection Question: Can you tell the story of your project right now — not just the tasks completed, but the narrative of where it stands, why, and what that means for the business? Featured Retrospective Format for the Week: What Worked / What Didn't Work / Next Steps Mukhtar is a firm believer in simplicity, and his favorite retrospective format reflects that — the classic "What worked, what didn't work, and next steps." He applies his rule of three here as well: three categories are easy for humans to hold in their heads, removing cognitive overhead so the team can focus on the conversation itself. But Mukhtar is quick to point out that a simple structure can still produce terrible retrospectives. What matters more is the facilitation: making sure people feel safe at the very start, level-setting so participants can "land" into the retrospective after jumping from another meeting, giving everyone a moment of quiet introspection to write things down before discussion begins — ensuring both quiet and loud voices are heard. He prepares for every retrospective because, as he puts it, "if you run a bad retro, you could do damage to your team morale and your project." Active facilitation — watching for who isn't speaking, encouraging quieter voices, managing tone — is what transforms a simple format into a powerful conversation.   [The Scrum Master Toolbox Podcast Recommends]

Mukhtar Kadiri: Merging Three Companies Into One Platform — When Founders Can't Let Go and Leaders Won't Decide Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "A lot of times, conflict arises because people don't understand each other. The first thing you need to do is make sure they understand each other." - Mukhtar Kadiri   Mukhtar brings us a challenge from a merger and acquisition program where a dominant software company acquired two competitors simultaneously — both solving the same market gap, each with their own platform, their own founders still in place, and their own fierce loyalties. The mission: merge three platforms into one. But the technical challenge was the easy part. The real complexity was human — founders who'd built their companies from scratch watching their babies potentially get retired, teams losing people to low morale and uncertainty, and leadership paralyzed by the knowledge that every decision would make somebody unhappy. Together, Mukhtar and Vasco explore a four-step approach to navigating these high-stakes disagreements: first, create a feeling of time abundance — never rush a decision that requires buy-in. Second, get each side to present their perspective with only clarifying questions, no judgment. Third, name the disagreement explicitly — turn emotions into concrete, debatable statements. And fourth, co-create an alternative solution that doesn't come from either original position, because co-creation builds commitment. Mukhtar adds a critical fifth element: steel-manning — having each side articulate the other's argument as if defending it. When people feel genuinely understood, even "disagree and commit" becomes possible.   In this episode, we refer to steel-manning and the concept of disagree and commit.   Self-reflection Question: When you're facilitating a disagreement between two strong positions, do you rush toward a decision — or do you invest the time to make sure both sides can articulate each other's argument before you even think about next steps?   [The Scrum Master Toolbox Podcast Recommends]

Mukhtar Kadiri: When the Smartest Person on the Team Becomes the Biggest Bottleneck — And Explodes in a Meeting Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "A lot of times, the problem is not necessarily technical. It's a human problem. Just figuring out the human dynamics removes the obstacles and makes the project flow." - Mukhtar Kadiri   Mukhtar was brought into a healthcare software project where the team couldn't hit any of their milestones. The product manager, engineering team, and head of engineering were supposed to be self-sustaining, but chaos reigned. What Mukhtar found through his one-on-ones was a pattern of finger-pointing — product blaming engineering, engineering blaming product. Then, in one meeting, the head of engineering exploded. He burst out yelling in front of the entire team. In a private conversation afterward, Mukhtar discovered the root cause: this brilliant architect was a bottleneck. Everyone depended on him, he was stretched across multiple projects, and the frustration had been building with no outlet. Mukhtar's approach was direct — "Your name is on this project. Yelling is not going to help." But the real insight came from what happened next. Once the head of engineering started controlling his outbursts, team morale improved almost immediately. Combined with basic structure — regular meetings, low-hanging-fruit milestones — the team built momentum and eventually became self-sufficient. The lesson? No matter how technical the challenge looks, it's always a people problem. And one-on-ones aren't just status updates — they're pressure valves that prevent public explosions that can cause irreparable damage to team morale.   Self-reflection Question: Is there someone on your team who's carrying too much load in silence — and what would it take for you to create a safe space where they can express that frustration before it boils over? Featured Book of the Week: HBR Project Management Handbook by Antonio Nieto-Rodriguez Mukhtar recommends the HBR Project Management Handbook because, as he puts it, "A lot of project management books, I can read them and it's almost like I'm not really learning anything new. But this one had substance." After stumbling into project management and leading projects for seven years before even pursuing his PMP, Mukhtar found that most PM books simply codified what he already knew from experience. The HBR handbook was different — it offered breadth, depth, and fresh approaches to common project management challenges. He also recommends the Rita Mulcahy PMP Exam Prep for those preparing for PMP certification, noting that studying for the exam crystallized frameworks around things he had been doing instinctively.   [The Scrum Master Toolbox Podcast Recommends]

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]

Peter Merel: From Desk-Pounding to Harmony — How the Game of Go Transformed a Violent Product Owner, and Why Every Employee Should Think Like an Owner In this episode, we refer to The Agile Way by Peter Merel and The Great Game of Business by Jack Stack. The Great Product Owner: The Real Estate Visionary Who Built Channels of Learning Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "When a product owner brings an attitude of learning together, it doesn't just create psychological safety — it creates an active experimental mindset and a network of trust relationships that support each other in the learning process." - Peter Merel   The best product owner Peter has worked with is Ben White, one of three brothers and partners in Ray White — Australia's largest property management business, started by Ben's great-grandfather. Ben had a vision for transforming how property management works across the entire Australian industry. To realize this vision, he tried to bring an app to market — and failed. Not once, but twice, before succeeding on the third attempt. What made Ben exceptional wasn't his persistence alone, but that each failure became an opportunity to learn how to approach the problem differently. The product he finally brought to market was informed by all of that learning. Ben's real genius, Peter explains, is his ability to establish channels of learning — trust relationships that flow not just through the technical team, but throughout the entire business and back into product development. Without those trust relationships, psychological safety alone isn't enough. Peter also emphasizes that the product owner should be a servant leader, and points to Jack Stack's open book management model where every employee is motivated to think and act as a business owner. When everyone understands that the future of the business is their future, they all collaborate as product owners — and the need for desk-pounding disappears entirely.   Self-reflection Question: How many channels of learning does your product owner currently have — and are there trust relationships in the organization that could become active channels but haven't been tapped yet? The Bad Product Owner: The Violent Visionary Who Didn't Understand Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The problem isn't the role of product owner. The problem is the relationship between product owner and everybody else." - Peter Merel   At Commonwealth Bank of Australia, Peter worked with a business executive who drove the development of a digital product that generated $2 billion in business for the bank. By any business measure, this person was extraordinarily successful. But as a product owner, he was terrible. He pounded desks, went red in the face, insisted that everything the team was doing was wrong, didn't trust anyone, and couldn't be trusted either. The core anti-pattern wasn't the shouting itself — it was that this person didn't understand what a collaborative relationship needed to be. Peter found a creative solution: he taught the executive the game of Go. Go rewards harmony — you lose by being too passive, and you lose by being too aggressive. Through Go, Peter taught the executive to create prompting questions, to work through others so they would carry concerns into meetings, and to provide answers rather than demands. Once the executive saw that collaboration was a more effective way to realize his own vision — faster, better, and more reliably — the behavior changed completely. The insight Peter shares is that before coaching behavior, you sometimes have to prove the business case for collaboration itself.   In this segment, we refer to The Agile Way by Peter Merel, which Peter now gives to product owners as a framework for understanding collaborative relationships.   Self-reflection Question: When you encounter a product owner who leads through demands rather than collaboration, have you considered showing them that collaboration is actually a faster path to getting what they want?   [The Scrum Master Toolbox Podcast Recommends]

Peter Merel: Leadership as a Service — Why Scrum Masters Should Work Themselves Out of a Job and How Quality Circles Make Learning Flow Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "A Scrum Master is a self-defeating role. If you have worked yourself out of a job, then you've succeeded." - Peter Merel   Peter Merel challenges the very notion of the Scrum Master as a permanent organizational role. He argues that calling someone a "master" makes everyone else a servant — the opposite of what agile teams need. Instead, Peter advocates for leadership as a service, where every team member provides leadership to their team and every member of a swarm provides leadership to their swarm. He points to the Haudenosaunee Confederacy — the successful direct democratic republic that existed in North America before the USA, and which influenced the American founding fathers — as a model for distributed leadership. The protocol is simple enough to apply universally, regardless of organizational structure. Peter's practical approach to success measurement is equally compelling: build a thin steel thread of alignment, prove it works in 8 to 12 weeks, then split it and backfill with the most progressive people in the organization. He describes growing a group of 300 in just 9 months using this approach. The key insight is that coaches should not think of themselves as change agents, but rather as people who transform change participants into change leaders. Once a team can self-organize without you, your job is to move on to the next challenge — and that's what success looks like.   In this episode, we refer to the concept of leadership as a service and the XScale Alliance.   Self-reflection Question: If you stepped away from your team tomorrow, could they self-organize effectively — and if not, what's the one thing you could teach them this week that would bring them closer to not needing you? Featured Retrospective Format for the Week: Quality Circles Peter Merel recommends quality circles as a cross-team retrospective format drawn from the Toyota Production System. The concept is simple but powerful: take three teams of six people and break them into six quality circles of three — one person from each team in each circle. These circles meet regularly for 10 to 30 minutes, ideally before team planning sessions, to share problems, ideas, and ways they can help each other. The magic of three people is that while one person explains, another listens, and the third is already thinking about where the conversation goes next — creating what Peter calls "a beautiful hum." Each circle brings two kinds of ideas back to their team: proposals for work that would benefit the teams as a whole, and treaties — working agreements between teams. The teams remain autonomous and can decide how to respond. Peter emphasizes that this approach scales naturally — representatives from groups of teams can form quality circles at higher levels, keeping face-to-face communication alive across entire organizations. As Peter puts it, "Learnings flow across the organization — and that's more valuable than anything you can come up with in a retrospective by yourself."   [The Scrum Master Toolbox Podcast Recommends]

Peter Merel: AI Alignment Is the Agile Coach's Next Frontier — Using Throughput Accounting and Pull-Based Transformation to Prove Value Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Our jobs ARE about alignment. Alignment is how do we get all of the people and all of the tools to work together for mutual benefit." - Peter Merel   Peter Merel brings a provocative perspective on the biggest challenge facing agile professionals today: AI and agile alignment. With AI rapidly advancing, Peter observes that everyone in the agile community is afraid for their jobs — but argues this fear is misplaced. The real challenge isn't replacement; it's alignment. How do we get biological and electronic entities to work together for mutual benefit? Peter's answer begins with pull-based transformation — building a thin steel thread from business through to DevOps, proving it works with a small group, then growing it. He connects this to Goldratt's throughput accounting, arguing that throughput (operating expense plus net profit) is the only metric immune to Goodhart's Law. From throughput, Peter derives three flows: value flow (throughput itself), workflow (the first derivative — what increases value flow), and learning flow (the second derivative — what improves workflow). He then introduces the pirate metrics (AARRR) — acquisition, activation, retention, referral, and revenue — as market constraints that can be analyzed through Theory of Constraints. Peter's frustration is that 25 years after Agile began, most business stakeholders still can't identify their market bottleneck. Without that knowledge, he argues, priorities are meaningless. The path forward for agile coaches? Bring scientific rigor to transformation, measure what matters, and prove value before scaling.   In this episode, we refer to FAST Agile, Joe Justice's work with Tesla and WikiSpeed, and the connection between throughput accounting and agile transformation metrics.   Self-reflection Question: Can you identify the single biggest market constraint limiting your organization's throughput right now — and if not, how confident are you that your current priorities are the right ones?   [The Scrum Master Toolbox Podcast Recommends]

Peter Merel: When a Hub-and-Spoke Executive Hijacks Your Agile Transformation — And What to Do About It Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Either you're going to do what you know works, or you're going to step away. Either way, you're not going to do damage to your client." - Peter Merel   After a successful transformation at Commonwealth Bank of Australia, Peter Merel moved to Westpac, another major Australian bank, expecting to replicate the same approach. He found an executive who appeared eager to support an agile transformation — but this executive saw agile as the ideal form of micromanagement. Everything and everyone revolved around this one individual, and as Peter began facilitating conversations that didn't hub on the executive, the executive felt disempowered. Peter was blind to this dynamic — he had never encountered it before. The situation deteriorated because Peter had been hired to run a push-based transformation, when he knew from experience that only pull-based transformation works. At Commonwealth Bank, he had built a thin steel thread from business through to DevOps with a small group, proved it worked, and then grown it organically. At Westpac, he let himself be persuaded to push change into the organization, and it compromised everything. The lesson Peter shares is stark: if you can't do what you know works, and you can't step away, then you are the problem. He also warns that when coaches fail this way, they make life harder for whoever comes next — a responsibility that's easy to overlook in the moment.   In this segment, we talk about pull-based transformation and why push-based change programs consistently fail in large organizations.   Self-reflection Question: Are you currently in a situation where you've compromised on your approach to change — and if so, are you doing more damage by staying than you would by stepping away? Featured Book of the Week: The Agile Way by Peter Merel Peter's own book, The Agile Way, is his modern translation of the Tao Te Ching — a 3,000-year-old text he argues was originally about how to achieve agile development in organizations large and small. Peter first started translating this text in 1989, and after decades of iteration, the book draws connections between ancient wisdom and modern agile practices — XP, Lean, Theory of Constraints, throughput accounting, and permaculture. As Peter explains, "The sage in Lao Tzu is Shang Ren — agile people. This is a book about agile people, agility, and it always was." The book is available at agile.way.pm, and Kent Beck, who wrote the foreword, calls it "a dangerous little book" — dangerous in the same sense as the word extreme.   [The Scrum Master Toolbox Podcast Recommends]

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]

BONUS: Why Your Agile Transformation Keeps Snapping Back — And What Systems Thinking Says About It Natalia Curusi co-authored a book that doesn't tell you what agile should look like — it tells you what actually happens when you try to transform an organization. Friday-night deployments, zombie teams going through the motions, transformations that met a wall of silence. In this episode, we unpack the real lessons from the front lines: how personal values drive the shift to agile, why some teams have all the ceremonies but none of the substance, and what systems thinking reveals about why transformations fail — or snap back. When Your Values Don't Match Your Ways of Working "I felt like there is a mismatch in my values, my moral values and principles, and customer-centric orientation. So when I found out about Agile around 2010, I understood — okay, this is the answer. Now I have the answer how I can map my moral values and principles with software delivery."   Natalia's journey to agile didn't start with a methodology — it started with a gut feeling that something was wrong. Working in large corporations in the early 2000s with fixed-scope contracts, late deployments, and scripts running directly in production, she sensed a disconnect between how work was done and how it should be done. When she moved to a smaller company around 2010 and experienced transparency, collaboration, and the freedom to ask any question without fear, she realized this was the agile mindset — even before she knew the term. The key insight: agile isn't something you adopt, it's something that aligns with values you may already hold. That alignment between personal principles and ways of working is what makes the difference between going through the motions and genuinely transforming how a team operates. Don't Be an Agile Zombie "The first thing I observe — if I go to some of the ceremonies and I see that stand-up becomes like a status meeting, and everybody is reporting to somebody. People are afraid to say some of the things, afraid to escalate risks or assumptions."   One of the strongest chapters in the book is titled "Don't Be an Agile Zombie." Natalia describes teams that have all the boards, all the roles, all the right meeting cadences — but nothing is actually changing. The Scrum Master becomes a secretary. The Product Owner is a proxy afraid to make decisions. The tell-tale signs? Fear and formality. When people report upward instead of collaborating sideways, when risks go unspoken because the environment punishes transparency, that's a watermelon project — green on the outside, red on the inside. Natalia's approach starts with observing the tone and dynamics in ceremonies. If the stand-up feels like a status report and not a coordination meeting, something deeper is broken. And her advice is direct: if an organization is delivering waterfall and happy with the predictability and value, that's fine — just call it what it is. Don't put lipstick on a pig. As Rebecca Homkes discussed on this podcast, the key is to communicate the truth with care, but communicate it nonetheless. Task-Driven vs. Value-Driven: The Real Spectrum "It's not right to say that you are agile if you are not. Just name the things how they are — name the things using the right word."   Rather than the old waterfall-vs-agile binary, a more useful lens is the spectrum between task-driven and value-driven product development. On the task-driven side, somebody creates the list of tasks — requirements, architecture document, design document — and a project manager distributes them. Teams execute but aren't asked to be creative or adaptable. On the value-driven side, what matters is the impact of what teams build. Value is discovered through the dynamic interaction of functionality with customers — it can't be predetermined. Most organizations sit somewhere on this spectrum, and many are slowly moving toward the value-driven end even if they don't call it agile. The practical takeaway: transformation should be tailored to where an organization actually is, not where a framework says it should be. The book argues for a pragmatic, hybrid approach rather than evangelical purity. Systems Thinking: Why Transformations Snap Back "We did a big agile transformation — five years of real transformation. Then the company was bought, merged with a bigger payment provider. And now they are working with SAFe. And that's the end of the story."   In the later part of the book, Natalia and her co-author move into systems thinking — Cynefin, the Iceberg Model, causal loop diagrams. Many agile practitioners stop before they get here because it feels academic. But Natalia argues it's essential, and she illustrates why with a real example: a payment company that went through five years of successful agile transformation using LeSS, only to be acquired by a larger organization that pushed SAFe — and the transformation snapped back. This is the basin of attraction concept: a system has to pass through a point of genuine disruption before it can settle into a new stable state. Without that, it returns to where it was. For practitioners looking to get started with systems thinking, Natalia recommends The Fifth Discipline by Peter Senge and learning to build causal loop diagrams — a practical tool that creates productive conversations about how organizational dynamics actually work. The Post-Agile Era: Beyond Labels "It's like comparing apples and orchestras. You cannot compare agile and AI — they are completely different things. Agile is not enough, but it's also not dead."   Natalia addresses the "Agile is dead" debate head-on. Her argument: comparing agile to AI is a category error. An apple cannot play an orchestra, and an orchestra cannot replace an apple — they serve entirely different purposes. AI can handle a significant portion of day-to-day tasks, but it lacks common sense, empathy, and the ability to read a room. Rather than declaring agile dead, Natalia sees a post-agile era — not one where agile disappears, but where we move beyond the label wars. The trends that matter aren't about whether agile is popular; they're about collaboration, adaptability, and understanding how teams and organizations actually work. We can finally talk about what matters in our industry without being pressured to label it. About Natalia Curusi Natalia Curusi is an Agile Coach at Endava with over 20 years in software delivery, specializing in agile transformations, delivery optimization, and systems thinking. She leads Asia Pacific initiatives driving business agility. She is co-author of From Resistance to Resilience: Practical Agile Lessons for Transformation.   You can link with Natalia Curusi on LinkedIn and visit her website at nataliacurusi.com. You can also join the Agile Continuum community on LinkedIn.

BONUS: Hard Hats and Standups — Why the Construction Industry Is Going Agile at GAS26 Felipe Engineer-Manriquez is one of the co-hosts of the Agile in Construction track at the Global Agile Summit 2026. In this preview episode, he and Vasco talk about why Agile belongs on the construction site, what the track's speakers discovered when they stopped following the plan, and why software people should pay close attention to an industry that builds hospitals, not apps. Construction Is 20 Years Behind — And That's the Opportunity "People don't realize that those ideas absolutely work in other industries. Agile's been successfully applied everywhere, and I think where it gets the least amount of publicity is in the construction sector."   When most people hear "Agile," they think standups in a tech office, not concrete and rebar. Felipe wants to change that. Construction, he says, is always about 20 years behind whatever process or technology the rest of the world adopts — a "very safe stock of keeping tradition." That gap is exactly what makes this track valuable. Agile is alive and growing in construction, and the translation turns out to be simpler than you'd expect. Most of what needs to change isn't the framework — it's the vocabulary. The sessions in this track show how practitioners made that jump with surprisingly small tweaks. The Speakers Don't Know How Good They Are "Half the speakers that I asked were like, 'what, me? Do I have a story to share?' I was like, yeah, you have this really amazing... people just don't realize how awesome they are."   One of the things that struck Felipe while assembling the track was how humble the speakers are. People who have transformed how their companies deliver work — including the keynote speaker, Brian, whose organization celebrated 10 years and saw dramatic before-and-after results — genuinely didn't think their stories were remarkable. They grew up in an industry with 100 years of project management tradition, where PMI-style thinking is the water they swim in. They don't see how different things look from the outside. Some of these practitioners couldn't even work across projects before adopting Agile — and now they're doing it routinely. That capacity shift alone is a data point worth paying attention to. Stop Following the Plan — Start Responding to Change "It's just ground into you, that thou shalt follow a plan. But in reality... they have to do heroic things to make those plans happen. Because the plans are just wrong."   Felipe zeroed in on the Agile value of responding to change over following a plan as the single biggest shift his speakers experienced. In construction, plan adherence is gospel — you follow the schedule, period. But in practice, teams were performing heroics just to make flawed plans appear to work. As speakers adopted Agile, they stopped forcing broken plans and started adapting. Felipe gives a nod to #NoEstimates — calling Vasco "the granddaddy of #NoEstimates" — as part of the same insight: the plans are wrong, and the sooner you accept that, the sooner you can respond to what's actually happening. The second pattern was equally powerful: for the first time, construction workers started thinking about who actually uses what they build. You'd think building a school or hospital makes the end user obvious, but Felipe says people in the industry can work for years and never once consider who receives their work. Agile forced that question, and the answers changed how they prioritize. What Software People Should Steal From Construction "Inside of every process are people. Everyone faces resistance to change... when I stopped trying to teach people, and I started inviting people, things changed."   Here's the cross-industry lesson Felipe wants software practitioners to hear: resistance to change is universal, and the breakthrough is the same everywhere. Every speaker in the track had a moment where they learned something new and didn't want to go back to the old way. That's the same moment every Scrum Master, product owner, and developer has lived through. The universal tactic that worked? Showing rather than telling. Case study after case study revealed that the real breakthroughs came not from training sessions or slide decks, but from demonstrating results and inviting people in. Stop teaching, start inviting — that's a principle that works whether you're pouring concrete or shipping code. Come Monday, You'll Ask Better Questions "The best thing you're gonna do on Monday after the summit is you're gonna start to ask really intelligent questions. That is gonna be priceless. That's something that AI doesn't even do for people."   Felipe's take on what attendees will walk away with isn't a new framework or a certification. It's a shift in the questions they ask. Twenty years into practicing Lean Construction, Agile, and Scrum, Felipe says asking better questions is the one thing that has stuck with him the entire time. Better questions melt away resistance, open up new perspectives, and make new ways of working accessible. The ideas in the track are, in his words, "not terribly complicated — they're actually quite simple, and I would even say elegant." And the speakers are approachable — Felipe personally vouches that every speaker in his track answers emails. There will also be live Q&A sessions during the summit for direct interaction. When Your AI Agent Tells You to Build a Website, You Listen "My chief orchestrator said, you should have your own website. So felipe.engineer was built."   In a delightful closing moment, Felipe shared that his personal website at felipe.engineer was built by his AI agent. Not suggested and then hand-coded — fully built, complete with a style guide the agent had strategically created two weeks earlier. Felipe jokes that the AI was setting him up: first planting the seed that he needed a style guide, then recommending it be applied to a brand-new personal site. Felipe also has a session in the track about building an AI bot for construction sites — another reason to check out the full lineup at globalagilesummit.com. About Felipe Engineer-Manriquez Felipe Engineer-Manriquez is a best-selling author, international speaker, and host of The EBFC Show. A force in Lean and Agile, he helps teams build faster with less effort. Felipe trains and coaches changemakers worldwide — and wrote Construction Scrum to make work easier, better, and faster for everyone.   You can link with Felipe Engineer-Manriquez on LinkedIn.   You can also find Felipe at thefelipe.bio.link, check out The EBFC Show podcast, and join the EBFC Scrum Community of Practice.

BONUS: The Game Industry Is Ending — And Why That Might Be the Best Thing for Agile Teams In this BONUS episode, we preview the Agile in Gaming track at the Global Agile Summit 2026 with track host Eagan Rackley. Eagan shares how he curated a lineup of speakers that spans indie studios, AI-driven game platforms, and multi-studio leadership — all focused on the human side of game development during one of the industry's most turbulent periods. If you've ever wondered what Agile looks like when artists, designers, sound engineers, and programmers all need to ship together under pressure, this is the episode. From Agile Coach Client to Track Host "You helped me recognize strengths I'd been dismissing in myself as a leader that I could turn the volume up on, and helped turn me on to some of my more people-first instincts into actual leadership accents."   Eagan's path to hosting the Agile in Gaming track started when he worked with Vasco at Malwarebytes in the early 2020s. That coaching relationship shifted how he thought about leadership — moving from dismissing his people-first instincts to leaning into them. When the Global Agile Summit opened up volunteer spots in 2025, he jumped in and co-hosted the development track. Game dev speakers drew strong audience engagement, and when the team suggested a dedicated gaming track for 2026, it was an easy yes. For Eagan, hosting is not just about giving — it is about learning from peers in an industry he transitioned into and loves deeply. Why Agile in Gaming Deserves Its Own Track "A lot of the problems we solve in gaming are the same problems people are solving in Agile everywhere, just with a different space. But also, Agile is very specific in gaming — even something like storyboarding is functionally different because you're describing a car in a city that makes these sounds, that drives with physics in this way."   Gaming sits at a unique intersection of disciplines — art, sound, design, engineering, narrative — all collaborating under tight constraints. Agile shows up differently here. The frameworks are similar, but the mechanics of how multidisciplinary teams coordinate are distinct. At gaming conferences, you rarely hear people talk about agility the way the Agile community does, and at Agile conferences, gaming is almost never represented. Eagan saw that gap and built a track to bridge it. The problems — building trust under pressure, introducing change to skeptical teams, managing cross-discipline dependencies — are universal. The context just makes them more vivid. The Producer Who Hates Agile but Runs an Agile Shop "He doesn't like Agile at all. He runs a really humanist-centered version of waterfall that can pivot quickly, which my argument is it's fairly agile, but it's not something he believes in — but it's also one of the most agile places I've ever worked."   One of Eagan's most striking observations comes from his current studio, led by an executive producer named Chris Whiteside. Chris explicitly rejects Agile as a label — likely burned by past implementations where someone tried to install a framework rather than nurture a mindset. Yet the way he runs teams is deeply human-centered, responsive, and adaptive. It is a useful reminder that the label matters far less than the behavior, and that some of the most agile organizations don't call themselves agile at all. The pattern Eagan has seen across studios mirrors what happens everywhere: framework-only installations that generate resistance, versus environments where the mindset develops organically. Accessible Excellence: The Skateboard Video Philosophy "I wanted to create a track that felt like accessible excellence. Just pushing beyond right where we were, but you could watch these talks and say, I could do that, that could be me. On Monday morning, I want to go in and try to be that person a little more."   When selecting speakers, Eagan drew on an unlikely reference point: a 1990s skateboard video called Zero Hero by a company called Zoroac. The skaters were not doing impossible three-story drops — they were doing moves that felt just one or two steps beyond what you could already do. That is the energy Eagan wanted for the track. Not aspirational keynotes from unreachable experts, but stories from people whose work makes you think: I could try that on Monday. He deliberately chose speakers across a range of experience levels and industry positions to hit that sweet spot. The Speakers and What to Expect "I want this track to be the answer to the question of whether it's worth it to stay in the industry and keep going — with some evidence that there are people out there doing this work thoughtfully, doing it well, and finding ways to remain human."   The track features a deliberately diverse lineup. Clinton Keith delivers the keynote, titled "The Game Industry As We Know It Is Ending — And the Future Could Be Much Better," which examines why the old AAA model is failing and where the industry is heading. Umar Ajaz focuses on building Agile into indie studios from the ground up — a timely topic as the industry shifts toward smaller, more agile teams. Kat Antonovich brings a social work background to team dynamics and change management, and Eagan intentionally sought an associate-level speaker because junior professionals have been disproportionately hit by industry layoffs. Marcos Jordt presents on Bitmagic, a fully AI-driven game development platform, along with his experience setting up Agile in Finland. And Kari Koivistoinen addresses the macro level: how to run multiple studios while preventing crunch and keeping team environments healthy. Who Should Register "These are the same problems everyone is solving in Agile. How do you build trust on teams under pressure? Introducing change when people are resistant or skeptical. Those show up everywhere."   This track is for curious people — whether they work in gaming or not. If you are interested in how teams solve problems with creativity and constraints, how multidisciplinary collaboration actually works (or breaks down), and what happens when an industry goes through a genuine transformation, there is something here for you. The goal is not prescriptive solutions. It is about getting down to fundamentals: what makes people do their best work and what makes teams function well. For people already in the gaming industry, Eagan designed this track to be the answer to the question many are asking after years of layoffs, studio closures, and canceled projects — is it still worth it? The track says yes, and backs it up with evidence. About Eagan Rackley Eagan Rackley is the track host for the Agile in Gaming track at the Global Agile Summit and a seasoned software engineer and Agile leader with 24+ years of experience spanning game development, enterprise architecture, graphics, and highly parallel programming. A passionate problem-solver, he excels in building collaborative teams, driving innovation, and turning conflict into opportunity. He thrives on creating software that empowers people and transforms ideas into impact.   You can link with Eagan Rackley on LinkedIn.  

BONUS: Why the People Track Exists — And What It Will Help You See at GAS26 The Global Agile Summit kicks off on May 4th, and the People track is one of the most loaded lineups this year. In this episode, track co-hosts Pete Oliver-Krueger and Alina Thapliyal share the story behind the track, the sessions they're most excited about, and why — in a world increasingly focused on technology and AI — the people dimension is more critical than ever. The Story Behind the People Track "Every transformation still comes down to how people feel, how they communicate, how they work with each other, how decisions are made, and how leaders can create a space and conditions for them to thrive."   The People track isn't new to the Global Agile Summit — it's been part of the event for several years, sometimes combined with the Product track. But this year, the volume and quality of submissions made it clear that the topic deserves its own dedicated space. Alina frames it in terms of the VUCA world we operate in: volatility, uncertainty, complexity, and ambiguity make the people dimension more important, not less. Pete picks up the thread with a sharper edge — as AI and technology increasingly dominate the conversation, it's easy to lose sight of the people creating, designing, using, and selling the products. That tension is exactly why he wrote Shift: From Product to People with his co-author Michael. The book exists to pull practitioners out of product-as-a-thing thinking and into product-as-people thinking. Product as a Thing vs. Product as People "When we lose sight of the people around the product is when things start to suffer."   When Pete reviewed the track submissions, he noticed a telling pattern — a divergence that confirmed the track's reason for existing. Many submissions talked about product as an artifact, focused on deliverables and outcomes, with no connection to the humans involved. Then there was a second group that immediately saw themselves in the People track. Pete explains the dynamic: we all start by caring about people and solving problems, but at some point we pick a solution and the work of getting it done becomes all-consuming. The task becomes the goal and the people become objects. Unless we consciously leave space to think about relationships and human dynamics, we drift into laser focus on things. The sessions in this track are designed to be the antidote. Marcus Bullock's Keynote — A People-First Success Story "It's so inspiring to just listen to it and think that I can also do it. We can give people a second chance. We can focus on what's good and increase the good, rather than focus on what's bad."   Both Alina and Pete highlighted Marcus Bullock's keynote as a must-watch. Marcus, CEO of Flikshop, started from a deeply difficult place and built his way to leading a business and empowering others. What makes his story stand out isn't the arc from adversity to success — it's the honesty. Pete, who has known Marcus for over 15 years, points out that Marcus's story includes genuine ups and downs, and his people-first approach is what helped him weather all of them. Alina was struck by the energy Marcus brings and his focus on amplifying what's good in people rather than minimizing what's bad. It's a message that resonates whether you lead a team of five or an organization of five thousand. Usability Theater — The Courage to Shut Up and Listen "Take a product, give it to a customer, and don't say anything. Just let the customer try it, let the customer experience the product. We need to have the courage to shut up."   Alina's second highlight was the session on usability theater, where the core idea is deceptively simple: put your product in front of a customer and resist the urge to explain anything. No "look what we did here," no guided tour. Just observe how people actually interact with what you've built. It takes real courage, Alina says, because our instinct is to showcase and defend our work. But the insights you gain from silence and observation are worth far more than the comfort of narration. This is one of those sessions that sounds simple but could change how you run your next product review or demo. Agency — Breaking the Permission Loop "There is a necessity to understand ourselves and have some of this confidence, but that's true for everybody, even our leaders. They may be stuck in permission loops with their own bosses."   Tara Scott's session on agency and breaking the permission loop touched a nerve for both hosts. Alina shared that in companies she's worked for, drawn-out decision processes wasted resources and drove people to leave. Tara's session tackles how to empower people to actually make decisions. Pete adds a crucial nuance: the permission loop isn't just a top-down problem. Leaders are stuck in their own permission loops too. Everyone in the chain faces the same challenge, and the solution can't be found in a vacuum — it requires understanding where each person is coming from and building flexibility across the team and organization. If this topic hits close to home, Tara is also doing a live Q&A during the summit. Neurodiversity, Jeff Patton, and the Full Lineup "Every time I have a conversation with Jeff Patton, it just goes in all kinds of directions, and I have so much fun."   Pete flagged two more sessions worth watching. The neurodiversity session with Anita promises to open up a topic that deserves more airtime in the agile community — how different minds experience and contribute to team dynamics. And Jeff Patton, whose conversations with Pete apparently never follow a straight line, brings his signature blend of product thinking and people awareness. The full track covers a wide range: trust, leadership, inclusion, decision-making, neurodiversity. As Alina puts it, these topics are universal — they're about human behavior, and that's valuable in any field where you work with people. A New Lens for Monday Morning "I think people can take away from the track the ability to see other dynamics in their workplace that maybe they currently aren't spending a lot of time paying attention to, or didn't even realize were there."   When asked what attendees will walk away with, both Alina and Pete landed on the same metaphor: a new lens. Alina described it as a better understanding of how human dynamics shape culture and performance, paired with practical tips that can be applied immediately — no theory, just real-life stories from real practitioners. Pete took the metaphor further, comparing it to putting on night vision goggles. After watching these sessions, you'll start noticing dynamics you'd been walking past every day — relationship patterns, permission loops, communication gaps. And with that new visibility comes influence. You'll realize you have more ability to shape your environment than you thought, simply because you can now see what was always there. About Pete Oliver-Krueger Pete Oliver-Krueger is an Executive Coach with the Library of Agile, and co-author of the book "Shift: From Product to People", a novel that tells the complex story of how leading "people-first" is required to solve tomorrow's biggest problems.   You can link with Pete Oliver-Krueger on LinkedIn, and visit Pete OK's website at https://www.shiftingpeople.com/. About Alina Thapliyal Alina Thapliyal is the Scrum Master for a team within the public sector. Her aspiration is to become an agile coach. She grew up in Romania and has been living in Germany for 13 years. She loves jogging, reading and actively listening to people's life stories.   You can link with Alina Thapliyal on LinkedIn.

BONUS: AI Won't Just Change How You Work — It Will Reshape Your Organization The Global Agile Summit is around the corner, and the AI in Organizations track is one you don't want to miss. In this episode, track co-hosts Michael Dougherty and Michał Parkoła walk us through what they've built — from the thinking behind the track name to the sessions that stood out, and why this isn't just another AI conference lineup. Why "AI in Organizations" — Not Just "AI" "AI will not only be useful to existing organizations, but it will reshape organizations in a very significant way, the same way cars reshaped cities."   Michael and Michał drew a deliberate line with the track name. Michael points out that AI has been around for decades — it didn't start with ChatGPT. The real shift now is AI agents scaling to enterprise level, replacing automation that used to require specialized tools. Claude Enterprise holds about 29% of the enterprise AI market, Gemini around 15%. But Michał pushes the framing further: the first-order effect is applying AI to existing work. The second-order effect — the one he's most interested in — is how AI will reshape organizations themselves. New species of companies will emerge, smaller teams will achieve what used to require hundreds of people, and some existing organizations won't survive the transition. That's the conversation this track is designed to start. Filtering the Signal From the Slop "There was a bit of AI slop in the submissions. There was a lot of talk that, unfortunately, was meta-talk — there was no real value that I could glean."   When session submissions came in, Michael was disappointed by how many were surface-level — big promises with no practical takeaway. The ones that stood out were practitioners showing what they actually do. Dave Westgarth, for example, demonstrated how he uses AI with Lovable and Claude embedded in Miro whiteboards to enhance real team interactions. On Michał's side, the standout was Max Pirata, who challenged the "vibe coding is slop" narrative. His argument: the quality of large-scale software has never depended on the infallibility of individual engineers — it depends on disciplined engineering processes. The same applies to agentic engineering. Your first attempt at vibe coding will be rough, but there are ways to apply engineering discipline to AI-assisted development. That's what Max will be talking about at the summit. Prototyping at the Speed of Thought — And the Human Bottleneck "Now I've got 20 prototypes that I can choose from. Which ones are the best? Which ones do I need to clear out? Product managers now have a different game they play."   Two sessions capture opposite sides of the AI-in-organizations tension. Dave Westgarth's "Vibe UX: Prototyping at the Speed of Thought" shows how vibe coding lets you build full working systems instead of Figma mockups — so fast that the bottleneck shifts from creation to selection. Product managers and product owners now face a new challenge: clearing the closet of AI-generated options rather than validating a single bet. On the other side, Shawn Wallack's session — "Even With AI, Your System Will Never Be Better Than Its People" — brings the counterpoint. Michael explains the systems-thinking angle: AI does what you tell it, fast and accurately, but that speed reveals human bottlenecks everywhere else. He shares the cautionary example of AI declining twice the insurance claims humans did, with the human-in-the-loop rubber-stamping instead of actually checking — leading to a class action lawsuit. The lesson: AI doesn't remove the need for human judgment, it makes it more critical. Gojko Adzic on Spec-Driven Development and Building AI Products "True to his roots, he is exploring spec-driven development now, which is one of the popular threads in agentic engineering."   Gojko Adzic — the author of Specification by Example and Impact Mapping — brings heavyweight credibility to the track. Michał reveals that while Gojko is exploring spec-driven development in the context of agentic engineering, the interview focused more on his hands-on experience building his own AI products. For attendees, this means real practitioner insights from someone who literally wrote the book on how specifications drive software quality — now applying those principles in an AI-first world. From Beginner to Builder — Who This Track Is For "My favorite case would be people who will quit their jobs and start new companies that will be able to achieve wonderful things with much smaller teams than we would otherwise imagine possible."   The track is designed to meet people wherever they are. Pierre Beaning covers the basics of using Claude for beginners. Jason Little — who Michael describes as a "techno nerd" and "grand poobah" — shows how to build and scale multi-agent systems for business. The spectrum runs from "I've only used AI to plan a vacation" to "I'm orchestrating agent teams." But Michał's vision for the ideal attendee is bolder: someone who walks away ready to start a company. Michael backs this up with the story of an AI unicorn — $1.8 billion valuation, one guy and his brother, in the pharmaceutical industry, just a few months old. Hype? Maybe. But Michał's pragmatic take lands it: "If you make a few million, even if it dies later, that's not such a bad thing." The goal of the track is to blow away the fog — throw flares into key spots so people can sketch a map of what's possible and decide which areas deserve a follow-up. About Michael Dougherty Michael Dougherty is the Co-author of Shift: From Product to People, leadership coach with 30+ years helping organizations adopt people-centered, agile ways of working. Co-owner of the Global Agile Summit.   You can link with Michael Dougherty on LinkedIn and find out more at shiftingpeople.com. About Michał Parkoła Michał Parkoła is an Agile practitioner based in Warsaw, Poland. Previously hosted the Value-Centric Product Development track at Agile Online Summit 2024. He is building Tapestry, an AI planning assistant.   You can link with Michał Parkoła on LinkedIn and check out Tapestry at growwithtapestry.com.

Viktor Glinka: The Curious Product Owner and the Disempowered One — How Scrum Masters Can Help POs Find Their Voice In this episode, we refer to product owner anti-patterns and product owner interviews on the Scrum Master Toolbox Podcast. The Great Product Owner: The Curious Negotiator Who Uses Data and Passion Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Great product owners are always asking: what if? How can we do it differently? How can we simplify?" - Viktor Glinka   Viktor describes great product owners as fundamentally curious people who constantly look for simpler, better ways to do things. But curiosity alone isn't enough — they're also skilled negotiators who navigate conversations with teams, stakeholders, and customers. In scaled setups, their work shifts from clarification to prioritization, and they delegate effectively. Viktor highlights their visualization skills with a concrete example: one product owner showed stakeholders a work composition chart revealing that more than 50% of the team's work was technical debt, making it impossible to deliver new features. That single visualization changed the conversation. Great product owners are also systems thinkers who understand dynamics and root causes, avoiding local optimization. Viktor adds something rarely discussed in frameworks: mindfulness. Product owners face constant pressure, and the ability to make peace with decisions — to move forward without regret — is critical. They also share their passion and vulnerability with development teams, telling them personally why they want to build something. It's the emotional complement to data-driven negotiation.   Self-reflection Question: Does your product owner use data and visualization to negotiate with stakeholders, or do they rely on authority and deadlines? How could you help them build those skills? The Bad Product Owner: The Disempowered Middleman Who Can't Give Direction Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "This fear of not being allowed — it's an illusion. You can always do more. Just try. No one will fire you for a suggestion." - Viktor Glinka   For Viktor, the worst product owner anti-pattern isn't about skill or knowledge — it's about empowerment. He believes every person can learn to become a great product owner if they are empowered and trusted by the organization. The red flags are clear: when a product owner talks about deadlines and commitments but never about return on investment or outcomes, that's a sign they're being pushed rather than empowered. Viktor shares the story of a product owner who was struggling to give direction because stakeholders just wanted their features delivered. He was a middleman — afraid to communicate his own vision to the team, afraid to challenge stakeholders. But inside, there was a spark of passion about the product. Viktor helped him uncover it using a simple tool: the product vision canvas. They sat down together and put his thoughts on paper. Once the vision was written, the product owner started thinking about the next step on his own: "What if I show this to stakeholders? What if I tell them there's a better way?" The product vision canvas became the bridge from learned helplessness to ownership.   Self-reflection Question: Is your product owner telling themselves "I'm not allowed to" when they actually could do more? What's the smallest experiment you could run together to test that assumption?   [The Scrum Master Toolbox Podcast Recommends]

Viktor Glinka: Why Context Is King for Scrum Master Success — Building Capabilities That Drive Business Goals Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Product management skills are crucial for Scrum Masters. Once you understand how retention impacts your return on investment, you will be able to coach your product owner." - Viktor Glinka   Viktor offers a nuanced perspective on Scrum Master success by distinguishing between short-term and long-term success. On the long-term side, he argues that the purpose of a Scrum Master extends beyond working with teams — it's about helping improve the system as a whole. To do that, you need to connect your contribution to the product's success by helping build specific capabilities. Viktor grounds this in practical terms: start by asking what the business goal of your company is, and check whether people around you actually know it. Never assume everyone does. That simple act of curiosity gives you the information you need to figure out how to contribute. In his experience, the key capability his teams needed to develop was multi-learning — the ability to work across components — and that directly served the business goal. Viktor makes a strong case that Scrum Masters need product management skills. Understanding how metrics like retention impact long-term success allows you to coach product owners and analyze product dynamics. His practical advice: if you're not experienced in this, go shadow your product owner, spend time with the sales department, and look through customer support tickets. You'll understand far more about the system than staying at the development organization level.   Self-reflection Question: Can you clearly explain how your work as a Scrum Master contributes to your product's success? What specific capability are you helping the system build right now? Featured Retrospective Format for the Week: Data-Driven Discussions with Actionable Outcomes Viktor's approach to retrospectives is refreshingly pragmatic: it depends on the team. For teams not yet used to actionable improvements, he starts simple — review previous retro decisions, ensure new concrete ones are created, and bring data as food for thought. He particularly likes using the cumulative flow diagram and time distribution histogram to help teams reflect on consistency in delivery. One team he worked with adopted this as a natural habit over time. For mature teams, format matters less — one team ran a simple "good, bad, to improve" retro in 30 minutes on their own, without a Scrum Master, and it was one of the most engaged and effective retrospectives Viktor had ever seen. He also values the free-talk format when first meeting a new team, coming in with genuine curiosity and no biases. And when something clearly went wrong — an incident, a failure — Viktor drops whatever format he had prepared. "In those moments, it's important to trust your instinct, read the room, sense the tension, and step into the danger directly."   [The Scrum Master Toolbox Podcast Recommends]

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]

Viktor Glinka: When Internal and External Team Members Have Divergent Goals — The Silent Killer of Agile Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The root causes for destructive team patterns often lie outside the team itself." - Viktor Glinka   Viktor shares a story from a manufacturing organization where one team stood out — and not in a good way. The team was composed of both internal and external members, and what no one saw coming was that their implicit goals were fundamentally divergent: the external members were focused on maximizing revenue for their own company, while the internal members cared deeply about product quality. The signs were visible to anyone who approached them — they barely talked to each other and preferred to work individually. When Viktor tried to raise the topic of cooperation and trust, he was met with awkward silence. One team member finally told him: "I don't want the team to blow up. In my previous experience, I raised this topic and that was the end of the team." Fear kept the truth underground. Viktor brought his observations to the manager, who acknowledged the lack of a shared goal as the root cause — but couldn't fix it because he wasn't authorized to manage the external people. The takeaway was clear: three key success factors for any team are the right team composition with people who want to work together, a shared goal that unites diverse perspectives, and clear expectations set by their manager.   In this segment, we talk about LeSS self-designing team workshops and the importance of team composition in scaled setups.   Self-reflection Question: Does your team have a shared goal that everyone — including external members and contractors — genuinely understands and cares about? When was the last time you checked? Featured Book of the Week: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland Viktor recommends The Art of Doing Twice the Work in Half the Time by Jeff Sutherland as the book that sparked his passion for Scrum. As he puts it: "I know the title is very controversial and often criticized, but I could deeply relate to the stories inside the book. They sparked a passion that is still with me." Viktor also recommends a bonus book: Reinventing Organizations by Frederic Laloux, which showed him the real power of self-organization and validated what he had already started experimenting with in his project management career. It pushed him to explore holacracy, sociocracy, intent-based leadership, and coaching.   [The Scrum Master Toolbox Podcast Recommends]

Viktor Glinka: When Passion Becomes the Problem — How Pushing for Agile Change Too Fast Creates Resistance Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I wanted to change the organization overnight with my eagerness and passion. Instead of helping the system to evolve, I created resistance. I became the problem myself." - Viktor Glinka   Viktor shares one of the most honest failure stories we've heard on the show. Early in his Scrum Master career, he joined a finance organization as a Scrum Master for a newly created department — his first experience in a scaled setup. Each team owned a particular part of the user journey, organized around components. After getting exposed to Large-Scale Scrum (LeSS) through a colleague, Viktor became overexcited. He started pushing for structural changes daily, telling the head of department that the current team composition was wrong and they needed cross-functional feature teams. But he was disconnected from reality. For this particular organization, even having partially cross-functional teams was already a big stretch. Worse, the head of department wasn't even authorized to make the changes Viktor was pushing for. Instead of helping the system evolve, he created resistance. What proved his approach wrong? That same department later received a European Award for being the best mortgage department. It took Viktor a few more years and similar cases to fully absorb the lesson: read the room, develop sensitivity to the system's pace, and stimulate reflection in decision makers rather than pushing your own agenda.   In this episode, we refer to organizational development, LeSS (Large-Scale Scrum), and systems analysis. Viktor also mentions the interview with Bas Vodde on the Scrum Master Toolbox Podcast.   Self-reflection Question: When was the last time you pushed for a change because you believed it was right, without checking whether the system was ready for it? What would happen if you started by asking decision makers what they think would be a good next step?   [The Scrum Master Toolbox Podcast Recommends]

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—within 3 weeks of a given application, his team sees a 90% reduction in AI usage in the first week, dropping to 0% within 13 days, because once a computer program does everything you need, you don't need AI anymore. R2-D2, Not C-3PO: How to Think About AI on Your Team "I think of our AI use more like R2-D2 than C-3PO. R2-D2 doesn't talk—bonus points. He doesn't interject his fear. He saves your butt. He's silent until you need him, and visible when you need him."   Peter's Star Wars analogy captures his team's philosophy on AI integration. AI should be like a smarter linter—a quiet, capable tool that handles the boring, repetitive tasks so humans can focus on creativity and shipping. His team treats AI as a "super junior" with infinite time: set it up as if it invented Python, have it write buy-the-book code with unit tests, and then a human reviews and accepts (or rejects) the output. The tooling isn't consistent enough to ship autonomously or commit directly into the codebase—even frontier providers don't fully understand what their models do. The practical benefit is enormous for setup and configuration: what used to be a painful, arcane process of tracking down dozens of AWS or Azure docs becomes a 20-minute "hello world" that's actually a working proof of concept. Your job isn't to become an expert at cloud services—it's to ship product. The Biggest Mistake: Automating Broken Processes at AI Speed "All it does is automate all the mistakes you made, all the way, at AI speed."   When asked about the most common mistake organizations make with AI, Peter is blunt: they port their existing infrastructure into AI-governed systems instead of rebuilding from the ground up. Companies with a self-inflated opinion of their processes think AI is just a million-person force multiplier—so they'll ship faster. But if your process was broken before AI, you'll just generate broken output at unprecedented scale. That 3,000-script experiment proved this firsthand. Peter's recommendation: rebuild from the bolts up. Start with AI-last architecture where reliable, offline-capable software handles the core, and AI is reserved for the edges—filling gaps, translating between systems, and making connections that don't exist yet. SaaS Is Bloated: The Case for AI Transformation Layers "The one thing AI is good at is transforming between boundaries."   Peter's team has been divesting from SaaS providers, replacing the patchwork of middleware subscription plans that forced everyone to copy and paste between CMS, Excel, meeting notes, and email. His approach: product people use Notion, developers use GitHub, and the two cross-sync without needing Jira as an arbitration layer. Everyone tracks work in the tool they already live in. AI's real superpower here is translation—between APIs, between languages, between formats. Peter sees a future where small translation layers between CRUD operations replace the bloated, one-size-fits-all SaaS tools that are "built for 99% of users with generalized features nobody uses." His team also freed themselves from tools like Figma: the designer works in their preferred graphics program, the developer in their preferred IDE, and AI arbitrates the differences. Teams, Velocity, and Reinvesting the AI Dividend "5 to 7 people is still good, because you need a diverse set of people who are intensely focused on certain areas. But they should be allotted that savings in time to ship all the things that get cut."   Peter pushes back on the idea that AI changes the ideal team size. The 5-to-7 person team still works—what should change is what those people do with the time they save. Instead of loading teams onto more projects or increasing portfolio velocity, reinvest the AI productivity dividend into quality: ship with unit tests from day one, ship WCAG-compliant from day one, and stop cutting features to hit deadlines. Version 1.0 should no longer need an immediate 1.1 follow-up. Peter also challenges the notion that AI eliminates the need for experienced practitioners—velocity metrics become meaningless when a 6-week coding plan finishes in 25 minutes. What matters is using the saved time to make software genuinely better. The Future: Demo-First Development and Solid Releases "I can show you a working demo of the thing at the first meeting, and you can pay for it. And then we can make it better than your dreams."   Peter sees AI transforming the consulting and product development lifecycle from "launch, listen, and learn" to "listen, iterate, and launch." As a consultant, he now brings working demos to first meetings instead of $20,000 six-week proposals. Clients see the product in motion and immediately identify improvements—before money changes hands. This shifts the power dynamic: products iterate toward quality before launch, not after. Peter envisions a future where we ship solid releases that iterate in quality, with interfaces that show users only what's relevant to them instead of "90,000 buttons that don't apply to me."   About Peter Swimm   Peter Swimm is a conversational AI veteran with 25+ years in tech — from managing data centers to building Botkit (the open-source chatbot framework that powered Slack and Teams bots), to serving as Principal Product Manager at Microsoft Copilot Studio. He's the founder of Toilville, a consultancy helping businesses build conversational AI solutions.   You can link with Peter Swimm on LinkedIn and visit his website at peterswimm.com.

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 doing everything your customer says, then you are not managing your product. That's the foundation." - Efe Gümüs   Efe names people-pleasing as the worst product owner anti-pattern — the "customer is always right" mentality applied to product management. When a PO says yes to every request, the consequences cascade quickly: multiple priorities competing simultaneously, everything marked urgent, no meaningful sprint goal, constant context switching, and new items injected mid-sprint. The team loses focus entirely. Efe has seen this in startups where the CEO walks in with urgent customer requests, and in larger organizations where multiple customers each demand customizations. In both cases, the PO becomes a pass-through instead of a decision-maker. The customer might be happy today, but will they be satisfied in six months when nothing is coherent? As Vasco notes, when you're serving multiple customers and saying yes to one, you're saying no to all the others — you just haven't told them yet. The result is chaos: steering blindfolded without navigational tools, trying to go everywhere at the same time. A product owner's most important skill is coherent, aligned decision-making — and that means learning to say no.   Self-reflection Question: How often does your product owner say no to stakeholder requests — and when they do say yes, is it because the request aligns with the product vision or because they want to avoid conflict?   [The Scrum Master Toolbox Podcast Recommends]

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 the thinking toward clear action points. This diamond pattern — diverge, explore, converge, act — ensures that the team moves from broad reflection to specific, owned commitments. The key word is "owned": when people arrive at actions through this structured exploration rather than being told what to improve, they commit to the follow-through. Efe connects this directly to his broader philosophy: the best systems don't depend on any single person, and the best retrospectives produce actions that the team drives forward without needing the Scrum Master to push.   [The Scrum Master Toolbox Podcast Recommends]

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]

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, the book helped Efe see the parallels between personal goal-setting and the iterative progress at the heart of Scrum. When you feel lost or stagnating, the exercises in the book help you create small pieces of progress — not quick wins, but genuine forward movement that builds momentum. Efe connects this directly to Agile: every event, every sprint, every review is a small achievement toward the next one. If you can set a clear life goal, setting a sprint goal becomes natural. The clarity of purpose unlocks action — and that's as true for individuals as it is for teams.   [The Scrum Master Toolbox Podcast Recommends]

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]

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 is already too high for humans to keep up, and the same LLM that wrote the code often catches bugs that another instance of itself introduced. Philip has been running both Codex and Cursor as PR reviewers on GitHub, and has been surprised by how often they identify issues in both human- and AI-generated code. He believes we are approaching a threshold where human intervention in codebases will be seen as risky and irresponsible — not the other way around. AI Killed the Individual Contributor "You're not building the thing anymore. You're pondering and tweaking the machine that builds the thing."   In his widely discussed essay "AI Killed the Individual Contributor", Philip argues that maximizing productivity with AI now requires engineers to spend their time on what are essentially management tasks: setting priorities, resolving conflicts, delegating to agents, reviewing output, and giving feedback. The IC role isn't disappearing because AI codes better — it's disappearing because the highest-leverage use of an engineer's time has shifted from writing code to orchestrating the systems that write code. Right now, it feels like managing a team of barely competent interns. But Philip expects that to change fast. Soon it will feel like managing high performers who are faster and more capable than you — and the engineers who thrive will be the ones who learned to let go of the keyboard and focus on judgment, direction, and taste. Building Solo with AI: The Superphonic Experiment "20x productivity means we have 20x fewer PMs than we need."   Philip is putting his thesis to the test with Superphonic, an AI-powered podcast player he's building essentially as a solo founder. What would have required a team two years ago, he now ships alone — leveraging AI agents for coding, testing, and review. But the productivity multiplier creates its own problems. When you can build 20x faster, the bottleneck shifts from engineering capacity to product judgment. You need to know what to build, not just how to build it. Philip's reference to The Mythical Man-Month is deliberate: adding more people (or agents) doesn't solve the fundamental challenge of building the right thing. The hardest part of being both the architect and the manager of your AI agents is knowing when the model breaks down — when you need to step in and do the work yourself rather than delegating. What Teams Get Wrong About AI Integration "There is a lot more that can be done to increase the quality of AI output even if all progress on foundation models stops."   For Scrum Masters and agile coaches helping teams adopt AI tools, Philip's warning is clear: don't treat AI as just another developer on the team. The integration requires rethinking how work is structured, how quality is assured, and what it means to be an engineer. Teams that bolt AI onto existing workflows without changing the underlying process will get marginal gains at best. The ones that redesign their workflows around AI capabilities — including accepting that humans may not need to review every line of code — will see transformational results. Philip's practical advice: do the work yourself first. Understand what the AI is doing before you delegate wholesale. The engineers who skip this step lose the judgment they need to manage the output effectively. About Philip Su Philip Su is a Distinguished Engineer (IC9) who scaled Facebook's London office from a dozen engineers to 500+, served as site lead at OpenAI, and now builds Superphonic — an AI-powered podcast player. He writes about the future of software work at Molochinations on Substack. LinkedIn   You can link with Philip Su on LinkedIn.

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 leadership void on the team that someone will step up and fill — and usually it's an engineer, or the Scrum Master becomes a quasi-product owner." - Nate Amidon   Nate views the product owner role as fundamentally a leadership position — leadership of the backlog, prioritization, and the connection between business needs and team execution. When a PO doesn't embrace that responsibility, the symptoms are predictable: throwing half-baked stories over the fence with a "just figure it out" attitude, constantly shifting priorities without considering the downstream impact on a team that just spent two weeks building something, and being absent from the daily conversations that keep everyone aligned. What follows is what Nate calls a "leadership void" — someone else on the team, often an engineer or the Scrum Master, steps in as a quasi-product owner because the work still needs direction. Meanwhile, without a PO acting as a filter, stakeholders start shoulder-tapping the team directly, competing directors play corporate Game of Thrones over whose priorities win, and the team gets whiplashed between conflicting demands. The biggest red flag? When you hear the team say: "We just did what you told us."   Self-reflection Question: If your product owner disappeared for two weeks, would anyone on the team notice a gap in leadership and direction — or has someone already quietly stepped in to fill that void?   [The Scrum Master Toolbox Podcast Recommends]

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 you chose it. It sounds lighthearted — and it is — but that's exactly the point. As Vasco notes, "laughs per minute" is a great metric for retros, because when people are laughing, they can talk about serious issues without defensiveness. The memes give a different angle on what happened during the sprint, surfacing deeper feelings and patterns that traditional formats might miss. It's especially useful when teams are getting fatigued from running the same retro format over and over.   [The Scrum Master Toolbox Podcast Recommends]

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]

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, and work should go to teams."   [The Scrum Master Toolbox Podcast Recommends]

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]

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 could work. The team delivered something to show every single sprint — something that never happened with traditional project management. The turning point came when he made a bet with a product manager: the PM needed 15 items per sprint, the team committed to 15, but historical throughput was 5-8 items. Reality delivered seven. That moment crystallized the #NoEstimates insight: we can't fight reality, but we can choose which seven items to deliver. Reality Is a Bitch — Why Linear Predictive Planning Fails "Never believe the plan. Or as in Scarface — never get high on your own supply. It's so unbelievable how project managers still today believe their freaking plans."   At Nokia, Vasco managed a program of 500 people across 100 teams on four continents. No way to get everyone in a room. So he tracked system-level throughput — features delivered to integration per week. Six months into a twelve-month project, the data said they'd be at least six months late. He told the program manager: cut scope now. The program manager did what every PMI-trained program manager does — sent an email asking all 100 teams if they'd deliver on time. Every single team said yes. Nobody wants to be first to admit they're late. Twelve months in, they discovered they were six months late. The project got canceled. 500 people, millions of euros, all because somebody believed the plan. Linear predictive planning is useful for exploring what might be possible if nothing goes wrong. It is not reality. The only tool that reflects reality is throughput — the number of items completed per unit of time. Earned Value Management — George Orwell at His Best "It's not earned, it's spent. It's not value, it's cost. It's not management, it's just observation. Monty Python could not have come up with a better name."   Felipe shares a story that mirrors the absurdity: an industrial project with a dedicated 35-person earned value management department. Before the meeting even started, the department head announced, "Let's all acknowledge that earned value management is more an art than a science." Their charts were made up, the contractor's charts were made up, and the goal of the meeting was to agree that the project would finish on time — regardless of what any data said. This is where traditional project management ends up when it disconnects from throughput: a $30 million scope addition with zero additional time, defended by charts that a mediocre attorney can invalidate in the first week of litigation. Felipe knows — he spent a year being cross-examined by forensic schedulers whose full-time job is proving that construction schedules are fiction. One Small Experiment to Test #NoEstimates "Never convince anyone. Convince yourself. Once you're convinced, whatever other people say, it doesn't really matter because you're not gonna take them seriously anyway."   Here's how to validate throughput-based planning with your own data: take the last 10 sprints (or periods). Calculate the average throughput and control limits from the first five. Then check whether the next five sprints fall within that range. They will. If you're in software and using Jira, you already have this data. You don't need anyone's permission. You don't need to change anything. Just look at what your team actually delivers versus what they planned to deliver. The gap between those two numbers is the gap between superstition and reality. About Felipe Engineer-Manriquez Felipe Engineer-Manriquez is a best-selling author, international keynote speaker, Project Delivery Services Director at The Boldt Company, host of The EBFC Show podcast, and a proven construction change-maker implementing Lean and Agile practices on projects from millions to billions of dollars worldwide. He is a Registered Scrum Trainer™ (RST), Registered Scrum Master™ (RSM), and recipient of the Lean Construction Institute Chairman's Award. His book Construction Scrum is the first practical guide for applying Scrum in construction.   You can link with Felipe Engineer-Manriquez on LinkedIn.

Bhavin Shukla: The Adaptable Product Owner — How Progress Over Perfection Drives Real Value in Scrum In this episode, we refer to story mapping as a key tool for maintaining focus and alignment. The Great Product Owner: Embedding Prioritization as a Daily Discipline 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.   "She had this section called 'Not Required Anymore.' Every time, it was a very subtle and a very respectful way of saying to the team: great idea, but the goals changed. We don't need it anymore." - Bhavin Shukla   Bhavin describes a Product Owner who turned prioritization into a living discipline. She built a culture of co-creation where everyone contributed ideas to the backlog, but she also saw the biggest risk coming early: misalignment from siloed ideas. Her approach was to use story maps extensively in refinements and planning, communicating weekly with customers to collect feedback. When the direction changed — and it regularly did — she articulated the shift clearly: "Goals changed, here's what we're doing now." Her stroke of genius was a section on the story map called "Not Required Anymore," where deprioritized ideas landed respectfully. Nobody felt offended; they understood customers' needs had shifted. This created a culture where people kept contributing ideas courageously, knowing that even if priorities changed, their input was valued. The result was a team that could adapt without chaos, maintaining focus while embracing change.   Self-reflection Question: How does your Product Owner communicate changes in direction? Is there a respectful, transparent mechanism for showing the team what's no longer needed — and why? The Bad Product Owner: The No-Feedback 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.   "I was looking for those keywords — a change in priorities, a change in the roadmap. Those conversations were missing. And when I asked about the roadmap, I got crickets." - Bhavin Shukla   Bhavin shares the story of a Product Owner who was brilliant at articulating value in the backlog — customer-centric stories, well-structured work. On the surface, everything looked great: goals were being met, the team was delivering. But something subtle was wrong. The roadmap never changed. Priorities never shifted. There were no conversations about customer feedback changing direction. When Bhavin got curious and asked to see the roadmap, he realized it was a static delivery plan, not a living document. The Product Owner wasn't collecting feedback from customers, so there was never a reason to adapt. The team was essentially building in a vacuum — shipping features nobody was validating. It's an anti-pattern that's easy to miss when the team is performing well on internal metrics but disconnected from real customer value.   Self-reflection Question: Is your team's roadmap a living document that changes based on customer feedback, or has it become a static delivery plan? When was the last time a priority genuinely shifted based on what you learned from users?   [The Scrum Master Toolbox Podcast Recommends]

Bhavin Shukla: Why Scrum Master Success Means Confronting the Ugly Truth With Data 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 is not always good vibes, good environment for us as Scrum Masters. For me, it's about confronting the reality, the ugly truth, which takes the team to tougher conversations, more constructive challenges." - Bhavin Shukla   Bhavin shares a pivotal moment in his career that redefined what success means for a Scrum Master. He was working with a fantastic team — great culture, people who believed in quality, knowledge sharing, strong bonds. But sprint goals weren't being met, and stakeholders were constantly chasing the Product Owner and Scrum Master for answers. Bhavin got his hands dirty with the data: lack of clarity on work, context switching, patterns emerging. When he presented the data to the team, he was met with silence — a confronting kind of silence. The team was essentially saying, "We were happy. Why would you do this to us?" Bhavin's response was direct: going for coffees and laughing together isn't the whole job. If he wasn't showing them reality, he couldn't look at himself in the mirror. The team eventually used that data to raise their own voice, pointing out systemic issues with external vendors and organizational constraints. The data gave them a platform to speak truth — not as blame, but as discovery.   Self-reflection Question: What conversations did you avoid this week that could have unlocked progress for your team? Are you bringing data to those conversations, or relying on vibes? Featured Retrospective Format for the Week: Newspaper Headline Retrospective Bhavin shares an unconventional use of the newspaper headline technique — typically used for roadmaps and vision — as a retrospective format. The idea is simple but powerful: ask the team to write the newspaper headline they want to see about themselves. What would the story say when they succeed? By authoring their own headline, the team takes ownership of the narrative — they define what success looks like, what must go right, and what risks could derail them. "Putting them in that newspaper headline, they authored the story. They own the accountability to make it successful," Bhavin explains. He also shares a second technique for Kanban teams under pressure: a rolling two-column whiteboard — "Frustration of the Day" and "Success of the Day" — with no meetings required, just real-time data capture that becomes a continuous retrospective, reviewed every 2-3 weeks.   [The Scrum Master Toolbox Podcast Recommends]

Bhavin Shukla: De-Scaling an Agile Organization — Removing Bureaucracy Without Losing Consistency 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.   "Before people understand what needs to change, and how they need to adopt, what it means to them in their day-to-day work, and how it's going to help and add value — those conversations are missing." - Bhavin Shukla   Bhavin brings a challenge many organizations face but few talk about openly: de-scaling. He's working with an organization that adopted a scaling framework for consistency — shared language, standardized tooling, uniform processes across business units. It worked for alignment, but it also created bureaucracy. Now leadership wants to become leaner and more nimble. The problem? The de-scaling itself is happening cookie-cutter style. Changes are being rolled out — new framework versions, new tools, flow metrics — without explaining the "why" to the people affected. The result is burnout and two parallel ecosystems running simultaneously: the old meeting structures people never abandoned, and the new Scrum events layered on top. Bhavin and his coaching peers ran a "Million Meeting Minutes" workshop, collecting data on how much time teams spend in meetings, what decisions get made (or don't), and who dominates conversations. The data revealed the overlap and waste. The experiment now is mapping those parallel systems and working with teams to understand which problems each structure actually solves — consolidating where possible while maintaining the consistency of language the organization genuinely needs.   Self-reflection Question: In your organization, are there parallel meeting structures addressing the same problems? What would it take to map them and start a conversation about consolidation?   [The Scrum Master Toolbox Podcast Recommends]

Bhavin Shukla: The Hidden Cost of Always Saying Yes — How a Helpful Scrum Team Nearly Self-Destructed 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 was sort of making me feel as a Scrum Master, like it's a slow self-destruction mode they are in. Good intentions, but it wasn't helping them, and that's something that they were not able to notice." - Bhavin Shukla   Bhavin tells the story of a banking team that looked like every Scrum Master's dream on day one — humming, cracking jokes, in the zone. But underneath the positive energy, the data told a different story. Sprint commitments kept overflowing, tech debt was rising, P1 and P2 production issues were climbing, and decision latency was immense. The root cause? This team of genuinely helpful people couldn't say no. They wanted to help everyone who came to them, and that desire was slowly drowning them. No one was giving them feedback about the consequences — missed sprint goals were met with "that's okay, we'll do it next sprint." Bhavin introduced two simple tools: an anonymous happiness meter on the wall (rate 1-5, leave a note if below 3) and a gratitude wall. The data revealed the truth — the team was burning out, handling weekend incidents with no escalation path. Armed with this data, Bhavin coached the team on negotiation techniques: you don't have to be rude to say no, you can negotiate the yes, you can negotiate the no.   In this segment, we talk about the importance of collecting regular data to surface hidden patterns, and the anti-pattern of teams operating without feedback on the consequences of their decisions.   Self-reflection Question: Is your team's positive energy masking underlying problems? What data would help you discover whether good vibes are hiding unsustainable patterns? Featured Book of the Week: Make Work Visible by Dominica DeGrandis Bhavin recommends Make Work Visible by Dominica DeGrandis because it goes beyond values and principles to put them into practice in a grounded, system-focused way. "One clear message I get from that book is it's not the people who are the problem, it's the system that we need to work on to improve ways of working," Bhavin shares. The book introduces concepts like the five thieves of time, visualizing work, dependencies, and bottlenecks — connecting lean thinking, Kanban principles, and behavioral patterns into a practical guide for any Scrum Master looking to understand the systems their teams operate in.   [The Scrum Master Toolbox Podcast Recommends]

Bhavin Shukla: When Protecting Your Agile Team Becomes the Barrier to Their Growth 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 perception I had was safe space means insulation from creating that transparency. It was not about protecting the teams. It was actually about giving them the voice, giving them the platform." - Bhavin Shukla   Bhavin shares a story from early in his Scrum Master journey, working with two teams building a BI and regulatory platform in Australia. When he arrived, team morale was low — people buried in their screens, going for coffee alone, no healthy debates happening. His natural instinct kicked in: protect the team, help them gel, get the best out of them. But his coach asked a question that changed everything: "What's the balance between protecting the team and creating visibility and transparency?" Bhavin realized he'd been shielding the team from stakeholders, keeping ceremonies closed and conversations siloed. When the team opened up their reviews to stakeholders with clear expectations, something shifted. The backlog started changing based on real feedback, healthy tension built up, and the team started humming. The lesson was profound — creating a safe space doesn't mean insulating the team from reality. Psychological safety isn't the absence of difficult emotions; it's the freedom to have them without destructive patterns. By isolating the team, Bhavin had actually been undermining their trust and growth.   Self-reflection Question: Are you protecting your team in ways that might actually be preventing them from building the stakeholder relationships and transparency they need to grow?   [The Scrum Master Toolbox Podcast Recommends]

Iryna Stelmakh: The Firewall Product Owner, Turning PO Anti-Patterns Into Opportunities for Growth 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 Great Product Owner: Market-Oriented and Vision-Driven "Great product owners don't just manage backlog items — they own the product vision and make sure the team understands how their work creates real value." — Iryna Stelmakh   Iryna describes the best product owners she's worked with through three qualities. First, they understand the market and the users deeply. Second, they can explain the business logic behind decisions — not just what to build, but why it matters. Third, they work closely with the team and treat them as partners in solving problems, not executors of tasks. The best PO Iryna worked with was responsible for sharing the business mindset, giving the team perspective and the possibility to contribute beyond the technical work. Everything was organized around a shared goal, and the team understood how their work created real value. As Vasco observes, when a PO just drops tasks without explaining why they matter, the team becomes "just a pair of hands." Great product owners create allegiance through understanding.   Self-reflection Question: Does your product owner share enough business context that your team could independently suggest features or improvements — or are they only able to execute what they're told? The Bad Product Owner: The Firewall Who Blocks All Business Context "We were working without the product mindset, without the product vision." — Iryna Stelmakh   Iryna shares the story of what she calls the Firewall Product Owner — a PO who constantly said "I need to go ask someone" for every decision, but never brought back answers. The result: backlog items lacked clarity, priorities changed frequently, and the team couldn't understand the real product direction. They were working without a product mindset or vision. As Vasco frames it, this PO wasn't just a proxy — they were a firewall, blocking the team from accessing any business context or market knowledge. The team couldn't reach the market representatives because they didn't even know who was on the other side.   Iryna's approach to this kind of situation: escalate with suggestions, not just complaints. Turn problems into opportunities and extensions — propose bringing in a business analyst to support the PO, or suggest restructuring the communication between the business and technical sides. In her case, the client eventually recognized the problem and replaced the PO with someone who could actually bridge the gap. The new PO changed everything.   In this episode, we also refer to the concept of turning problems into opportunities.   Self-reflection Question: When your product owner is unable to provide timely answers, do you escalate with specific suggestions for improvement — or do you simply wait and hope things get better?   [The Scrum Master Toolbox Podcast Recommends]  

Iryna Stelmakh: The Almost Invisible Scrum Master, Why Team Independence Is the Ultimate Success Metric 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 successful Scrum Master is almost invisible — not because they don't contribute, but because the team is no longer dependent on them for every decision." — Iryna Stelmakh   Iryna offers a powerful definition of success for Scrum Masters: becoming almost invisible. Not because the Scrum Master isn't contributing, but because the system works — with or without them. The team takes ownership of delivery, solves problems collaboratively, and continuously improves its own process. Each team member can propose, vote, and suggest changes because the environment has a high level of trust.   When that happens, Iryna explains, the Scrum Master becomes more of a system observer and catalyst rather than a daily driver. As Vasco adds, this perspective is valuable because it looks beyond personal metrics — it examines behaviors across all the interactions the Scrum Master facilitates: between the team and the product owner, between the team and stakeholders during reviews, and within the team itself. The Scrum Master role sits at the nexus of many interactions, and success means those interactions work well even when you step back.   Self-reflection Question: If you were absent for a full sprint, would your team maintain the same quality of collaboration, decision-making, and delivery — or would things fall apart without you? Featured Retrospective Format for the Week: The Energy Retrospective Iryna shares her favorite retrospective format — one she calls the Energy Retrospective. Instead of the standard "what went well / what didn't" framing, it asks three questions: What gave us energy this sprint? What drained our energy? And what should we start, stop, or continue doing to keep our energy at the right level?   This approach shifts the conversation from purely technical task problems to real human dynamics. As Iryna explains, closing technical tasks and resolving issues is important, but so is the wellness of the team. The Energy Retrospective creates space for both. She also notes that retrospective format should match the team: for open, trusting teams, a straightforward format works fine. But for new teams or teams with high resistance — those still in the forming stage where the Scrum Master isn't yet a trusted figure — she uses metaphorical approaches, like asking team members to pick pictures that represent their feelings about the sprint. Even a happy, sad, or frustrated monkey picture can surface insights that direct questions might not.   [The Scrum Master Toolbox Podcast Recommends]  

Iryna Stelmakh: Fighting Agile Theater, When Organizations Adopt the Ceremonies But Not the Mindset 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.   "Transparency can be uncomfortable, but without transparency, there is no real improvement." — Iryna Stelmakh   Iryna brings a challenge she calls "Agile Theater" — organizations that implement all the visible parts of Agile (the ceremonies, the boards, the terminology) while the underlying mindset remains unchanged. Decisions stay centralized, transparency is avoided, and problems are hidden. As she puts it: "Teams go through the emotions of Agile without actually benefiting from it."   But her real challenge goes deeper. Iryna shares a story about building trust with outsourcing clients. Five days into a new assignment on a project the company had worked on for over ten years, she received an email listing team members to be removed — with no explanation. It was a red flag: the absence of transparency signaled that the client relationship lacked the trust bridge needed for genuine collaboration.   Iryna's response was characteristically direct. She organized a call with stakeholders and discovered the client operated on quarterly budget cycles — these cuts could happen every three months. Instead of accepting the loss, she shifted the cut team members to other projects within the same account, turning the problem into an opportunity. A QA engineer moved to another project that needed one. A developer and two others got upsold into a team extension. Nobody ended up on the bench.   Then came the systemic fix: Iryna set up one-on-one meetings with each stakeholder across different divisions to stay informed in advance. Prevention over reaction — because, as she says, reactions cost more.   Self-reflection Question: In your current engagement, do you have direct relationships with the people who make budget and staffing decisions — or would a surprise email catch you completely off guard?   [The Scrum Master Toolbox Podcast Recommends]  

Iryna Stelmakh: When Communication Clarity Matters More Than Technical Complexity, A Healthcare Project That Fell 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.   "Communication clarity is more important than technical complexity, because if you do not understand, it's pretty hard to execute." — Iryna Stelmakh   Iryna shares one of her most painful career stories — a project in the healthcare domain focused on cancer treatment research data. When she joined, she was managing around 9 projects simultaneously and agreed to take this one on the condition that a strong technical lead would own the technical direction. The project began with a critical misunderstanding: sales had communicated that the client needed a database redesign, but the client actually needed a migration to a different database type. Similar words, fundamentally different work.   For three months, the team worked through research and discovery phases, trying to understand the actual problem. But communication gaps — compounded by language barriers between the Ukrainian development team and the US-based client — prevented them from identifying the real need in time. Iryna trusted the technical lead's reports that everything was on track. She relied instead of checking. Eventually, the client lost confidence and left. It remains the only project in her career she considers a genuine failure.   The lesson cuts deep: teams must have people who can ask the right questions early. As Vasco observes, the root cause was implicit assumptions that were never discovered or explored by the different people involved.   In this episode, we also talk about the importance of the monitoring and controlling phase in project management.   Self-reflection Question: When you trust a team member's assessment that "everything is fine," what verification steps do you take to confirm that understanding is truly shared across all stakeholders? Featured Book of the Week: Team Topologies by Matthew Skelton and Manuel Pais Iryna recommends Team Topologies by Matthew Skelton and Manuel Pais as a book that changed how she thinks about Agile leadership. "Great agile leadership is not only about frameworks, but it's about communication, influence, and the ability to align people around shared goals," she explains. The book helped her understand that Agile isn't just about team process — it's about organizational structure, team boundaries, and responsibilities. She also recommends Never Split the Difference by Chris Voss for Scrum Masters who want to sharpen their communication and influence tactics. As Iryna puts it, communication is one of the most important skills a Scrum Master must have.   [The Scrum Master Toolbox Podcast Recommends]  

Iryna Stelmakh: When "Agile" Becomes a License to Change Everything, The Cost of No Rules in Backlog Management 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.   "For me, it was pretty hard to explain that Agile is about cost reduction, and not about cost increasing." — Iryna Stelmakh   Iryna shares a story from one of her first projects as a Scrum Master, working with a client from Israel who saw Scrum as an open invitation to add anything to the backlog at any time. For this client, agility meant unlimited flexibility — the freedom to extend not just the product backlog but the sprint backlog, multiple times per sprint. As Vasco points out, this is a pattern many teams recognize: when there's no cost to disrupting a sprint, it becomes effortless to keep piling on work, destroying the very predictability that sprints are designed to create.   Iryna struggled to push back. It was one of her first projects, and the client was confident in his approach. But the experience taught her a lasting lesson: the collaboration with external clients must start with an agreement about how the team works. That means explaining the methodology during the pre-sale phase, documenting it in the contract, and teaching the client the benefits of the process before the work begins. As she puts it, when she checked back with the sales and engagement teams, she realized nobody had set those expectations. She relied instead of checking — and paid the price. Once she held sessions with the client to explain how Scrum works and what it delivers, things shifted. New tasks went into the product backlog and were prioritized properly through refinement, not dumped into active sprints.   Self-reflection Question: When was the last time you verified that your client or stakeholders truly understand how your team works — not just the label, but the actual rules and commitments?   [The Scrum Master Toolbox Podcast Recommends]  

BONUS: Why 98% of Innovation Fails Before It Reaches a Single Customer Lorraine Marchand has spent three decades helping organizations innovate in environments where failure carries real consequences. In this episode, she shares the frameworks, stories, and hard-won lessons from her time at IBM Watson Health and beyond — starting with the summer her father handed her a stopwatch and a problem to solve at a diner. The Sugar Cube That Started It All "At the age of 12, I learned that problem solving was fun. It was really safe to experiment, and it turned out to be lucrative, because we earned some revenue and royalties from our sugar cube."   Lorraine's innovation journey began with her father — a serial inventor who challenged his kids to identify and solve real problems. One summer, he took Lorraine and her brother to the Hot Shops Cafeteria in the Baltimore-Washington area with stopwatches, graph paper, and 3-color pens. Their assignment: figure out what was slowing down table turnover. After three days of observation and interviews with waitresses, busboys, and the manager, they discovered that sugar packets were the culprit — granules spilling over the table and floor during cleanup. Their solution, the Sugar Cube, was prototyped, sold to the manager, and eventually adopted across the chain — which later became the Marriott Corporation. The lesson stuck: innovation starts with observing problems close to the core, not chasing abstract ideas in a vacuum. Inside IBM Watson Health: Customer Co-Creation Over Engineering Brilliance "We have fallen in love with our solution. And we have not done our true problem-solving dissection and customer research to make sure that we're solving a problem that a customer wants to pay us to solve."   At IBM Watson Health, Lorraine worked with 250 world-class engineers building solutions for the biggest names in life sciences — Johnson & Johnson, Pfizer, Sanofi, Medtronic. The process started with "garage sessions" where the team would tackle problems directly with a reference customer. But a recurring tension emerged: engineering would want to take what they learned from one customer, disappear into a room, build the perfect solution, and then hand it to marketing to sell. Lorraine had to repeatedly pull them back. A reference customer is an N of 1 — solving their problem doesn't guarantee a marketplace need. The discipline was to keep the customer in lockstep at every stage and continuously open the aperture, bringing in more customers and more feedback to validate that the solution would work at scale. The Innovation Mindset: Four Components That Matter "Thinking outside of the box means that you step outside of your box and you step into someone else's box."   Lorraine identifies four components of the innovation mindset: problem solving, insatiable curiosity, embracing change, and welcoming diversity. The diversity piece is where most teams fall short. Homogenous groups become echo chambers — smart engineers designing from a technology perspective rather than a customer use perspective. The most innovative organizations Lorraine has worked with embrace cross-functional, multidisciplinary teams where engineering, marketing, and customer experience all have a seat at the table. No idea is a bad idea at the brainstorming stage — the down-selection comes later through structured evaluation. The Golden Ratio: Why 10% Drives 70% of Future Growth "Five years later, 70% of your growth will come from that 10% that you invested in innovation. So there's an inverse correlation to where you're investing and where that growth is going to come in the future."   Lorraine points to the Golden Ratio framework popularized by Sergey Brin at Google: invest 70% in core business, 20% in adjacencies and new markets, and 10% in net new, transformative ideas that might not work out. The data across companies over the last 15 years consistently shows that the 10% bet on innovation generates the majority of future growth. Companies that invest 100% in core and a little in adjacency stay stuck in single-digit growth. Making innovation a strategic imperative — with dedicated budget and dedicated talent — is what separates companies that break out from those that stagnate. Experimentation Done Right: Problem Statement First, Prototype Fast "You have to have a really solid problem statement. It has to be clear, measurable, significant, and actionable."   Good experimentation follows the scientific method. It starts with problem deconstruction — using first principles, the series of whys, or reframing to break down the problem until the statement is sharp enough to act on. From there, brainstorm solutions, down-select to the most promising one based on customer input, and build a minimal viable product. Lorraine emphasizes minimal — test the smallest feature possible, get it in front of customers quickly, capture the feedback, and loop it back into the next iteration. The continuous loop of learning is where real progress happens. The Watson Health Pivot: When the Customer Changes Everything "Even for me, it wasn't until we got this in the customer's hands and we were able to see how it was going to function in real life that we had the aha moment."   At IBM Watson Health, Lorraine's team was developing an algorithm for a large medical device company working on pain intervention. The software used a patient's mobile phone to detect mobility issues — how quickly they got up from a chair, how easily they opened a jar — and determine when to deliver pain relief through the device. The engineering was elegant, the reference customer loved it. But when they put the solution in the hands of actual physicians and patients in their homes, they discovered they were off track in how the tool would function in real life. The pivot was dramatic: instead of the medical device company, they partnered with a pharmaceutical company that used the algorithm to guide patients on when to take pain-related medication. The entire end customer changed — because they did the work of testing with real users. Reframing Failure as Learning "If failure's in your operating system, you're not going to try these experiments, and you're not going to be willing to get it wrong."   Lorraine's book No Fear, No Failure examines the strategic failure that holds companies back from innovating. One of the five C's in her framework is chance — the willingness to take calculated risks. The key is reframing experiments from "did we get it right or wrong?" to "what can we learn?" When teams set learning objectives for each experiment — what can I learn about this tool, about the customer, about how this works in practice — they remove the fear that prevents action and replace it with a process that compounds knowledge over time.   About Lorraine Marchand   Lorraine Marchand helps senior leaders innovate in high-cost-of-failure environments. An award-winning author, keynote speaker, and innovation advisor, she brings 30+ years of experience, including work at IBM Watson Health. Her book, No Fear, No Failure, offers practical frameworks for learning and growth without undue risk.   You can link with Lorraine Marchand on LinkedIn and find more of her work at LorraineMarchand.com.

BONUS: Why Every Organization Reinvents Silos—And What to Do About It Today we speak with Roland Flemm, co-creator of Org Topologies and co-author of 10X Org — Powered by Org Topologies. Roland has spent decades in the trenches—first as a developer, then in infrastructure, and finally as a Scrum Master, trainer, and organizational design consultant. In this episode, he explains why even teenagers with zero corporate experience instinctively create departmental silos, why making every team faster doesn't make the whole organization faster, and how leaders can use the Org Topologies map to see their organization as it actually is—not as the org chart says it should be. From Developer to Org Designer: Four Decades of Hitting the Same Wall "I felt many, many times the limitations of organizational structures stopping me from using my common sense to make people work together in a proper way."   Roland's career spans over 40 years, starting as a developer in 1984. After a decade writing code and another decade in infrastructure, he moved into Scrum and agile coaching. But even as a highly effective Scrum Master, he kept hitting the same ceiling: local team improvements couldn't break through organizational boundaries. You could have wins with your team, but the moment you needed multiple teams to work together, someone higher up would shut it down. That frustration led him to Large-Scale Scrum (LeSS) by Bas Vodde and Craig Larman, which offered a more educated approach to multi-team collaboration—and eventually to co-creating Org Topologies as a way to help leaders see and change the structures that block real collaboration. Bas has been on the podcast to share his view on scaling Scrum with LeSS, listen to his episode here. The Hydrogen Car That Built Its Own Silos "If you don't think about your org design—the way that you want to collaborate—then something like this happens."   One of the most striking stories in Roland's book comes from the Technical University of Delft, where student engineers were thrown together to build a hydrogen racing car. These were teenagers—no corporate experience, no boss who'd worked in a traditional company. And within weeks, they'd organized themselves into departmental silos, each sticking to their specialty. The mechanical engineers stayed on their turf, the electrical engineers on theirs. It was automatic. Roland traces this instinct deep: from school, where you choose a specialty; from the army and the church, where hierarchy is the default; from society itself, where "you're a plumber, so then we know what you are." The pattern of drawing boundaries and appointing leads when faced with complexity isn't corporate culture—it's human nature. And the problem isn't that it exists. The problem is that we don't know there are alternatives. The Ferrari Effect: Why Local Speed Creates Global Congestion "It's not that people choose to do fewer things. They just push more into the system because it can handle it. And that's where things go wrong."   Roland uses a vivid analogy from the book: swapping every car on the road for a Ferrari doesn't fix traffic congestion. The same principle applies in organizations. Everyone feels faster individually—teams are delivering, sprints are moving—but the whole isn't getting better. The HealthCare.gov story makes the case dramatically: 55 vendor firms, $1.7 billion in spending, and on launch day, six people successfully enrolled. Then a ten-person cross-functional team fixed it in six weeks. Roland sees this pattern repeat in banks that adopt delivery-oriented structures like SAFe: they create value streams, but because they don't make hard choices about what not to do, the freed-up coordination capacity immediately fills with new demands. The congestion returns, just at a different level. In this segment, we talk about the Cynefin Framework.  Three Topologies: Resource, Delivery, and Adaptive "The third topology is interesting—that's where the hands and the heads are merged. They're no longer separated."   Roland walks through the Org Topologies map, each suited to different contexts:   Resource Topology — The "hands" are separated from the "heads." Coordinators design and direct; specialists execute narrow, deep tasks. This works in environments with low variability and deep technical expertise—think ASML's university-level hardware engineers, or a bank's core transaction processing team running COBOL. The focus is on utilization of expensive specialists.   Delivery Topology — Still has coordination overhead, but teams are cross-functional and can handle more complex problems end to end. A team owns the customer page and does design, testing, and deployment. This model favors speed of delivery, but breaks down when new work doesn't fit neatly onto existing value streams—like needing a retention initiative when no retention team exists. Work falls through the cracks.   Adaptive Topology — The hands and heads merge. People who coordinate can also do the work, and they self-organize around problems as they emerge. It's like a startup—"four guys and a dog in a garage"—but with hundreds of people. This model thrives in high-variability, high-learning environments where the investment in cross-training pays off because the challenges keep changing.   The key insight: none of these is "better." It's about fit for purpose. A single organization—like a large bank—might need all three topologies operating simultaneously in different parts of the business. The MADE Loop: Map, Assess, Design, Elevate "First, we all agree that the system that we're looking at is really the system that we're looking at. And then we can start talking about how to improve."   Rather than the typical transformation playbook—hire consultants, roll out a framework, hope for the best—Roland advocates for the MADE loop: Map the reality of how work actually flows (not what the org chart says), Assess whether that structure is fit for the strategic purpose, Design targeted improvements using the Org Topologies map, and Elevate through small experiments. Maybe two teams temporarily share members. Maybe one person switches team membership for a sprint. The changes are gradual, measurable, and reversible. Roland is emphatic about one principle from the book: "Own, Not Rent." Real structural change can't be outsourced to a consulting firm. Leaders have to see the system themselves—go to where the work happens, understand the flow, and make informed choices about what to change. AI Is About to Reshape the Map "As AI comes, you might want to get at least a part of that work transferred lower in the organization to more execution-oriented teams, because they can now use resources like AI to make proper decisions."   Roland makes a forward-looking point about how AI will shift the boundaries between topologies. Work that required deep specialist silos—like legal review or compliance decisions—may soon be handleable by cross-functional teams using AI tools. This means the threshold for when an adaptive or delivery topology makes sense will shift. Organizations that understand their current topology will be better positioned to adapt; those that don't will find their structures obsolete without understanding why.   About Roland Flemm   Roland Flemm is co-creator of Org Topologies and co-author of 10X Org — Powered by Org Topologies (2026) — a framework and book about elevating organizational performance through people-centered, strategy-driven redesign. He works with leaders in scale-ups and enterprises across Europe, helping them see how their org structure shapes — or blocks — their ability to learn, adapt, and deliver.   You can link with Roland Flemm on LinkedIn. Learn more about Roland's work at 10xorg and https://www.orgtopologies.com

BONUS: Katie Anderson, Toyota's Real Secret Isn't the Tools — It's the Attitude Towards Learning That Changes Everything Katie Anderson joins us to explore the real engine behind Toyota's legendary success — and it's not what most people think. Drawing from her years living in Japan and her close relationship with 40-year Toyota veteran Isao Yoshino, Katie reveals why tools alone will never create lasting transformation. We explore the Doer Trap, the Telling Habit, and why hansei (deep reflection) is the most productive practice leaders keep skipping. The Only Secret to Toyota "The only secret to Toyota is its attitude towards learning. We don't even notice, and we take it for granted."   Katie moved to Japan over 11 years ago as a continuous improvement practitioner and got to know Isao Yoshino, a Toyota leader with 40 years of experience. After repeatedly asking him what made Toyota so successful, he finally offered an almost offhand answer: "The only secret to Toyota is its attitude towards learning." The deeper insight? Even inside Toyota, they barely noticed it — it was so embedded in how they worked that they took it for granted. Katie explains that most organizations copy the visible tools — the kanban boards, the value streams, the process maps — but miss the invisible layer underneath: people development. Without that foundation of learning, tools lead to project-based improvements that never sustain. The secret sauce is the quality of how organizations develop people to learn, contribute, problem-solve, and innovate. That system of people development underlies the system of process improvement, and without it, organizations stay stuck in what Katie calls "constant whack-a-mole" — fixing the same problems year after year. The Doer Trap and the Five Archetypes "The doer trap is when we're stepping in and doing things, or owning things that aren't ours to own."   Katie identifies five archetypes of the Doer Trap that leaders and change agents fall into. The Hero is the firefighter who jumps from crisis to crisis — it feels good to save the day. The Rescuer can't stand watching people struggle, so they give answers too early, robbing others of the chance to develop their own thinking. The Magician works behind the scenes, subtly shaping outcomes without others' input. The Pair of Hands just jumps in and gets it done because "it's faster." And the Surrogate Leader fills a leadership vacuum that isn't theirs to fill — so when they move on, everything fades away. Each archetype feels productive in the moment but prevents the organization from building real capability. The shift Katie advocates is from command-based leadership to influence-based leadership: still setting direction, but creating the conditions for others to find the way there. Break the Telling Habit "The telling habit is when we're giving our answer instead of holding space for someone else to develop their answer."   Closely linked to the Doer Trap, the Telling Habit is about how leaders — and change agents — default to providing their own ideas, suggestions, and solutions instead of creating space for others to think. Katie sees this show up even in well-intentioned coaches and consultants. The antidote aligns with what David Marquet calls intent-based leadership: instead of telling people what to do, you validate their thinking and ask questions when you spot gaps. Katie frames good leadership through three responsibilities drawn from Mr. Yoshino's example: set the direction (what goal needs to be achieved), provide support (create the capability and conditions for people to succeed), and develop yourself (because if you can't see the system, you can't help others see it either). Learning as Sustainable Competitive Advantage "We need to set up experiments. And experiments are fundamentally based on an attitude towards learning."   Katie argues that as complexity increases, no single leader can hold all the answers. Organizations need to harness what you might call the collective brain — the hive mind of the team — and that requires an experimental mindset. This connects directly to Jeffrey Liker's concept of organizations as socio-technical systems: it's never just the technical processes that matter, but how people interact, influence each other, and navigate the formal and informal structures that actually get things done. Katie's advice to change leaders: develop your own systems thinking skills first. Help leaders see what's really driving behavior — reward structures, people development gaps, the difference between compliance and genuine capability. Everything starts with you. Hansei — Reflection as the Most Productive Practice "The study and adjust part of the cycle is where the learning happens. But we keep cutting it because the doing part feels more productive."   Hansei — Japanese for deep self-reflection — goes far beyond the typical retrospective. Where most teams do a surface-level "what worked, what didn't, let's move on," hansei asks: what did we expect to happen? What were our assumptions? What behaviors drove the outcome? Katie points out that Toyota schedules reflection time deliberately — both large-scale and small-scale — and sticks to it. That discipline is part of their attitude towards learning. She advocates reframing the PDSA cycle as Study-Adjust-Plan-Do, because the reflection should come first, not as an afterthought. At Toyota, PDCA operates at every level: micro-kaizen on the factory floor daily, A3 reports for structured problem-solving, and Hoshin Kanri for annual and five-year strategy deployment. The mindset of experimentation, paired with disciplined reflection, is what makes continuous improvement actually continuous.   About Katie Anderson   Katie Anderson is an internationally recognized keynote speaker, award-winning author, and leadership consultant who helps organizations achieve extraordinary results through continuous learning. She partners with executives and change leaders to build learning cultures, strengthen leadership capability, and drive sustainable success by aligning purpose, developing people, and fostering curiosity, courage, and meaningful transformation.   You can link with Katie Anderson on LinkedIn and visit her website at kbjanderson.com. Listen to her podcast, Chain of Learning.

BONUS: How to Build Teams That Think, Own, and Execute Without Burnout What if the problem isn't your people—but how your leadership shows up? In this episode, Sid Jashnani unpacks how Agile thinking, EOS (the Entrepreneurial Operating System), and his DELTA Delegation Ladder can help leaders build teams that truly own outcomes, execute without micromanagement, and grow the business—without burning out leaders or teams. The Breaking Point: When Smart People Don't Own Outcomes "I realized that I was the system, I was the bottleneck. And I was the one orchestrating everything. And if I were to step away for just going for dinner with my family, I would still get a call from someone."   Around 2014, Sid was running a thriving systems integration company with great people—people he trusted and loved working with. But they weren't owning outcomes. They were busy, but not always productive. Every decision fell back on Sid, and when the calls kept coming during family dinners, he started responding with irritation and sarcasm—a leadership pattern he knew was unsustainable. That moment of self-awareness became the catalyst for change. Sid realized the problem wasn't his team's competence; it was his inability to get them aligned, accountable, and clear on expectations.  That's when he discovered EOS—a business operating system created by Gino Wickman that orchestrates how you set priorities, run meetings, connect with your team, and track your numbers. Over the next few years, implementing EOS across his organization brought the clarity, accountability, and discipline his business needed. Where Agile and EOS Overlap: Trust Through Structure "The real overlap is trust through structure. If there's no structure, then I'm not accountable to you. I can do whatever."   Sid sees deep parallels between Agile and EOS. Both are allergic to hero culture. Both push decisions as close to the work as possible. Both rely on cadence—sprints, weekly meetings, daily stand-ups—to create rhythm without micromanagement. And both use visibility, numbers, and scorecards to keep teams aligned. But the real overlap, as Sid frames it, is trust through structure. In EOS, teams are structured through an accountability chart: who owns what outcome, who reports to whom, and how success is defined for each role. Without that structure, accountability becomes optional, and without accountability, trust never forms. Sid connects this directly to Patrick Lencioni's The Five Dysfunctions of a Team—where trust sits at the base of the pyramid, enabling healthy conflict, commitment, accountability, and ultimately results. The key anti-pattern Sid warns about: people picking only the comfortable parts of a system and relaxing the parameters so much that it becomes "SOS—Sid's Operating System—which is just an emergency call for help." In this episode, we also refer to Traction, by Gino Wickman, a foundational book for Sid in his career.  The DELTA Delegation Ladder: From Command-and-Control to Co-Founder Mode "Delegation fails because leaders skip levels."   Sid introduces his DELTA Delegation Ladder—a five-level framework for understanding where your team members sit and how to delegate accordingly:   D — Do as I say: Pure execution of instructions. Sid notes this level is increasingly being replaced by AI. E — Explore the possible solutions: Research and present options, but the leader still makes the decision. Also increasingly delegable to AI. L — Lead with a recommendation: The entry point for real human value. The person researches, forms a hypothesis, and recommends a path forward. Sid considers this the minimum hiring bar. T — Take action with oversight: The person takes decisions and acts, keeping the leader in the loop. Trust has been built through coaching and mentoring. A — Autonomous execution: Co-founder mode. The person owns the outcome end-to-end. Full trust, full ownership.   Delegation fails when leaders skip levels—expecting someone at "D" to operate at "A." It also fails when leaders abdicate rather than delegate, throwing someone into a role without investing time in coaching, clarifying expectations, or showing them what "great" looks like. As Sid puts it: delegation only works if you spend time with the person you're delegating to. Remote Teams: Written Clarity Beats Verbal Alignment "Trust comes from predictability, not proximity. I can be 1,000 miles across the world from you and trust you, because I can predict what your actions are gonna be."   For distributed and cross-timezone teams, Sid's non-negotiables are clear: get good at writing, and over-communicate. Written clarity beats verbal alignment every time, especially across cultures where tone and directness vary widely—from British politeness to Dutch directness. Over-communication isn't a flaw; it's the standard for remote teams. Without it, accountability vanishes and culture erodes. Sid points out that trust in remote settings comes from predictability—can you predict that someone will hit their milestones, complete their to-dos, and follow through?—not from physical proximity. Someone sitting next to you who consistently misses deadlines will never earn your trust, while someone across the world who reliably delivers will.   Self-reflection Question: Where on the DELTA Delegation Ladder are the people you're currently delegating to—and are you investing the time and coaching they need to move up, or are you skipping levels and hoping for miracles?   About Sid Jashnani Sid is a founder, operator, and growth advisor who scaled a systems integration firm into a portfolio of IT businesses. After struggling with delegation and predictability, EOS transformed how he led. Through Outgrow, Sid helps founders drive 15–30% predictable growth with disciplined execution and proactive customer communication.   You can link with Sid Jashnani on LinkedIn.   You can also read his weekly newsletter, Leadership Bytes Weekly on Substack.

BONUS: Guardrails Over Processes—How to Scale Teams Without Killing Creativity What actually slows down tech teams—lack of talent, or lack of ownership? In this episode, Prashanth Tondapu shares lessons from leading through global-scale failures, scaling from a small team to a 100-person company, and discovering why guardrails beat rigid processes when it comes to building teams that own outcomes and execute with discipline. Diffusion of Accountability: When Everyone Is Responsible, Nobody Is "Crisis is not the problem. Crisis is the one that uncovers the problem that has always existed."   Early in his career, Prashanth witnessed a large-scale failure at a major technology company—not because the team lacked talent, but because accountability had become diffused. When too many people are responsible for something, it translates to nobody being responsible. The team was brilliant individually, but there was no clear demarcation of who owned what outcome. On good days, everything worked. But when things went wrong, there was no single person who could no longer delegate accountability to someone else. In this segment, we also refer to the concept from Extreme Ownership by Jocko Willink. Prashant argues for: outcome can only come with 100% emotional commitment to a particular problem, and when five people share that commitment, each carries only 20%. That's where breakdowns happen. The Leadership Design Problem: From Computers to People "I was a developer who imagined that humans are also going to be as predictable as computers. Until 6 or 7 people, it works well because you can be everywhere. But as soon as we increased above 7, I was not able to be everywhere."   Prashanth's journey as a founder mirrors what many tech leaders experience at scale. Starting Innostax at 27 as a developer with no management experience, he initially treated people like predictable systems. Below seven people, it worked—he could be the hero founder, the catch-all. But beyond that threshold, he had to learn delegation, which meant learning to trust. First came the people-dependent phase, then the process-oriented phase with SOPs (Standard Operating Procedures) for everything—even how APIs should look. The SOPs made the team fast at execution, but their clients noticed something troubling: "Your guys do not even ask any questions." The rigid processes had suppressed the very creativity and critical thinking they needed. That feedback became the catalyst for the next evolution: becoming a people-first company. Guardrails vs. Processes: Freeing Creativity Within Structure "If something goes wrong, our guardrail is: we will just ask you one question—what was your intent behind doing this?"   Prashanth draws a sharp distinction between processes and guardrails. Processes tell you exactly what to do and how to do it—they create predictable execution but kill creativity. Guardrails define the boundaries within which people have freedom to be creative and solve problems their own way. At Innostax, guardrails take practical forms:   Time-on-task guardrails: If a task takes longer than expected, ask for help—don't rabbit-hole into it for three days Don't be a hero: When friction appears with a client or a problem, escalate early rather than trying to solve everything alone The intent review: When something goes wrong, instead of punishment, they ask three questions—was the intent right, was the approach right, and what was the outcome? If intent and approach were right but it still failed, that's the company's problem, not the individual's   This framework creates psychological safety while maintaining accountability. People know they won't be penalized for honest mistakes made with good intent, which means they surface problems early rather than hiding them. Vision Elements and the People-First Company "The outcome is not just what is expected, but outcome also consists of what is not expected. People come out in so many creative, great ways that they end up surprising you."   The shift to a people-first company meant replacing rigid SOPs with what Prashanth calls "vision elements"—broader directional guidance like "we are working for the client, we need to give the best for the client in the resources that we have." This gives teams a larger sandbox to work in while guardrails prevent them from going too far off course.  The daily rhythm includes team leads reviewing work summaries—not to micromanage, but to catch misalignment early and offer support. Prashanth emphasizes that guardrails must be created with emotional intelligence and detachment. If you create guardrails assuming you're also part of the problem, they'll be biased and ineffective. That's why he considers emotional intelligence the prerequisite skill for any leader designing team structures. The Books That Changed Everything "Whenever I was reading through the fixed mindset guy, it was like it was describing me. And that actually changed everything."   Prashanth recommends two foundational books for leaders building ownership-driven teams. First, Mindset by Carol Dweck—a book that cracked his own fixed mindset as a confident developer who thought he knew everything. Reading about the fixed mindset felt like reading his own biography, and that uncomfortable recognition opened him to listening more, seeking exposure to experts, and believing there were perspectives he hadn't encountered yet. Second, Emotional Intelligence by Daniel Goleman—because without mastering emotional intelligence, everything you hear feels personal, clouding your judgment and making you too close to the problem to design effective solutions for your team.   Self-reflection Question: Are you building guardrails that give your team freedom to be creative within clear boundaries, or are you still writing processes that tell people exactly what to do—and in the process, suppressing the very thinking you hired them for?   About Prashanth Tondapu Prashanth Tondapu is Founder and CEO of Innostax and a veteran technology leader. He's led teams through high-stakes global incidents at McAfee and scaled disciplined delivery organizations worldwide. His work focuses on ownership, accountability, and designing teams for predictable, sustainable execution as complexity grows.   You can link with Prashanth Tondapu on LinkedIn.

BONUS: Why the Spotify Model Didn't Work (Even at Spotify) Imagine a company that spends a year building an iPad app—and on launch day the product owner says: "Now it'll be interesting to see IF anyone uses it." In this episode, Marcus Hammarberg and Tore Fjaertoft share why organizations keep installing frameworks like software, why it still doesn't work, and what they've learned from places like Spotify about treating your way of working as a product in itself. When Copying Without Adopting Becomes the Norm "It becomes more about following whatever this framework tells you to do, rather than to understand what the problem you're trying to solve is all about."   Marcus and Tore met at a consultancy in Malmö and within 15 minutes realized they shared the same frustrations—despite coming from opposite directions. Marcus comes from the ground up as a software developer and coach, while Tore works top-down with leadership teams on product organization design. Both had worked at Spotify and both had seen organizations copy famous frameworks and models without adopting the underlying mindset. The telltale sign, as Tore describes it, is when people focus on compliance rather than being pragmatic—following the manual without questioning whether the way they're working is actually serving the organization. As Marcus frames it through Cynefin, product development lives in a domain where best practices don't even exist—only emergent practices that you discover by trying things out. Treat Your Process Like a Product "The easiest way for us to explain things has been: take the mindset you use for your product, and then use that same mindset when you're approaching how you set things up and how you work internally."   The core idea Marcus and Tore keep returning to is deceptively simple: see the way you operate as a product in and of itself. Just as a digital product is never finished—you ship it, observe how customers use it, and evolve accordingly—your operating model should follow the same cycle. Tore explains that the "customers" of your process are your employees: they need less friction, more empowerment, and the ability to spend more time on work that actually moves the needle for users. Marcus connects this to the lean concept of True North—a shared direction that everyone understands, so that every experiment and process change moves the organization closer to what matters. He contrasts this with the three Agile transformations he participated in that all had the same misguided tagline: "get more out of our development organization." As Marcus points out, even the AI DORA report shows developers feeling more productive individually—but is individual productivity really the goal? The Factory Floor Story: Empowerment Needs Alignment "Everyone down here knows that anything we do needs to be the best in the world, in every step."   Marcus shares a powerful story from a Swedish lorry factory where workers changed their workstation instructions several times a day—written on a whiteboard with a pen, not locked in a manual. When asked how they got everyone to engage in continuous improvement, the factory managers didn't understand the question. Every worker on the floor knew they were building the most expensive lorry in the world, and they wanted it to stay the best. That shared purpose drove improvement without mandates.  But Marcus is quick to add the counterbalance: empowerment without alignment leads to local optimization. The factory combined local metrics with overarching flow metrics, so everyone could see how their station fit into the whole chain. Marcus and Tore distill this into three interconnected principles: empowerment to enable people to change how they work, alignment to steer toward shared outcomes, and collaboration to prevent teams from optimizing in isolation. From Static Frameworks to Dynamic Ways of Working "We realized that Spotify didn't use the Spotify model. They moved on, because they see the way they work as a continuously evolving approach."   Tore reveals one of the most striking lessons from their Spotify experience: the company that accidentally created "the Spotify model" had already moved beyond it by the time the rest of the world started copying it. The reason? Spotify treated its way of working as something that continuously evolves—not a static blueprint to install and follow. Marcus adds a practical example from Spotify: on your first day, you got access to the company's key metrics. Everyone knew the True North—at the time, increasing monthly active users—and every process change, every experiment, every team decision was oriented toward that outcome. The contrast with organizations that "install" a framework and then wonder why it doesn't work couldn't be sharper. As Marcus puts it: "We tried process X, it didn't work. We tried process Y, the opposite, and that didn't work either. Why doesn't the process work?" The answer is that the "how" must emerge over time, guided by a clear "why." Always Know Why You're Doing What You're Doing "I don't want anyone to work on anything if you don't know why."   Tore shares a policy from a product management colleague at Spotify: every single day, everyone on his team should be able to articulate not just what they're working on, but why—and the "why" could not be "because person XYZ told me to." It had to connect to the company's purpose and users. Marcus takes this even further, recounting how he once stopped productivity at an entire company by telling developers: don't work on anything unless you know why. Nobody could continue. The uncomfortable silence that followed became a powerful catalyst for change. With an 80% failure rate for product experiments being the industry standard, packaging that risk into year-long projects is a recipe for the iPad app scenario they opened with. The alternative is to build the organizational muscle for rapid experimentation—cheap hypotheses, fast feedback, and the humility to let outcomes guide the way forward.   Self-reflection Question: When was the last time you asked your team—or yourself—"why are we doing this?" and got an answer that connected to a real business or user outcome rather than "because the framework says so"?   About Marcus Hammarberg and Tore Fjaertoft Marcus Hammarberg is a product and software coach and consultant who has seen product organizations from the inside and from the trenches. He works at Humane, part of the ADRA consulting collective, and has experience from Spotify, Tradera, and multiple Agile transformations across banks and insurance companies.   Tore Fjaertoft is a product organization advisor who works with leadership teams on how product thinking actually scales in large, complex companies. He works at Above, also part of the ADRA consulting collective, and has experience from Spotify and Volvo Cars.   You can link with Marcus Hammarberg on LinkedIn and Tore Fjaertoft on LinkedIn.

BONUS: Why the Human Architect Still Matters—AI-Assisted Coding for Production-Grade Software How do you build mission-critical software with AI without losing control of the architecture? In this episode, Ran Aroussi returns to share his hands-on approach to AI-assisted coding, revealing why he never lets the AI be the architect, how he uses a mental model file to preserve institutional knowledge across sessions, and why the IDE as we know it may be on its way out. Vibe Coding vs AI-Assisted Coding: The Difference Shows Up When Things Break "The main difference really shows up later in the life cycle of the software. If something breaks, the vibe coder usually won't know where the problem comes from. And the AI-assisted coder will."   Ran sees vibe coding as something primarily for people who aren't experienced programmers, going to a platform like Lovable and asking for a website without understanding the underlying components. AI-assisted coding, on the other hand, exists on a spectrum, but at every level, you understand what's going on in the code. You are the architect, you were there for the planning, you decided on the components and the data flow. The critical distinction isn't how the code gets written—it's whether you can diagnose and fix problems when they inevitably arise in production. The Human Must Own the Architecture "I'm heavily involved in the... not just involved, I'm the ultimate authority on everything regarding architecture and what I want the software to do. I spend a lot of time planning, breaking down into logical milestones."   Ran's workflow starts long before any code is written. He creates detailed PRDs (Product Requirements Documents) at multiple levels of granularity—first a high-level PRD to clarify his vision, then a more detailed version. From there, he breaks work into phases, ensuring building blocks are in place before expanding to features. Each phase gets its own smaller PRD and implementation plan, which the AI agent follows. For mission-critical code, Ran sits beside the AI and monitors it like a hawk. For lower-risk work like UI tweaks, he gives the agent more autonomy. The key insight: the human remains the lead architect and technical lead, with the AI acting as the implementer. The Alignment Check and Multi-Model Code Review "I'm asking it, what is the confidence level you have that we are 100% aligned with the goals and the implementation plan. Usually, it will respond with an apologetic, oh, we're only 58%."   Once the AI has followed the implementation plan, Ran uses a clever technique: he asks the model to self-assess its alignment with the original goals. When it inevitably reports less than 100%, he asks it to keep iterating until alignment is achieved. After that, he switches to a different model for a fresh code review. His preferred workflow uses Opus for iterative development—because it keeps you in the loop of what it's doing—and then switches to Codex for a scrutinous code review. The feedback from Codex gets fed back to Opus for corrections. Finally, there's a code optimization phase to minimize redundancy and resource usage. The Mental Model File: Preserving Knowledge Across Sessions "I'm asking the AI to keep a file that's literally called mentalmodel.md that has everything related to the software—why decisions were made, if there's a non-obvious solution, why this solution was chosen."   One of Ran's most practical innovations is the mentalmodel.md file. Instead of the AI blindly scanning the entire codebase when debugging or adding features, it can consult this file to understand the software's architecture, design decisions, and a knowledge graph of how components relate. The file is maintained automatically using hooks—every pre-commit, the agent updates the mental model with new learnings. This means the next AI session starts with institutional knowledge rather than from scratch. Ran also forces the use of inline comments and doc strings that reference the implementation plan, so both human reviewers and future AI agents can verify not just what the code does, but what it was supposed to do. Anti-Patterns: Less Is More with MCPs and Plan Mode "Context is the most precious resource that we have as AI users."   Ran takes a minimalist approach that might surprise many developers:   Only one MCP: He uses only Context7, instructing the AI to use CLI tools for everything else (Stripe, GitHub, etc.) to preserve context window space No plan mode: He finds built-in plan mode limiting, designed more for vibe coding. Instead, he starts conversations with "I want to discuss this idea—do not start coding until we have everything planned out" Never outsource architecture: For production-grade, mission-critical software, he maintains the full mental model himself, refusing to let the AI make architectural decisions The Death of the IDE and What Comes Next "I think that we're probably going to see the death of the IDE."   Ran predicts the traditional IDE is becoming obsolete. He still uses one, but purely as a file viewer—and for that, you don't need a full-fledged IDE. He points to tools like Conductor and Intent by Augment Code as examples of what the future looks like: chat panes, work trees, file viewers, terminals, and integrated browsers replacing the traditional code editor. He also highlights Factory's Droids as his favorite AI coding agent, noting its superior context management compared to other tools. Looking further ahead, Ran believes larger context windows (potentially 5 million tokens) will solve many current challenges, making much of the context management workaround unnecessary.   About Ran Aroussi Ran Aroussi is the founder of MUXI, an open framework for production-ready AI agents, co-creator of yfinance, and author of the book Production-Grade Agentic AI: From brittle workflows to deployable autonomous systems. Ran has lived at the intersection of open source, finance, and AI systems that actually have to work under pressure—not demos, not prototypes, but real production environments.   You can connect with Ran Aroussi on X/Twitter, and link with Ran Aroussi on LinkedIn.