Scrum Master Toolbox Podcast

BONUS: The Operating System for Software-Native Organizations - The Five Core Principles In this BONUS episode, the final installment of our Special Xmas 2025 reflection on Software-native businesses, we explore the five fundamental principles that form the operating system for software-native organizations. Building on the previous four episodes, this conversation provides the blueprint for building organizations that can adapt at the speed of modern business demands, where the average company lifespan on the S&P 500 has dropped from 33 years in the 1960s to a projected 12 years by 2027. The Challenge of Adaptation "What we're observing in Ukraine is adaptation happening at a speed that would have been unthinkable in traditional military contexts - new drone capabilities emerge, countermeasures appear within days, and those get countered within weeks." The opening draws a powerful parallel between the rapid adaptation we're witnessing in drone warfare and the existential threats facing modern businesses. While our businesses aren't facing literal warfare, they are confronting dramatic disruption. Clayton Christensen documented this in "The Innovator's Dilemma," but what he observed in the 1970s and 80s is happening exponentially faster now, with software as the accelerant. If we can improve businesses' chances of survival even by 10-15%, we're talking about thousands of companies that could thrive instead of fail, millions of jobs preserved, and enormous value created. The central question becomes: how do you build an organization that can adapt at this speed? Principle 1: Constant Experimentation with Tight Feedback Loops "Everything becomes an experiment. Not in the sense of being reckless or uncommitted, but in being clear about what we're testing and what we expect to learn. I call this: work like a scientist: learning is the goal." Software developers have practiced this for decades through Test-Driven Development, but now this TDD mindset is becoming the ruling metaphor for managing products and entire businesses. The practice involves framing every initiative with three clear elements: the goal (what are we trying to achieve?), the action (what specific thing will we do?), and the learning (what will we measure to know if it worked?). When a client says "we need to improve our retrospectives," software-native organizations don't just implement a new format. Instead, they connect it to business value - improving the NPS score for users of a specific feature by running focused retrospectives that explicitly target user pain points and tracking both the improvements implemented and the actual NPS impact. After two weeks, you know whether it worked. The experiment mindset means you're always learning, never stuck. This is TDD applied to organizational change, and it's powerful because every process change connects directly to customer outcomes. Principle 2: Clear Connection to Business Value "Software-native organizations don't measure success by tasks completed, story points delivered, or features shipped. Or even cycle time or throughput. They measure success by business outcomes achieved." While this seems obvious, most organizations still optimize for output, not outcomes. The practice uses Impact Mapping or similar outcome-focused frameworks where every initiative answers three questions: What business behavior are we trying to change? How will we measure that change? What's the minimum software needed to create that change? A financial services client wanted to "modernize their reporting system" - a 12-month initiative with dozens of features in project terms. Reframed through a business value lens, the goal became reducing time analysts spend preparing monthly reports from 80 hours to 20 hours, measured by tracking actual analyst time, starting with automating just the three most time-consuming report components. The first delivery reduced time to 50 hours - not perfect, but 30 hours saved, with clear learning about which parts of reporting actually mattered. The organization wasn't trying to fulfill requirements; they were laser focused on the business value that actually mattered. When you're connected to business value, you can adapt. When you're committed to a feature list, you're stuck. Principle 3: Software as Value Amplifier "Software isn't just 'something we do' or a support function. Software is an amplifier of your business model. If your business model generates $X of value per customer through manual processes, software should help you generate $10X or more." Before investing in software, ask whether this can amplify your business model by 10x or more - not 10% improvement, but 10x. That's the threshold where software's unique properties (zero marginal cost, infinite scale, instant distribution) actually matter, and where the cost/value curve starts to invert. Remember: software is still the slowest and most expensive way to check if a feature would deliver value, so you better have a 10x or more expectation of return. Stripe exemplifies this principle perfectly. Before Stripe, accepting payments online required a merchant account (weeks to set up), integration with payment gateways (months of development), and PCI compliance (expensive and complex). Stripe reduced that to adding seven lines of code - not 10% easier, but 100x easier. This enabled an entire generation of internet businesses that couldn't have existed otherwise: subscription services, marketplaces, on-demand platforms. That's software as amplifier. It didn't optimize the old model; it made new models possible. If your software initiatives are about 5-10% improvements, ask yourself: is software the right medium for this problem, or should you focus where software can create genuine amplification? Principle 4: Software as Strategic Advantage "Software-native organizations use software for strategic advantage and competitive differentiation, not just optimization, automation, or cost reduction. This means treating software development as part of your very strategy, not a way to implement a strategy that is separate from the software." This concept, discussed with Tom Gilb and Simon Holzapfel on the podcast as "continuous strategy," means that instead of creating a strategy every few years and deploying it like a project, strategy and execution are continuously intertwined when it comes to software delivery. The practice involves organizing around competitive capabilities that software uniquely enables by asking: How can software 10x the value we generate right now? What can we do with software that competitors can't easily replicate? Where does software create a defensible advantage? How does our software create compounding value over time? Amazon Web Services didn't start as a product strategy but emerged from Amazon building internal capabilities to run their e-commerce platform at scale. They realized they'd built infrastructure that was extremely hard to replicate and asked: "What if we offered it to others?" AWS became Amazon's most profitable business - not because they optimized their existing retail business, but because they turned an internal capability into a strategic platform. The software wasn't supporting the strategy - the software became the strategy. Compare this to companies that use software just for cost reduction or process optimization - they're playing defense. Software-native companies use software to play offense, creating capabilities that change the competitive landscape. Continuous strategy means your software capabilities and your business strategy evolve together, in real-time, not in annual planning cycles. Principle 5: Real-Time Observability and Adaptive Systems "Software-native organizations use telemetry and real-time analytics not just to understand their software, but to understand their entire business and adapt dynamically. Observability practices from DevOps are actually ways of managing software delivery itself. We're bootstrapping our own operating system for software businesses." This principle connects back to Principle 1 but takes it to the organizational level. The practice involves building systems that constantly sense what's happening and can adapt in real-time: deploy with feature flags so you can turn capabilities on/off instantly, use A/B testing not just for UI tweaks but for business model experiments, instrument everything so you know how users actually behave, and build feedback loops that let the system respond automatically. Social media companies and algorithmic trading firms already operate this way. Instagram doesn't deploy a new feed algorithm and wait six months to see if it works - they're constantly testing variations, measuring engagement in real-time, adapting the algorithm continuously. The system is sensing and responding every second. High-frequency trading firms make thousands of micro-adjustments per day based on market signals. Imagine applying this to all businesses: a retail company that adjusts pricing, inventory, and promotions in real-time based on demand signals; a healthcare system that dynamically reallocates resources based on patient flow patterns; a logistics company whose routing algorithms adapt to traffic, weather, and delivery success rates continuously. This is the future of software-native organizations - not just fast decision-making, but systems that sense and adapt at software speed, with humans setting goals and constraints but software executing continuous optimization. We're moving from "make a decision, deploy it, wait to see results" to "deploy multiple variants, measure continuously, let the system learn." This closes the loop back to Principle 1 - everything is an experiment, but now the experiments run automatically at scale with near real-time signal collection and decision making. It's Experiments All The Way Down "We established that software has become societal infrastructure. That software is different - it's not a construction project with a fixed endpoint; it's a living capability that evolves with the business." This five-episode series has built a complete picture: Episode 1 established that software is societal infrastructure and fundamentally different from traditional construction. Episode 2 diagnosed the problem - project management thinking treats software like building a bridge, creating cascade failures throughout organizations. Episode 3 showed that solutions already exist, with organizations like Spotify, Amazon, and Etsy practicing software-native development successfully. Episode 4 exposed the organizational immune system - the four barriers preventing transformation: the project mindset, funding models, business/IT separation, and risk management theater. Today's episode provides the blueprint - the five principles forming the operating system for software-native organizations. This isn't theory. This is how software-native organizations already operate. The question isn't whether this works - we know it does. The question is: how do you get started? The Next Step In Building A Software-Native Organization "This is how transformation starts - not with grand pronouncements or massive reorganizations, but with conversations and small experiments that compound over time. Software is too important to society to keep managing it wrong." Start this week by doing two things.  First, start a conversation: pick one of these five principles - whichever resonates most with your current challenges - and share it with your team or leadership. Don't present it as "here's what we should do" but as "here's an interesting idea - what would this mean for us?" That conversation will reveal where you are, what's blocking you, and what might be possible.  Second, run one small experiment: take something you're currently doing and frame it as an experiment with a clear goal, action, and learning measure. Make it small, make it fast - one week maximum, 24 hours if you can - then stop and learn. You now have the blueprint. You understand the barriers. You've seen the alternatives. The transformation is possible, and it starts with you. Recommended Further Reading Tom Gilb and Simon Holzapfel episodes on continuous strategy  The book by Christensen, Clayton: "The Innovator's Dilemma"  The book by Gojko Adzic: Impact Mapping  Ukraine drone warfare Company lifespan statistics: Innosight research on S&P 500 turnover  Stripe's impact on internet businesses Amazon AWS origin story DevOps observability practices About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

BONUS: Breaking Through The Organizational Immune System - Why Software-Native Organizations Are Still Rare With Vasco Duarte In this BONUS episode, we explore the organizational barriers that prevent companies from becoming truly software-native. Despite having proof that agile, iterative approaches work at scale—from Spotify to Amazon to Etsy—most organizations still struggle to adopt these practices. We reveal the root cause behind this resistance and expose four critical barriers that form what we call "The Organizational Immune System." This isn't about resistance to change; it's about embedded structures, incentives, and mental models that actively reject beneficial transformation. The Root Cause: Project Management as an Incompatible Mindset "Project management as a mental model is fundamentally incompatible with software development. And will continue to be, because 'project management' as an art needs to support industries that are not software-native." The fundamental problem isn't about tools or practices—it's about how we think about work itself. Project management operates on assumptions that simply don't hold true for software development. It assumes you can know the scope upfront, plan everything in advance, and execute according to that plan. But software is fundamentally different. A significant portion of the work only becomes visible once you start building. You discover that the "simple" feature requires refactoring three other systems. You learn that users actually need something different than what they asked for. This isn't poor planning—it's the nature of software. Project management treats discovery as failure ("we missed requirements"), while software-native thinking treats discovery as progress ("we learned something critical"). As Vasco points out in his NoEstimates work, what project management calls "scope creep" should really be labeled "value discovery" in software—because we're discovering more value to add. Discovery vs. Execution: Why Software Needs Different Success Metrics "Software hypotheses need to be tested in hours or days, not weeks, and certainly not months. You can't wait until the end of a 12-month project to find out your core assumption was wrong." The timing mismatch between project management and software development creates fundamental problems. Project management optimizes for plan execution with feedback loops that are months or years long, with clear distinctions between teams doing requirements, design, building, and testing. But software needs to probe and validate assumptions in hours or days. Questions like "Will users actually use this feature?" or "Does this architecture handle the load?" can't wait for the end of a 12-month project. When we finally discover our core assumption was wrong, we need to fully replan—not just "change the plan." Software-native organizations optimize for learning speed, while project management optimizes for plan adherence. These are opposing and mutually exclusive definitions of success. The Language Gap: Why Software Needs Its Own Vocabulary "When you force software into project management language, you lose the ability to manage what actually matters. You end up tracking task completion while missing that you're building the wrong thing." The vocabulary we use shapes how we think about problems and solutions. Project management talks about tasks, milestones, percent complete, resource allocation, and critical path. Software needs to talk about user value, technical debt, architectural runway, learning velocity, deployment frequency, and lead time. These aren't just different words—they represent fundamentally different ways of thinking about work. When organizations force software teams to speak in project management terms, they lose the ability to discuss and manage what actually creates value in software development. The Scholarship Crisis: An Industry-Wide Knowledge Gap "Agile software development represents the first worldwide trend in scholarship around software delivery. But most organizational investment still goes into project management scholarship and training." There's extensive scholarship in IT, but almost none about delivery processes until recently. The agile movement represents the first major wave of people studying what actually works for building software, rather than adapting thinking from manufacturing or construction. Yet most organizational investment continues to flow into project management certifications like PMI and Prince2, and traditional MBA programs—all teaching an approach with fundamental problems when applied to software. This creates an industry-wide challenge: when CFOs, executives, and business partners all think in project management terms, they literally cannot understand why software needs to work differently. The mental model mismatch isn't just a team problem—it's affecting everyone in the organization and the broader industry. Budget Cycles: The Project Funding Trap "You commit to a scope at the start, when you know the least about what you need to build. The budget runs out exactly when you're starting to understand what users actually need." Project thinking drives project funding: organizations approve a fixed budget (say $2M over 9 months) to deliver specific features. This seems rational and gives finance predictability, but it's completely misaligned with how software creates value. Teams commit to scope when they know the least about what needs building. The budget expires just when they're starting to understand what users actually need. When the "project" ends, the team disbands, taking all their accumulated knowledge with them. Next year, the cycle starts over with a new project, new team, and zero retained context. Meanwhile, the software itself needs continuous evolution, but the funding structure treats it as a series of temporary initiatives with hard stops. The Alternative: Incremental Funding and Real-Time Signals "Instead of approving $2M for 9 months, approve smaller increments—maybe $200K for 6 weeks. Then decide whether to continue based on what you've learned." Software-native organizations fund teams working on products, not projects. This means incremental funding decisions based on learning rather than upfront commitments. Instead of detailed estimates that pretend to predict the future, they use lightweight signals from the NoEstimates approach to detect problems early: Are we delivering value regularly? Are we learning? Are users responding positively? These signals provide more useful information than any Gantt chart. Portfolio managers shift from being "task police" asking "are you on schedule?" to investment curators asking "are we seeing the value we expected? Should we invest more, pivot, or stop?" This mirrors how venture capital works—and software is inherently more like VC than construction. Amazon exemplifies this approach, giving teams continuous funding as long as they're delivering value and learning, with no arbitrary end date to the investment. The Business/IT Separation: A Structural Disaster "'The business' doesn't understand software—and often doesn't want to. They think in terms of features and deadlines, not capabilities and evolution." Project thinking reinforces organizational separation: "the business" defines requirements, "IT" implements them, and project managers coordinate the handoff. This seems logical with clear specialization and defined responsibilities. But it creates a disaster. The business writes requirements documents without understanding what's technically possible or what users actually need. IT receives them, estimates, and builds—but the requirements are usually wrong. By the time IT delivers, the business need has changed, or the software works but doesn't solve the real problem. Sometimes worst of all, it works exactly as specified but nobody wants it. This isn't a communication problem—it's a structural problem created by project thinking. Product Thinking: Starting with Behavior Change "Instead of 'build a new reporting dashboard,' the goal is 'reduce time finance team spends preparing monthly reports from 40 hours to 4 hours.'" Software-native organizations eliminate the business/IT separation by creating product teams focused on outcomes. Using approaches like Impact Mapping, they start with behavior change instead of features. The goal becomes a measurable change in business behavior or performance, not a list of requirements. Teams measure business outcomes, not task completion—tracking whether finance actually spends less time on reports. If the first version doesn't achieve that outcome, they iterate. The "requirement" isn't sacred; the outcome is. "Business" and "IT" collaborate on goals rather than handing off requirements. They're on the same team, working toward the same measurable outcome with no walls to throw things over. Spotify's squad model popularized this approach, with each squad including product managers, designers, and engineers all focused on the same part of the product, all owning the outcome together. Risk Management Theater: The Appearance of Control "Here's the real risk in software: delivering software that nobody wants, and having to maintain it forever." Project thinking creates elaborate risk management processes—steering committees, gate reviews, sign-offs, extensive documentation, and governance frameworks. These create the appearance of managing risk and make everyone feel professional and in control. But paradoxically, the very practices meant to manage risk end up increasing the risk of catastrophic failure. This mirrors Chesterton's Fence paradox. The real risk in software isn't about following the plan—it's delivering software nobody wants and having to maintain it forever. Every line of code becomes a maintenance burden. If it's not delivering value, you're paying the cost forever or paying additional cost to remove it later. Traditional risk management theater doesn't protect against this at all. Gates and approvals just slow you down without validating whether users will actually use what you're building or whether the software creates business value. Agile as Risk Management: Fast Learning Loops "Software-native organizations don't see 'governance' and 'agility' as a tradeoff. Agility IS governance. Fast learning loops ARE how you manage risk." Software-native organizations recognize that agile and product thinking ARE risk management. The fastest way to reduce risk is delivering quickly—getting software in front of real users in production with real data solving real problems, not in demos or staging environments. Teams validate expected value by measuring whether software achieves intended outcomes. Did finance really reduce their reporting time? Did users actually engage with the feature? When something isn't working, teams change it quickly. When it is working, they double down. Either way, they're managing risk through rapid learning. Eric Ries's Lean Startup methodology isn't just for startups—it's fundamentally a software-native management practice. Build-Measure-Learn isn't a nice-to-have; it's how you avoid the catastrophic risk of building the wrong thing. The Risk Management Contrast: Theater vs. Reality "Which approach actually manages risk? The second one validates assumptions quickly and cheaply. The first one maximizes your exposure to building the wrong thing." The contrast between approaches is stark. Risk management theater involves six months of requirements gathering and design, multiple approval gates that claim to prevent risk but actually accumulate it, comprehensive test plans, and a big-bang launch after 12 months. Teams then discover users don't want it—and now they're maintaining unwanted software forever. The agile risk management approach takes two weeks to build a minimal viable feature, ships to a subset of users, measures actual behavior, learns it's not quite right, iterates in another two weeks, validates value before scaling, and only maintains software that's proven valuable. The second approach validates assumptions quickly and cheaply. The first maximizes exposure to building the wrong thing. The Immune System in Action: How Barriers Reinforce Each Other "When you try to 'implement agile' without addressing these structural barriers, the organization's immune system rejects it. Teams might adopt standups and sprints, but nothing fundamental changes." These barriers work together as an immune system defending the status quo. It starts with the project management mindset—the fundamental belief that software is like construction, that we can plan it all upfront, that "done" is a meaningful state. That mindset creates funding models that allocate budgets to temporary projects instead of continuous products, organizational structures that separate "business" from "IT" and treat software as a cost center, and risk management theater that optimizes for appearing in control rather than actually learning. Each barrier reinforces the others. The funding model makes it hard to keep stable product teams. The business/IT separation makes it hard to validate value quickly. The risk theater slows down learning loops. The whole system resists change—even beneficial change—because each part depends on the others. This is why so many "agile transformations" fail: they treat the symptoms (team practices) without addressing the disease (organizational structures built on project thinking). Breaking Free: Seeing the System Clearly "Once you see the system clearly, you can transform it. You now know the root cause, how it manifests, and what the alternatives look like." Understanding these barriers is empowering. It's not that people are stupid or resistant to change—organizations have structural barriers built on a fundamental mental model mismatch. But once you see the system clearly, transformation becomes possible. You now understand the root cause (project management mindset), how it manifests in your organization (funding models, business/IT separation, risk theater), and what the alternatives look like through real examples from companies successfully operating as software-native organizations. The path forward requires addressing the disease, not just the symptoms—transforming the fundamental structures and mental models that shape how your organization approaches software. Recommended Further Reading Vasco's article on 5 examples of software disasters that show we are in the middle of another software crisis NoEstimates movement: Vasco Duarte's work and book Impact Mapping: Gojko Adzic's framework Lean Startup: Eric Ries, "The Lean Startup" Outcome-based funding model Spotify squad model: Henrik Kniberg's materials Chesterton's fence paradox About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

Xmas Special: Recovering the Essence of Agile - What's Already Working in Software-Native Organizations In this BONUS Xmas Special episode, we explore what happens when we strip away the certifications and branded frameworks to recover the essential practices that make software development work. Building on Episode 2's exploration of the Project Management Trap, Vasco reveals how the core insights that sparked the Agile revolution remain valid - and how real organizations like Spotify, Amazon, and Etsy embody these principles to thrive in today's software-driven world. The answer isn't to invent something new; it's to amplify what's already working. Agile as an Idea, Not a Brand "The script (sold as the solution) will eventually kill the possibility of the conversation ever happening with any quality." We establish a parallel between good conversations and good software development. Just as creating "The Certified Conversational Method™" with prescribed frameworks and certification levels would miss the point of genuine dialogue, the commodification of agile into Agile™ has obscured its essential truth. The core idea was simple and powerful: build software in small increments, get it in front of real users quickly, learn from their actual behavior, adapt based on what you learn, and repeat continuously. This wasn't revolutionary - it was finally recognizing how software actually works. You can't know if your hypothesis about user needs is correct until users interact with it, so optimize for learning speed, not planning precision. But when the need to certify and validate "doing Agile right" took over, the idea got packaged, and often the package became more important than the principle. Four Fundamental Practices That Enable Living Software "Every deployment was a chance to see how users actually responded." Software-native organizations distinguish themselves through core practices that align with software as a living capability. In this episode, we review four critical ones: First, iterative delivery means shipping the smallest valuable increment possible and building on it - Etsy's transformation from quarterly releases in 2009 to shipping 50+ times per day by 2012 exemplifies this approach, where each small change serves as a learning opportunity. Second, tight feedback loops get software in front of real users as fast as possible, whether through paper prototypes or production deployments. Third, continuous improvement of the process itself creates meta-feedback loops, as demonstrated by Amazon's "You Build It, You Run It" principle introduced by Werner Vogels in 2006, where development teams running their own services in production learn rapidly to write more resilient code. Fourth, product thinking over project thinking organizes teams around long-lived products rather than temporary projects, allowing teams to develop deep expertise and become living capabilities themselves, accumulating knowledge and improving over time. Spotify's Evolutionary Approach "The Spotify model has nothing to do with Spotify really. It was just a snapshot of how that one company worked at the time." Spotify's journey reveals a critical insight often missed in discussions of their famous organizational model. Starting with standard Scrum methodology pre-2012, they adopted the squad model around 2012 with autonomous teams organized into tribes, documented in Henrik Kniberg and Anders Ivarsson's influential white paper (direct PDF link). But post-2016, internal staff and agile coaches noted that the "Spotify model" had become mythology, and the company had moved on from original concepts to address new challenges. As Kniberg himself later reflected, the model has taken on a life of its own, much like Lean's relationship to Toyota. The key insight isn't the specific structure - it's that Spotify treated their own organizational design as a living capability, continuously adapting based on what worked and what didn't rather than implementing "the model" and declaring victory. That's software-native thinking applied to organization design itself. Amazon's Two-Pizza Teams and Massive Scale "Amazon deploys code every 11.7 seconds on average. That's over 7,000 deployments per day across the organization." (see this YouTube video of this talk) Amazon's two-pizza team principle goes far deeper than team size. Teams small enough to be fed with two pizzas (roughly 6-10 people) gain crucial autonomy and ownership: each team owns specific services and APIs, makes their own technical decisions, runs their services in production, and manages inter-team dependencies through APIs rather than meetings. This structure enabled Amazon to scale massively while maintaining speed, as teams could iterate independently without coordinating with dozens of other teams. The staggering deployment frequency - over 7,000 times per day as of 2021 - is only possible with a software-native structure for the company itself, demonstrating that this isn't just about managing software delivery but touches everything, including how teams are organized. Why These Practices Work "These practices work because they align with what software actually is: a living, evolvable capability." The effectiveness of software-native approaches stems from their alignment with software's true nature. Traditional project approaches assume we can know requirements upfront, estimate accurately, build it right the first time, and reach a meaningful "done" state. Software-native approaches recognize that requirements emerge through interaction with users, estimation is less important than rapid learning, "right" is discovered iteratively rather than designed upfront, and "done" only happens when we stop evolving the software. When Etsy ships 50 times per day, they're optimizing for learning where each deployment is a hypothesis test. When Amazon's teams own services end-to-end, they're creating tight feedback loops where teams feel the pain of their own decisions directly. When Spotify continuously evolves their organizational model, they're treating their own structure as software that should adapt to changing needs. The Incomplete Picture and the Question of Universal Adoption "If these approaches work, why aren't they universal?" We're not trying to paint a unrealistically rosy picture - these organizations aren't perfect. Spotify has had well-documented challenges with their model, Amazon's culture has been criticized as demanding and sometimes brutal, and Etsy has gone through multiple strategic shifts. But what matters is that they're practicing software-native development at scale, and it's working well enough that they can compete and thrive. They're not following a playbook perfectly but embodying principles and adapting continuously. This raises the critical question that will be explored in the next episode: if these approaches work, why do so many organizations still operate in project mode, and why do "agile transformations" so often fail to deliver real change? Understanding the resistance - what we call The Organizational Immune System - is essential to overcoming it. References for Further Reading A book on the shift from "projects" to "products": "Project to Product" by Mik Kersten About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success.  You can link with Vasco Duarte on LinkedIn.

Xmas Special: Why project management tools fail software development - and what works instead! In this BONUS episode, we dive deep into The Project Management Trap, continuing our exploration from Episode 1 where we established that software is societal infrastructure being managed with tools from the 1800s. We examine why project management frameworks - designed for building railroads and ships - are fundamentally misaligned with software development, and what happens when we treat living capabilities like construction projects with defined endpoints. The Origin Story - Where Project Management Came From "The problem isn't that project management is bad. The problem is that software isn't building a railroad or a building, or setting up a process that will run forever (like a factory)." Project management emerged from industries with hard physical constraints - building the Transcontinental Railroad in the 1860s, coordinating factory machinery, managing finite and expensive materials. The Gantt chart, invented in the 1910s for factory scheduling, worked brilliantly for coordinating massive undertakings with calculable physics, irreversible decisions, and clear completion points. When the rails met, you were done. When the bridge was built, the project ended. These tools gave us remarkable precision for building ships, bridges, factories, and highways. But software operates in a completely different reality - one where the raw materials are time and brainpower, not minerals and hardware, and where the transformation happens in unique creative moments rather than repeated mechanical movements. The Seductive Clarity Of Project Management Artifacts "In software, we almost never know either of those things with certainty." Project management is tempting for software leaders because it offers comforting certainty. Gantt charts show every task laid out, milestones mark clear progress, "percent complete" gives us a number, and a defined "done" promises relief. The typical software project kickoff breaks down into neat phases: requirements gathering (6 weeks), design (4 weeks), development (16 weeks), testing (4 weeks), deployment (2 weeks) - total 32 weeks, done by Q3. Leadership loves this. Finance can budget it. Everyone can plan around it. But this is false precision. Software isn't pouring concrete where you measure twice and pour once. Every line of code is a hypothesis about what users need and how the system should behave. That 32-week plan assumes we know exactly what to build and exactly how long each piece takes - assumptions that are almost never true in software development. The Completion Illusion "Software products succeed by evolving. Projects end; products adapt." "Done" is the wrong goal for living software. We expand on the Slack story from Episode 1 to illustrate this point. If Slack's team had thought in project terms in 2013, they might have built a functional tool with channels, direct messages, file sharing, and search - shipped on time and on budget by Q2 2014, project complete. But that wasn't the end; it was the beginning. Through continuous user feedback and evolution, Slack added threaded conversations (2017), audio/video calls (2016), workflow automation (2019), and Canvas for knowledge management (2023). Each wasn't maintenance or bug fixing - these were fundamental enhancements. Glass's research shows that 60% of maintenance costs are enhancements, not fixes. By 2021, when Salesforce acquired Slack for $27.7 billion, it bore little resemblance to the 2014 version. The value wasn't in that initial "project" - it was in the continuous evolution. If they'd thought "build it, ship it, done," Slack would have died competing against HipChat and Campfire. When Projects Succeed (Well, Some Do, Anyway) But Software Fails "They tried to succeed at project management. They ended up failing at both software delivery AND project management!" Vasco references his article "The Software Crisis is Real," examining five distinct cases from five different countries that represent what's wrong with project thinking for software. These projects tried hard to do everything right by project management standards: detailed requirements (thousands of pages), milestone tracking, contractor coordination, hitting fixed deadlines, and proper auditing. What they didn't have was iterative delivery to test with real users early, feedback loops to discover problems incrementally, adaptability to change based on learning, or a "living capability" mindset. Project thinking demanded: get all requirements right upfront (otherwise no funding), build it all, test at the end, launch on deadline. Software thinking demands: launch something minimal early, get real user feedback, iterate rapidly, evolve the capability. These projects succeeded at following project management rules but failed at delivering valuable software. What Software-Native Delivery Management Looks Like "Software is unpredictable not because we're bad at planning - it's unpredictable because we're creating novel solutions to complex problems, and in a completely different economic system." If not projects, then what? Vasco has been exploring this question for years, since publishing the NoEstimates book. The answer starts with thinking in products and capabilities, not projects - recognizing that products have ongoing evolution, capabilities are cultivated and improved rather than "delivered" and done, and value is measured in outcomes rather than task completion. Instead of comprehensive planning, we need iteration and constant decision-making based on validated hypotheses: start with "We believe users need X," run experiments by building small and testing with real users, then learn and adapt. Instead of fixed scope, define the problem (not the solution), allow the solution to evolve as you learn, and optimize for learning speed rather than task completion.  The contrast is clear: project thinking says "We will build features A, B, C, D, and E by Q3, then we're done." Software-native thinking says "We're solving problem X for users. We'll start with the riskiest hypothesis, build a minimal version, ship it to 100 users next week, and learn whether we're on the right track." The appropriate response to software's inherent unpredictability isn't better planning - it's faster learning. References for Further Reading Vasco Duarte's article on the Software Leadership Workshop newsletter: "The Software Crisis is Real"  Glass, Robert L. "Facts and Fallacies of Software Engineering" - Fact 42: "Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it." NoEstimates Book: How To Measure Project Progress Without Estimating Slack evolution timeline: Company history and feature releases  The unexpected design challenge behind Slack's new threaded conversations Slack voice and video chat Slack launches admin workflow automation and announcement channels  Meet Slack Canvas - Slack's answer to the knowledge management problem. About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

Xmas Special: Software Industry Transformation - Why Software Development Must Mature Welcome to the 2025 Xmas special - a five-episode deep dive into how software as an industry needs to transform. In this opening episode, we explore the fundamental disconnect between how we manage software and what software actually is. From small businesses to global infrastructure, software has become the backbone of modern society, yet we continue to manage it with tools designed for building ships in the 1800s. This episode sets the stage for understanding why software development must evolve into a mature discipline. Software Runs Everything Now "Without any single piece, I couldn't operate - and I'm tiny. Scale this reality up: software isn't just in tech companies anymore." Even the smallest businesses today run entirely on software infrastructure. A small consulting and media business depends on WordPress for websites, Kajabi for courses, Stripe for payments, Quaderno for accounting, plus email, calendar, CRM systems, and AI assistants for content creation. The challenge? We're managing this critical infrastructure with tools designed for building physical structures with fixed requirements - an approach that fundamentally misunderstands what software is and how it evolves. This disconnect has to change. The Oscillation Between Technology and Process "AI amplifies our ability to create software, but doesn't solve the fundamental process problems of maintaining, evolving, and enhancing that software over its lifetime." Software improvement follows a predictable pattern: technology leaps forward, then processes must adapt to manage the new complexity. In the 1960s-70s, we moved from machine code to COBOL and Fortran, which was revolutionary but led to the "software crisis" when we couldn't manage the resulting complexity. This eventually drove us toward structured programming and object-oriented programming as process responses, which, in turn, resulted in technology changes! Today, AI tools like GitHub Copilot, ChatGPT, and Claude make writing code absurdly easy - but writing code was never the hard part. Robert Glass documents in "Facts and Fallacies of Software Engineering" that maintenance typically consumes between 40 and 80 percent of software costs, making "maintenance" probably the most important life cycle phase. We're overdue for a process evolution that addresses the real challenge: maintaining, evolving, and enhancing software over its lifetime. Software Creates An Expanding Possibility Space "If they'd treated it like a construction project ('ship v1.0 and we're done'), it would never have reached that value." Traditional project management assumes fixed scope, known solutions, and a definable "done" state. The Sydney Opera House exemplifies this: designed in 1957, completed in 1973, ten times over budget, with the architect resigning - but once built, it stands with "minimal" (compared to initial cost) maintenance. Software operates fundamentally differently. Slack started as an internal tool for a failed gaming company called Glitch in 2013. When the game failed, they noticed their communication tool was special and pivoted entirely. After launching in 2014, Slack continuously evolved based on user feedback: adding threads in 2017, calls in 2016, workflow builder in 2019, and Canvas in 2023. Each addition changed what was possible in organizational communication. In 2021, Salesforce acquired Slack for $27.7 billion precisely because it kept evolving with user needs. The key difference is that software creates possibility space that didn't exist before, and that space keeps expanding through continuous evolution. Software Is Societal Infrastructure "This wasn't a cyber attack - it was a software update gone wrong." Software has become essential societal infrastructure, not optional and not just for tech companies. In July 2024, a faulty software update from cybersecurity firm CrowdStrike crashed 8.5 million Windows computers globally. Airlines grounded flights, hospitals canceled surgeries, banks couldn't process transactions, and 911 services went down. The global cost exceeded $10 billion. This wasn't an attack - it was a routine update that failed catastrophically. AWS outages in 2021 and 2023 took down major portions of the internet, stopping Netflix, Disney+, Robinhood, and Ring doorbells from working. CloudFlare outages similarly cascaded across daily-use services. When software fails, society fails. We cannot keep managing something this critical with tools designed for building physical things with fixed requirements. Project management was brilliant for its era, but that era isn't this one. The Path Ahead: Four Critical Challenges "The software industry doesn't just need better tools - it needs to become a mature discipline." This five-episode series will address how we mature as an industry by facing four critical challenges: Episode 2: The Project Management Trap - Why we think in terms of projects, dates, scope, and "done" when software is never done, and how this mindset prevents us from treating software as a living capability Episode 3: What's Already Working - The better approaches we've already discovered, including iterative delivery, feedback loops, and continuous improvement, with real examples of companies doing this well Episode 4: The Organizational Immune System - Why better approaches aren't universal, how organizations unconsciously resist what would help them, and the hidden forces preventing adoption Episode 5: Software-Native Organizations - What it means to truly be a software-native organization, transforming how the business thinks, not just using agile on teams Software is too important to our society to keep getting it wrong. We have much of the knowledge we need - the challenge is adoption and evolution. Over the next four episodes, we'll build this case together, starting with understanding why we keep falling into the same trap. References For Further Reading Glass, Robert L. "Facts and Fallacies of Software Engineering" - Fact 41, page 115  CrowdStrike incident: https://en.wikipedia.org/wiki/2024_CrowdStrike_incident  AWS outages: 2021 (Dec 7), 2023 (June 13),  and November 2025 incidents  CloudFlare outages: 2022 (June 21), and November 2025 major incident  Slack history and Salesforce acquisition: https://en.wikipedia.org/wiki/Slack_(software)  Sydney Opera House: https://en.wikipedia.org/wiki/Sydney_Opera_House About Vasco Duarte Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success. You can link with Vasco Duarte on LinkedIn.

Natalia Curusi: From Spreadsheets to Discovery—Helping POs Make the Transition The Great Product Owner: Taking Ownership and Coaching the Team Forward 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.   "That person was not just a great product owner, but a great coach—he had excellent communication and stakeholder management skills, and he coached myself as a Scrum Master, showing me how product ownership should look like." - Natalia Curusi   Natalia worked with a Product Owner who embodied everything the role should be. He didn't come from a technical background, but he possessed exceptional domain knowledge, outstanding communication skills, and stakeholder management expertise you rarely find in one person. What made him truly remarkable was that he coached everyone around him, including Natalia as the Scrum Master.  He demonstrated full empowerment and ownership—making decisions himself rather than constantly escalating to higher management. When risks needed to be taken, he took them with courage and conviction. The team trusted him completely because he balanced business needs with team capacity, always understanding what they could realistically achieve. Over the past five years, this person has been promoted multiple times and now serves as a global director of product, still with the same company.  When Natalia thinks about what great product ownership looks like, she thinks of him—someone who combined technical understanding with coaching ability, took genuine ownership of outcomes, and empowered the team through clear vision and decisive leadership. These are exactly the skills that are hardest to find in the market, yet when you find them, the impact is transformative for the entire organization.   Self-reflection Question: Does your Product Owner take ownership and make decisions, or do they constantly escalate to higher management, preventing the team from moving forward with confidence? The Bad Product Owner: Assigned Without Training, Support, or Willingness "She was a great subject matter expert with deep domain knowledge, but the organization assigned her the product owner role without her willingness, without training, and while she was already 80% loaded with other responsibilities." - Natalia Curusi   Natalia encountered a Product Owner anti-pattern that reveals a systemic organizational failure. The person was an exceptional subject matter expert with incredible domain knowledge, but when the organization decided to adopt Agile, they assigned her the PO role like sticking a label on a box—no training, no consent, no preparation. She was already working at 80% capacity on other responsibilities and had no understanding of what product ownership meant. Frustrated and overwhelmed, she approached the role from a command-and-control mindset. At the project start, she brought a massive spreadsheet of requirements, expecting the team to implement them sequentially.  The team tried a different approach, wanting to understand problems before discussing solutions, but the PO surprised everyone by re-introducing the spreadsheet in a later meeting—a clear sign of misalignment and broken trust. Natalia, recognizing this was a battle she couldn't win without organizational support, chose to manage the relationship rather than create open conflict. She worked to mediate between the PO's spreadsheet approach and the team's need for discovery and iterative development. The real anti-pattern wasn't the individual—it was the organization assigning critical roles without providing training, time, or psychological safety. This situation illustrates why product ownership fails: not from bad people, but from bad systems that set people up to fail.   Self-reflection Question: When you see a struggling Product Owner, are you addressing the individual's behavior or the systemic conditions that set them up to fail in the first place?   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: Measuring What Matters Beyond Velocity and Story Points Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "We as Scrum Masters need to put a scope for ourselves—we need to aim to leave the place where we work a little bit better than it was, and to make sure that this place could improve itself without us." - Natalia Curusi   Natalia defines success for Scrum Masters with crystal clarity: leave the organization better than you found it, and ensure it can continue improving when you're gone. This means fostering independence and ownership in teams so they can perform whether you're on vacation, in another meeting, or have moved to coaching other teams.  The opposite pattern—where everything falls apart when the Scrum Master isn't present—reveals someone who hasn't truly succeeded in the role. Natalia also emphasizes the importance of establishing metrics early, but not the traditional ones.  Using velocity as a metric is an anti-pattern that focuses teams on the wrong outcomes. Instead, she recommends metrics like predictability, team morale, psychological safety measured through 360 feedback, and the quality of conversations both within teams and with stakeholders. But metrics alone don't tell the story.  Natalia champions the concept of Gemba walks—going to see what's actually happening, talking to people, observing the reality rather than just reviewing dashboard numbers. Some metrics are easily gamed, others provide only narrow perspectives on reality. The most important practice is using metrics to trigger reflection and adaptation, not as fixed targets. Natalia believes strongly that the quality of conversations—how teams discuss options, make decisions together, and adapt when facing pressure—reveals more about a Scrum Master's success than any velocity chart ever could. The ultimate question: can your team succeed without you?   Self-reflection Question: If you disappeared from your team tomorrow, would they continue improving, or would progress stop until someone replaced you? Featured Retrospective Format for the Week: Spotify Squad Health Check "This is a multidimensional retro that I run with teams every 2 to 3 months—you need around 30 minutes for it, and I often get insights and new ideas from this retrospective that help me as a Scrum Master." - Natalia Curusi   The Spotify Squad Health Check is Natalia's favorite retrospective format because it provides a comprehensive view of team health across multiple dimensions. Unlike traditional retrospectives that might focus on a single sprint or specific issue, this format examines the team's overall state across areas like teamwork, support, mission clarity, and technical quality. Teams rate themselves on various health indicators, creating a visual representation that reveals patterns over time.  What makes this particularly valuable is that it works whether you know the team well or are just starting with them—either way, you gain insights and "aha moments" about where the team truly stands. The multidimensional nature prevents teams from optimizing just one aspect while neglecting others, and the regular cadence (every 2-3 months) allows you to track trends and celebrate improvements.  For Natalia, this format consistently surfaces the hidden challenges that teams might not raise in regular retrospectives, making it an essential tool in her Scrum Master toolkit.   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: Demonstrating Your Value When the Market Questions Agile Roles 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.   "My challenging topic is about the demand of agility in the market—how do we fit ourselves as scrum masters in that AI era? How can we demonstrate our competence and contribution when there's a perception that agile roles bring little value?" - Natalia Curusi   Natalia faces the challenge every Scrum Master in 2025 grapples with: how to demonstrate value in an era when business perceives agile roles as optional overhead. The market has contracted, companies are optimizing budgets, and Scrum Masters often appear first on the chopping block.  There's talk of "blended roles" where developers are expected to absorb Scrum Master responsibilities, and questions about how AI might replace the human facilitation work that coaches provide. But Natalia believes the answer lies in understanding something fundamental: the Scrum Master is a deeply situational and contextual role that adapts to what the team needs each day.  Some teams need help with communication spaces, others need work structure like Kanban boards, still others need translation between technical realities and stakeholder expectations. The challenge is that this situational nature makes it incredibly hard to explain to business leaders who think in fixed job descriptions and measurable outputs. Natalia's approach involves bringing metrics—not velocity, which focuses on the wrong things, but metrics around team independence, continuous improvement, and organizational capability. She suggests concepts like Gemba walks—going to see what's actually happening rather than relying only on numbers. The real question Natalia poses is this: the biggest value we can bring to an organization is to leave it better than we found it, but how do we make that visible and tangible to business stakeholders who need justification for our roles?   Self-reflection Question: If you had to demonstrate your value as a Scrum Master using only observable evidence from the past month, what would you show your leadership?   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: The Dark Side of High-Performing Dream 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.   "I was proud of this team—I helped form them from the start, we traveled to the client together, they were mature and independent, they even jelled outside the workplace. This was my dream team." - Natalia Curusi   Natalia had built something special. The team was technically strong, emotionally connected, and highly productive. They socialized outside work, traveled together to client sites, and operated with remarkable independence. But when a new junior developer joined, everything started to unravel.  The existing team members were like heroes—fast, skilled, confident. The newcomer couldn't keep pace, and slowly Natalia noticed something disturbing: the team started making fun of the new member during retrospectives and stand-ups. The person became an outlier, a black swan ignored by the group. Natalia conducted one-on-one meetings with both the new member and the team, but the situation only worsened. The new person insisted they were fine and didn't need help. The team members claimed they were just joking around. Meanwhile, the team structure and morale deteriorated.  Natalia realized she was watching her dream team self-destruct through a form of bullying—something she hadn't even recognized at the time. Finally, she understood she couldn't handle this alone and escalated to the head of discipline and the organizational psychologist. Together, they decided to rotate the person to another team where they felt more comfortable. Natalia learned a painful lesson: as Scrum Masters, we don't need to solve everything ourselves, and sometimes the best solution is recognizing when to use the support structure around us rather than treating it as a personal failure.   In this episode, we refer to Coaching Agile Teams by Lyssa Adkins and Training from the Back of the Room by Sharon Bowman.   Self-reflection Question: When have you witnessed subtle forms of exclusion in your team, and did you recognize them early enough to intervene effectively? Featured Book of the Week: Coaching Agile Teams by Lyssa Adkins "This was the first book about agile coaching that I read, and it's how I understood that I was already playing the scrum master role without even knowing it—I understood that I was already acting like a glue for the team." - Natalia Curusi   Natalia discovered Coaching Agile Teams at a pivotal moment in her career. The book revealed something profound: if you're irreplaceable, there's a problem. A great Scrum Master or coach makes themselves obsolete by growing team members who can replace them. The team should be able to perform independently when you're on vacation or move to another assignment. Lyssa Adkins showed Natalia that she needed to let go of over-control and over-responsibility, focusing instead on growing the team's capabilities. The book remains one of Natalia's top recommendations for every junior Scrum Master wanting to embrace the role, alongside Training from the Back of the Room, which teaches facilitators how to run interactive workshops where people learn from each other rather than just listening to slides.   [The Scrum Master Toolbox Podcast Recommends]

Natalia Curusi: When Your Technical Expertise Becomes Your Biggest Scrum Master Weakness 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 thought my technical background was my biggest strength, but I understood that this was my biggest weakness—I was coming into stand-ups saying 'I know how we need to fix that issue,' and I was a Scrum Master." - Natalia Curusi   Natalia stepped into her first blended role as team leader and Scrum Master full of confidence. With years of programming experience behind her, she believed she could guide her team through any technical challenge. But during morning stand-ups, she found herself suggesting solutions, directing technical approaches, and sharing her expertise freely. The team listened—after all, she was their former leader. They implemented her suggestions, but when those solutions failed, the team didn't have the thinking process to adapt them to their context.  Natalia realized she was preventing the team's learning and ownership by taking control away from them. The turning point came when she made a deliberate choice: she selected the most technical person on the team to become the technical authority and committed to never stepping on his feet again. From that moment forward, she focused purely on the Scrum Master role—asking questions, fostering collaboration, and shutting up to listen actively.  Years later, that technical lead followed her to another job, and they remain friends to this day. Natalia learned that her contribution wasn't about giving solutions—it was about keeping the team from losing ownership of their work.   Self-reflection Question: When you attend your team's daily stand-up, are you contributing to collaboration, or is your contribution keeping the team from owning their work?   [The Scrum Master Toolbox Podcast Recommends]

BONUS: Swimming in Tech Debt — Practical Techniques to Keep Your Team from Drowning in Its Codebase In this fascinating conversation, veteran software engineer and author Lou Franco shares hard-won lessons from decades at startups, Trello, and Atlassian. We explore his book "Swimming in Tech Debt," diving deep into the 8 Questions framework for evaluating tech debt decisions, personal practices that compound over time, team-level strategies for systematic improvement, and leadership approaches that balance velocity with sustainability. Lou reveals why tech debt is often the result of success, how to navigate the spectrum between ignoring debt and rewriting too much, and practical techniques individuals, teams, and leaders can use starting today. The Exit Interview That Changed Everything "We didn't go slower by paying tech debt. We went actually faster, because we were constantly in that code, and now we didn't have to run into problems." — Lou Franco   Lou's understanding of tech debt crystallized during an exit interview at Atalasoft, a small startup where he'd spent years. An engineer leaving the company confronted him: "You guys don't care about tech debt." Lou had been focused on shipping features, believing that paying tech debt would slow them down. But this engineer told a different story — when they finally fixed their terrible build and installation system, they actually sped up. They were constantly touching that code, and removing the friction made everything easier. This moment revealed a fundamental truth: tech debt isn't just about code quality or engineering pride. It's about velocity, momentum, and the ability to move fast sustainably. Lou carried this lesson through his career at Trello (where he learned the dangers of rewriting too much) and Atlassian (where he saw enterprise-scale tech debt management). These experiences became the foundation for "Swimming in Tech Debt." Tech Debt Is the Result of Success "Tech debt is often the result of success. Unsuccessful projects don't have tech debt." — Lou Franco   This reframes the entire conversation about tech debt. Failed products don't accumulate debt — they disappear before it matters. Tech debt emerges when your code survives long enough to outlive its original assumptions, when your user base grows beyond initial expectations, when your team scales faster than your architecture anticipated. At Atalasoft, they built for 10 users and got 100. At Trello, mobile usage exploded beyond their web-first assumptions. Success creates tech debt by changing the context in which code operates. This means tech debt conversations should happen at different intensities depending on where you are in the product lifecycle. Early startups pursuing product-market fit should minimize tech debt investments — move fast, learn, potentially throw away the code. Growth-stage companies need balanced approaches. Mature products benefit significantly from tech debt investments because operational efficiency compounds over years. Understanding this lifecycle perspective helps teams make appropriate decisions rather than applying one-size-fits-all rules. The 8 Questions Framework for Tech Debt Decisions "Those 8 questions guide you to what you should do. If it's risky, has regressions, and you don't even know if it's gonna work, this is when you're gonna do a project spike." — Lou Franco   Lou introduces a systematic framework for evaluating whether to pay tech debt, inspired by Bob Moesta's push-pull forces from product management. The 8 questions create a complete picture:   Visibility — Will people outside the team understand what we're doing? Alignment — Does this match our engineering values and target architecture? Resistance — How hard is this code to work with right now? Volatility — How often do we touch this code? Regression Risk — What's the chance we'll introduce new problems? Project Size — How big is this to fix? Estimate Risk — How uncertain are we about the effort required? Outcome Uncertainty — How confident are we the fix will actually improve things?   High volatility and high resistance with low regression risk? Pay the debt now. High regression risk with no tests? Write tests first, then reassess. Uncertain outcomes on a big project? Do a spike or proof of concept. The framework prevents both extremes — ignoring costly debt and undertaking risky rewrites without proper preparation. Personal Practices That Compound Daily "When I sit down at my desk, the first thing I do is I pay a little tech debt. I'm looking at code, I'm about to change it, do I even understand it? Am I having some kind of resistance to it? Put in a little helpful comment, maybe a little refactoring." — Lou Franco   Lou shares personal habits that create compounding improvements over time. Start each coding session by paying a small amount of tech debt in the area you're about to work — add a clarifying comment, extract a confusing variable, improve a function name. This warms you up, reduces friction for your actual work, and leaves the code slightly better than you found it. The clean-as-you-go philosophy means tech debt never accumulates faster than you can manage it. But Lou's most powerful practice comes at the end of each session: mutation testing by hand. Before finishing for the day, deliberately break something — change a plus to minus, a less-than to less-than-or-equal. See if tests catch it. Often they don't, revealing gaps in test coverage. The key insight: don't fix it immediately. Leave that failing test as the bridge to tomorrow's coding session. It connects today's momentum to tomorrow's work, ensuring you always start with context and purpose rather than cold-starting each day. Mutation Testing: Breaking Things on Purpose "Before I'm done working on a coding session, I break something on purpose. I'll change a plus to a minus, a less than to a less than equals, and see if tests break. A lot of times tests don't break. Now you've found a problem in your test." — Lou Franco   Manual mutation testing — deliberately breaking code to verify tests catch the break — reveals a critical gap in most test suites. You can have 100% code coverage and still have untested behavior. A line of code that's executed during tests isn't necessarily tested — the test might not actually verify what that line does. By changing operators, flipping booleans, or altering constants, you discover whether your tests protect against actual logic errors or just exercise code paths. Lou recommends doing this manually as part of your daily practice, but automated tools exist for systematic discovery: Stryker (for JavaScript, C#, Scala) and MutMut (for Python) can mutate your entire codebase and report which mutations survive uncaught. This isn't just about test quality — it's about understanding what your code actually does and building confidence that changes won't introduce subtle bugs. Team-Level Practices: Budgets, Backlogs, and Target Architecture "Create a target architecture document — where would we be if we started over today? Every PR is an opportunity to move slightly toward that target." — Lou Franco   At the team level, Lou advocates for three interconnected practices. First, create a target architecture document that describes where you'd be if starting fresh today — not a detailed design, but architectural patterns, technology choices, and structural principles that represent current best practices. This isn't a rewrite plan; it's a North Star. Every pull request becomes an opportunity to move incrementally toward that target when touching relevant code. Second, establish a budget split between PM-led feature work and engineering-led tech debt work — perhaps 80/20 or whatever ratio fits your product lifecycle stage. This creates predictable capacity for tech debt without requiring constant negotiation. Third, hold quarterly tech debt backlog meetings separate from sprint planning. Treat this backlog like PMs treat product discovery — explore options, estimate impacts, prioritize based on the 8 Questions framework. Some items fit in sprints; others require dedicated engineers for a quarter or two. This systematic approach prevents tech debt from being perpetually deprioritized while avoiding the opposite extreme of engineers disappearing into six-month "improvement" projects with no visible progress. The Atlassian Five-Alarm Fire "The Atlassian CTO's 'five-alarm fire' — stopping all feature development to focus on reliability. I reduced sync errors by 75% during that initiative." — Lou Franco   Lou shares a powerful example of leadership-driven tech debt management at scale. The Atlassian CTO called a "five-alarm fire" — halting all feature development across the company to focus exclusively on reliability and tech debt. This wasn't panic; it was strategic recognition that accumulated debt threatened the business. Lou worked on reducing sync errors, achieving a 75% reduction during this focused period. The initiative demonstrated several leadership principles: willingness to make hard calls that stop revenue-generating feature work, clear communication of why reliability matters strategically, trust that teams will use the time wisely, and commitment to see it through despite pressure to resume features. This level of intervention is rare and shouldn't be frequent, but it shows what's possible when leadership truly prioritizes tech debt. More commonly, leaders should express product lifecycle constraints (startup urgency vs. mature product stability), give teams autonomy to find appropriate projects within those constraints, and require accountability through visible metrics and dashboards that show progress. The Rewrite Trap: Why Big Rewrites Usually Fail "A system that took 10 years to write has implicit knowledge that can't be replicated in 6 months. I'm mostly gonna advocate for piecemeal migrations along the way, reducing the size of the problem over time." — Lou Franco   Lou lived through Trello's iOS navigation rewrite — a classic example of throwing away working code to start fresh, only to discover all the edge cases, implicit behaviors, and user expectations baked into the "old" system. A codebase that evolved over several years contains implicit knowledge — user workflows, edge case handling, performance optimizations, and subtle behaviors that users rely on even if they never explicitly requested them. Attempting to rewrite this in six months inevitably misses critical details. Lou strongly advocates for piecemeal migrations instead. The Trello "Decaffeinate Project" exemplifies this approach — migrating from CoffeeScript to TypeScript incrementally, with public dashboards showing the percentage remaining, interoperable technologies allowing gradual transition, and the ability to pause or reverse if needed. Keep both systems running in parallel during migrations. Use runtime observability to verify new code behaves identically to old code. Reduce the problem size steadily over months rather than attempting big-bang replacements. The only exception: sometimes keeping parallel systems requires scaffolding that creates its own complexity, so evaluate whether piecemeal migration is actually simpler or if you're better off living with the current system. Making Tech Debt Visible Through Dashboards "Put up a dashboard, showing it happen. Make invisible internal improvements visible through metrics engineering leadership understands." — Lou Franco   One of tech debt's biggest challenges is invisibility — non-technical stakeholders can't see the improvement from refactoring or test coverage. Lou learned to make tech debt work visible through dashboards and metrics. The Decaffeinate Project tracked percentage of CoffeeScript files remaining, providing a clear progress indicator anyone could understand. When reducing sync errors, Lou created dashboards showing error rates declining over time. These visualizations serve multiple purposes: they demonstrate value to leadership, create accountability for engineering teams, build momentum as progress becomes visible, and help teams celebrate wins that would otherwise go unnoticed. The key is choosing metrics that matter to the business — error rates, page load times, deployment frequency, mean time to recovery — rather than pure code quality metrics like cyclomatic complexity that don't translate outside engineering. Connect tech debt work to customer experience, reliability, or developer productivity in ways leadership can see and value. Onboarding as a Tech Debt Opportunity "Unit testing is a really great way to learn a system. It's like an executable specification that's helping you prove that you understand the system." — Lou Franco   Lou identifies onboarding as an underutilized opportunity for tech debt reduction. When new engineers join, they need to learn the codebase. Rather than just reading code or shadowing, Lou suggests having them write unit tests in areas they're learning. This serves dual purposes: tests are executable specifications that prove understanding of system behavior, and they create safety nets in areas that likely lack coverage (otherwise, why would new engineers be confused by the code?). The new engineer gets hands-on learning, the team gets better test coverage, and everyone wins. This practice also surfaces confusing code — if new engineers struggle to understand what to test, that's a signal the code needs clarifying comments, better naming, or refactoring. Make onboarding a systematic tech debt reduction opportunity rather than passive knowledge transfer. Leadership's Role: Constraints, Autonomy, and Accountability "Leadership needs to express the constraints. Tell the team what you're feeling about tech debt at a high level, and what you think generally is the appropriate amount of time to be spent on it. Then give them autonomy." — Lou Franco   Lou distills leadership's role in tech debt management to three elements. First, express constraints — communicate where you believe the product is in its lifecycle (early startup, rapid growth, mature cash cow) and what that means for tech debt tolerance. Are we pursuing product-market fit where code might be thrown away? Are we scaling a proven product where reliability matters? Are we maintaining a stable system where operational efficiency pays dividends? These constraints help teams make appropriate trade-offs. Second, give autonomy — once constraints are clear, trust teams to identify specific tech debt projects that fit those constraints. Engineers understand the codebase's pain points better than leaders do. Third, require accountability — teams must make their work visible through dashboards, metrics, and regular updates. Autonomy without accountability becomes invisible engineering projects that might not deliver value. Accountability without autonomy becomes micromanagement that wastes engineering judgment. The balance creates space for teams to make smart decisions while keeping leadership informed and confident in the investment. AI and the Future of Tech Debt "I really do AI-assisted software engineering. And by that, I mean I 100% review every single line of that code. I write the tests, and all the code is as I would have written it, it's just a lot faster. Developers are still responsible for it. Read the code." — Lou Franco   Lou has a chapter about AI in his book, addressing the elephant in the room: will AI-generated code create massive tech debt? His answer is nuanced. AI can accelerate development tremendously if used correctly — Lou uses it extensively but reviews every single line, writes all tests himself, and ensures the code matches what he would have written manually. The problem emerges with "vibe coders" — non-developers using AI to generate code they don't understand, creating unmaintainable messes that become someone else's problem. Developers remain responsible for all code, regardless of how it's generated. This means you must read and understand AI-generated code, not blindly accept it. Lou also raises supply chain security concerns — dependencies can contain malicious code, and AI might introduce vulnerabilities developers miss. His recommendation: stay six months behind on dependency updates, let others discover the problems first, and consider separate sandboxed development machines to limit security exposure. AI is a powerful tool, but it doesn't eliminate the need for engineering judgment, testing discipline, or code review practices. The Style Guide Beyond Formatting "Have a style guide that goes beyond formatting to include target architecture. This is the kind of code we want to write going forward." — Lou Franco   Lou advocates for style guides that extend beyond tabs-versus-spaces formatting rules to include architectural guidance. Document patterns you want to move toward: how should components be structured, what state management approaches do we prefer, how should we handle errors, what testing patterns should we follow? This creates a shared understanding of the target architecture without requiring a massive design document. When reviewing pull requests, teams can reference the style guide to explain why certain approaches align with where the codebase is headed versus perpetuating old patterns. This makes tech debt conversations less personal and more objective — it's not about criticizing someone's code, it's about aligning with team standards and strategic direction. The style guide becomes a living document that evolves as the team learns and technology changes, capturing collective wisdom about what good code looks like in your specific context. Recommended Resources Some of the resources mentioned in this episode include:  Steve Blank's Four Steps To Epiphany The podcast episode with Bernie Maloney where we discuss the critical difference between "enterprise" and "startup". And Geoffrey Moore's Crossing the Chasm, and Dealing with Darwin.   About Lou Franco   Lou Franco is a veteran software engineer and author of Swimming in Tech Debt. With decades of experience at startups, as well as Trello, and Atlassian, he's seen both sides of debt—as coder and leader. Today, he advises teams on engineering practices, helping them turn messy codebases into momentum.   You can link with Lou Franco on LinkedIn and learn more at LouFranco.com.

BONUS: The Agile Organization as a Learning System Think Like a Farmer, Not a Factory Manager "Go slow to go fast. If you want to go somewhere, go together as a team. Take a farmer's mentality."   Simon contrasts monoculture industrial thinking with the permaculture approach of Joel Salatin. Industrial approaches optimize for short-term efficiency but create fragile systems. Farmer thinking recognizes that healthy ecosystems require patience, diversity, and nurturing conditions for growth. The nervous system that's constantly stressed never builds much over time—think of the body, trust the body, let the body be a body. Value Masters, Not Scrum Masters "We need value masters, not Scrum Masters. Agile is a useful tool for delivering value, but value itself is primary. Everything else is secondary—Agile included."   Tom makes his most provocative point: if you asked a top manager whether they'd prefer an agile person or value delivery, the answer is obvious. Agile is one tactic among many for delivering value—not even a necessary one. The shift required is from process mastery to value mastery, from Scrum Masters to people who understand and can deliver on critical stakeholder values. The DOVE Manifesto "I wrote a paper called DOVE—Deliver Optimum Values Efficiently. It's the manifesto focusing on delivering value, delivering value, delivering value."   Tom offers his alternative to the Agile Manifesto: a set of principles laser-focused on value delivery. The document includes 10 principles on a single page that can guide any organization toward genuine impact. Everything else—processes, frameworks, methodologies—are secondary tools in service of this primary goal. Read Tom's DOVE manifesto here.  Building the Glue Between Social and Physical Technology "Value is created in interactions. That's where the social and physical technology meet—that joyous boundary where stuff gets done."   Simon describes seeing the world through two lenses: physical technology (visible tools and systems) and social technology (culture, relationships, the air we breathe). Eric Beinhoeker's insight is that progress happens at the intersection. The Gilbian learning loops provide the structure; trust and human connection provide the fuel. Together, they create organizations that can actually learn and adapt.   Further Reading To Support Your Learning Journey Resources & Further Reading Explore these curated resources to deepen your understanding of strategic planning, value-based management, and transformative organizational change.    

BONUS: Quality 5.0—Quantifying the "Unmeasurable" With Tom Gilb and Simon Holzapfel Clarification Before Quantification "Quantification is not the main idea. The key idea is clarification—so that the executive team understands each other."   Tom emphasizes that measurement is a means to an end. The real goal is shared understanding. But quantification is a powerful clarification tactic because it forces precision. When someone says they want a "very fast car," asking "can we define a scale of measure?" immediately surfaces the vagueness. Miles per hour? Acceleration time? Top speed? Each choice defines what you're actually optimizing for. The Scale-Meter-Target Framework "First, define a scale of measure. Second, define the meter—the device for measuring. Third, set numbers: where are we now, what's the minimum to survive, and what does success look like?"   Tom's framework makes the abstract concrete:   Scale of measure: What dimension are you measuring? (e.g., time to complete task) Meter: How will you measure it? (e.g., user testing with stopwatch) Past/Status: Where are you now? (e.g., currently takes 47 seconds) Tolerable: What's the minimum acceptable? (e.g., must be under 30 seconds to survive) Target/Goal: What does success look like? (e.g., 15 seconds or less)   Many important concepts like "usability" decompose into 10+ different scales of measure—you're not looking for one magic number but a set of relevant metrics. Trust as the Organizational Hormone "Change moves at the speed of trust. Once there's trust, information flows. Once information flows, the system comes to life and can learn. Until there's trust, you have the Soviet problem."   Simon introduces trust as the "human growth hormone" of organizational change—it's fast, doesn't require a user's manual, and enables everything else. Low-trust environments hoard information, guaranteeing poor outcomes. The practical advice? Make your work visible to your manager, alignment-check first, do something, show results. Living the learning cycle yourself builds trust incrementally. And as Tom adds: if you deliver increased critical value every week, you will build trust.   About Tom Gilb and Simon Holzapfel   Tom Gilb, born in the US, lived in London, and then moved to Norway in 1958. An independent teacher, consultant, and writer, he has worked in software engineering, corporate top management, and large-scale systems engineering. As the saying goes, Tom was writing about Agile before Agile was named. In 1976, Tom introduced the term "evolutionary" in his book Software Metrics, advocating for development in small, measurable steps. Today, we talk about Evo, the name Tom uses to describe his approach. Tom has worked with Dr. Deming and holds a certificate personally signed by him. You can listen to Tom Gilb's previous episodes here.    You can link with Tom Gilb on LinkedIn    Simon Holzapfel is an educator, coach, and learning innovator who helps teams work with greater clarity, speed, and purpose. He specializes in separating strategy from tactics, enabling short-cycle decision-making and higher-value workflows. Simon has spent his career coaching individuals and teams to achieve performance with deeper meaning and joy. Simon is also the author of the Equonomist newsletter on Substack. And you can listen to Simon's previous episodes on the podcast here.    You can link with Simon Holzapfel on LinkedIn.  

BONUS: Testing as Measurement—Why Bug-Hunting Misses the Point With Tom Gilb and Simon Holzapfel The Revelation That Almost Caused a Car Crash "Tom said like 10 sentences in a row, kind of like a geometric proof, that just so blew my mind I almost drove off the road. I realized I had wasted hundreds of hours in boardrooms arguing about errors of which we were aware of perhaps 10%."   Simon shares the moment Tom's framework clicked for him. The insight? Traditional testing—finding bugs and defects—is the wrong focus entirely. It's a programmer's view of the world. Managers don't care about bugs; they care about results, about improvements in their business. Tom calls this shift moving from "testing" to "measurement of enhanced or increased value at every cycle." The American Toast Problem "How do we make toast in America? We burn the toast, and then we pay someone to scrape off the black bits off the bread."   Vasco invokes Deming's classic analogy to describe traditional software testing. The entire testing-at-the-end approach is fundamentally wasteful. Instead, Tom advocates for continuous measurement against quantified values. If you expected 3% progress toward your goals this week and didn't get it, you've learned something critical: your strategy needs to change. If you did get it, keep going with confidence. Four Questions at Every Checkpoint "Where are we going? Where are we now? Where should we have been at this point? And why is there a gap?"   Drawing from fighter pilot doctrine, these four questions should be asked at every micro-cycle—not just at quarterly reviews. Fighter pilots ask these questions every minute during critical missions, with clear abort criteria if answers are unacceptable. Most organizations have no abort criteria for their strategies at all, guaranteeing they'll discover failures far too late.   About Tom Gilb and Simon Holzapfel   Tom Gilb, born in the US, lived in London, and then moved to Norway in 1958. An independent teacher, consultant, and writer, he has worked in software engineering, corporate top management, and large-scale systems engineering. As the saying goes, Tom was writing about Agile before Agile was named. In 1976, Tom introduced the term "evolutionary" in his book Software Metrics, advocating for development in small, measurable steps. Today, we talk about Evo, the name Tom uses to describe his approach. Tom has worked with Dr. Deming and holds a certificate personally signed by him. You can listen to Tom Gilb's previous episodes here.    You can link with Tom Gilb on LinkedIn    Simon Holzapfel is an educator, coach, and learning innovator who helps teams work with greater clarity, speed, and purpose. He specializes in separating strategy from tactics, enabling short-cycle decision-making and higher-value workflows. Simon has spent his career coaching individuals and teams to achieve performance with deeper meaning and joy. Simon is also the author of the Equonomist newsletter on Substack. And you can listen to Simon's previous episodes on the podcast here.    You can link with Simon Holzapfel on LinkedIn.

BONUS: Continuous Strategy Engineering—Beyond Waterfall Planning With Tom Gilb and Simon Holzapfel Strategy Professors Are Decades Behind "The professors of strategy have no clue as to what Evo is. They are locked in decades ago, waterfall mode."   Tom's analysis is stark: the people teaching strategy in business schools haven't undergone the same agile transformation that software development experienced. They still think in terms of 5-year plans that get tested at the end—a guaranteed recipe for discovering failure too late. The alternative? Decompose any large strategy into weekly value delivery steps. And if you think that's impossible, ask any AI to do it for you—it will produce 52 reasonable weekly increments in about a minute. Why OKRs Aren't Enough for Complex Systems "If you're doing small-scale stuff that OKRs were designed for, like planning your personal work 14 days hence, OKRs are wonderful. If you're designing the air traffic control system for Europe, they're just too simple."   Tom distinguishes between tools appropriate for personal productivity and those needed for complex organizational strategy. OKRs force some thinking, which is good, but they weren't designed for—and have never been adapted to—large-scale systems engineering. His paper "What is Wrong with OKRs?" documents roughly 100 gaps between simple OKRs and what robust value requirements actually require. Check out Tom Gilb's paper on what's wrong with OKR's and how to fix it.  The Missing Alignment Layer "We have no mental model for most of leadership about how you actually align people around clear vision."   Simon introduces the concept of a Hoshin-Kanri "sprinkler" system—imagine strategic clarity flowing from the top and misting over everyone's desk as alignment. Most organizations lack anything resembling this. They have Moses descending from expensive consultant retreats with tablets, but no continuous two-way flow of strategic information. The result? Teams work hard on things that don't matter while critical values go unaddressed. About Tom Gilb and Simon Holzapfel   Tom Gilb, born in the US, lived in London, and then moved to Norway in 1958. An independent teacher, consultant, and writer, he has worked in software engineering, corporate top management, and large-scale systems engineering. As the saying goes, Tom was writing about Agile before Agile was named. In 1976, Tom introduced the term "evolutionary" in his book Software Metrics, advocating for development in small, measurable steps. Today, we talk about Evo, the name Tom uses to describe his approach. Tom has worked with Dr. Deming and holds a certificate personally signed by him. You can listen to Tom Gilb's previous episodes here.    You can link with Tom Gilb on LinkedIn    Simon Holzapfel is an educator, coach, and learning innovator who helps teams work with greater clarity, speed, and purpose. He specializes in separating strategy from tactics, enabling short-cycle decision-making and higher-value workflows. Simon has spent his career coaching individuals and teams to achieve performance with deeper meaning and joy. Simon is also the author of the Equonomist newsletter on Substack. And you can listen to Simon's previous episodes on the podcast here.    You can link with Simon Holzapfel on LinkedIn.

BONUS: Impact Engineering—Finding Agile's Lost North Star With Tom Gilb and Simon Holzapfel The Clarity Problem: Why Organizations Start with "Fuzzy B*S*!" "Everybody seems to start from a position of fuzzy b*s*. Nice-sounding words. Management does it, professors do it, politicians do it. And they don't even feel very guilty about it."   Tom Gilb doesn't mince words when describing how most organizations define their objectives. The fundamental problem isn't a lack of ambition—it's a lack of clarity. When leaders are asked about their critical values like "extremely high security" or "employee happiness," they typically respond with circular definitions that provide no actionable direction. Tom's approach starts by exposing this gap and then demonstrating that any value—no matter how "soft" or intangible it seems—can be quantified. Using AI tools, he's shown clients over 1,400 different ways to measure human happiness alone. Why Agile Lost Its North Star "Agile's lost its North Star because the economic problems it was trying to solve within the organization are now mismatched with the digital world."   Simon Holzapfel offers a structural analysis: Agile developed primarily to allay the concerns of pre-digital capital—investors who needed reassurance that their money wouldn't disappear into failed projects. But today's digital economy operates differently. Capital now moves like a service (SaaS model), and innovation is fundamentally stochastic—you can't predict when breakthroughs will happen. Organizations using flow-focused tools when the real problem is value creation are applying yesterday's solutions to today's challenges. The First Step: Quantify Your Critical Values "If you ask AI to quantify employee happiness a hundred different ways, it will do it in one minute for free. So you can no longer be in denial."   The path forward starts with brutal honesty about what your organization actually cares about. Tom's approach involves:   Identifying the top 10 critical stakeholder values Defining clear scales of measure for each Establishing where you are now (status) Setting where you need to be to survive (tolerable level) Defining what success looks like (target/goal level)   This isn't about adding bureaucracy—it's about creating shared clarity that enables everyone to row in the same direction.   About Tom Gilb and Simon Holzapfel   Tom Gilb, born in the US, lived in London, and then moved to Norway in 1958. An independent teacher, consultant, and writer, he has worked in software engineering, corporate top management, and large-scale systems engineering. As the saying goes, Tom was writing about Agile before Agile was named. In 1976, Tom introduced the term "evolutionary" in his book Software Metrics, advocating for development in small, measurable steps. Today, we talk about Evo, the name Tom uses to describe his approach. Tom has worked with Dr. Deming and holds a certificate personally signed by him. You can listen to Tom Gilb's previous episodes here.    You can link with Tom Gilb on LinkedIn    Simon Holzapfel is an educator, coach, and learning innovator who helps teams work with greater clarity, speed, and purpose. He specializes in separating strategy from tactics, enabling short-cycle decision-making and higher-value workflows. Simon has spent his career coaching individuals and teams to achieve performance with deeper meaning and joy. Simon is also the author of the Equonomist newsletter on Substack. And you can listen to Simon's previous episodes on the podcast here.    You can link with Simon Holzapfel on LinkedIn.

Scott Smith: Empathy and Availability Define Excellent Product Ownership 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: Always Present, Always Available, Always Curious "They are always present. They always make themselves available for team members that need them." - Scott Smith   Scott is currently working with a Product Owner who exemplifies what great PO collaboration looks like. This person is always present—not just physically but mentally engaged with the team's work and challenges. They make themselves available for team members who need them, responding actively on the team chat and interacting consistently.  What makes this PO stand out is their empathy and curiosity. Instead of being defensive when questions arise or challenges emerge, they lean into helping the team understand and solve problems. They show genuine curiosity about what the team is experiencing, asking questions and exploring solutions together rather than dictating answers.  This PO understands that their role isn't to be the smartest person in the room but to be the most available, most collaborative, and most curious. The result is a team that feels supported and empowered, with clear direction and someone who genuinely helps them answer the hard questions. Scott's experience with this PO demonstrates that presence, availability, empathy, and curiosity are the foundations of great Product Owner work.   Self-reflection Question: How present and available are you to your team, and do you approach their questions with curiosity or defensiveness? The Bad Product Owner: Never There When the Team Needs Direction "The PO was never present. The team had lack of clarity, and vision, and had no direction or someone who would help answer those questions." - Scott Smith   Scott has also experienced the opposite extreme—a Product Owner who was never present. This absence created a cascade of problems for the team. Without regular access to the PO, the team lacked clarity about priorities, vision, and direction. They had questions that went unanswered and decisions that couldn't be made.  The result was frustration and a team that couldn't move forward effectively. An absent PO creates a vacuum where uncertainty thrives. Teams end up making assumptions, second-guessing decisions, and feeling disconnected from the purpose of their work.  The lack of someone who can help answer strategic questions or provide guidance means the team operates in the dark, building things without confidence that they're building the right things. Scott's experience highlights a fundamental truth about Product Ownership: presence isn't optional.  Teams need a PO who shows up, engages, and stays connected to the work. Without that presence, even the most skilled team will struggle to deliver value because they can't align their efforts with the product vision and customer needs.   Self-reflection Question: If your team were asked whether you're present and available as a Product Owner or Scrum Master, what would they say?   [The Scrum Master Toolbox Podcast Recommends]

Scott Smith: Using MIRO to Build a Living Archive 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.   "We're in a servant leadership role. So, ask: is the team thriving? That's a huge indication of success." - Scott Smith   For Scott, success as a Scrum Master isn't measured by velocity charts or burn-down graphs—it's measured by whether the people are thriving. This includes everyone: the development team and the Product Owner.  As a servant leader, Scott's focus is on creating conditions where teams can flourish, and he has practical ways to gauge that health. Scott does a light touch check on a regular basis and a deeper assessment quarterly. Mid-sprint, he conducts what he calls a "vibe" check—a quick pulse to understand how people are feeling and what they need. During quarterly planning, the team retrospects and celebrates achievements from the past quarter, keeping and tracking actions to ensure continuous improvement isn't just talked about but lived. Scott's approach recognizes that success is both about the work being done and the people doing it. When teams feel supported, heard, and valued, the work naturally flows better. This people-first perspective defines what great servant leadership looks like in practice.   Self-reflection Question: How often do you check in on whether your team is truly thriving, and what specific indicators tell you they are? Featured Retrospective Format for the Week: MIRO as a Living History Museum "Use the multiple retros in the MIRO board as a shared history museum for the team." - Scott Smith   Scott leverages MIRO not just as a tool for running retrospectives but as a living archive of team learning and growth. He uses MIROVERSE templates to bring diversity to retrospective conversations, exploring the vast library of pre-built formats that offer themed and structured approaches to reflection. The magic happens when Scott treats each retrospective board not as a disposable artifact but as part of the team's shared history museum.  Over time, the accumulation of retrospective boards tells the story of the team's journey—what they struggled with, what they celebrated, what actions they took, and how they evolved. This approach transforms retrospectives from isolated events into a continuous narrative of improvement. Teams can look back at previous retros to see patterns, track whether actions were completed, and recognize how far they've come. MIRO becomes both the canvas for current reflection and the archive of collective learning, making improvement visible and tangible across time.   [The Scrum Master Toolbox Podcast Recommends]

Scott Smith: Building a Coaching Service Where Survey Scores Become Living Improvement 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 about feedback from coaching clients." - Scott Smith   Scott is tackling one of the most challenging aspects of organizational transformation: turning annual survey results into continuous improvement. Working with a domain of about 30 people, Scott is exploring how to create a coaching service that doesn't just react to once-a-year data but actively drives ongoing growth. The typical pattern in many organizations is familiar—conduct an annual survey, review the scores, maybe have a few discussions, and then wait another year. Scott is experimenting with a different approach.  He's setting up a coaching service that focuses on real-time feedback from the people being coached, making improvement a living practice rather than an annual event. The strategy starts with a pilot, testing the concept before scaling across the entire domain. Scott's measure of success is pragmatic and human-centered: feedback from coaching clients. Not abstract metrics or theoretical frameworks, but whether the people receiving coaching find value in what's being offered.  This approach reflects a fundamental principle of Agile coaching—start small, experiment, gather feedback, and iterate based on what actually works for the people involved. Scott is building improvement infrastructure that puts continuous learning at the center, transforming how organizations think about growth from an annual checkbox into an ongoing conversation.   Self-reflection Question: If you were to implement a coaching service in your organization, how would you measure its success beyond traditional survey scores?   [The Scrum Master Toolbox Podcast Recommends]

Scott Smith: Why Great Scrum Masters Create Space for Breaks 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.   "Think of the people involved. Put yourself in the shoes of the other." - Scott Smith   Scott found himself in the middle of rising tension as voices escalated between the Product Owner and the development team. The PO was harsh, emotions were running high, and the conflict was intensifying with each exchange. In that moment, Scott knew he had to act.  He stepped in with a simple but powerful reminder: "We're on the same team." That pause—that momentary break—allowed everyone to step back and reset. Both the PO and the team members later thanked Scott for his intervention, acknowledging they needed that space to cool down and refocus on their shared outcome.  Scott's approach centers on empathy and perspective-taking. He emphasizes thinking about the people involved and putting yourself in their shoes. When tensions rise, sometimes the most valuable contribution a Scrum Master can make is creating space for a break, reminding everyone of the shared goal, and helping teams focus on the outcome rather than the conflict. It's not about taking sides—it's about serving the team by being the calm presence that brings everyone back to what matters most.   Self-reflection Question: When you witness conflict between team members or between the team and Product Owner, do you tend to jump in immediately or create space for the parties to find common ground themselves? Featured Book of the Week: An Ex-Manager Who Believed "It was about having someone who believed in me." - Scott Smith   Scott's most influential "book" isn't printed on pages—it's a person. After spending 10 years as a Business Analyst, Scott decided to take the Professional Scrum Master I (PSM I) course and look for a Scrum Master position. That transition wasn't just about skills or certification; it was about having an ex-manager who inspired him to chase his goals and truly believed in him. This person gave Scott the confidence to make a significant career pivot, demonstrating that sometimes the most powerful catalyst for growth is someone who sees your potential before you fully recognize it yourself. Scott's story reminds us that great leadership isn't just about managing tasks—it's about inspiring people to reach for goals they might not have pursued alone. The belief and encouragement of a single person can change the trajectory of someone's entire career.   [The Scrum Master Toolbox Podcast Recommends]

Scott Smith: The Spotlight Failure That Taught a Silent Lesson About Recognition 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.   "Not everybody enjoys the limelight and being called out, even for great work." - Scott Smith   Scott was facilitating a multi-squad showcase with over 100 participants, and everything seemed to be going perfectly. Each squad had their five-minute slot to share achievements from the sprint, and Scott was coordinating the entire event. When one particular team member delivered what Scott considered fantastic work, he couldn't help but publicly recognize them during the introduction.  It seemed like the perfect moment to celebrate excellence in front of the entire organization. But then his phone rang. The individual he had praised was unhappy—really unhappy. What Scott learned in that moment transformed his approach to recognition forever. The person was quiet, introverted, and conservative by nature.  Being called out without prior notice or permission in front of 100+ people wasn't a reward—it was uncomfortable and unwelcome. Scott discovered that even positive recognition requires consent and awareness of individual preferences. Some people thrive in the spotlight, while others prefer their contributions to be acknowledged privately. The relationship continued well afterward, but the lesson stuck: check in with individuals before publicly recognizing them, understanding that great coaching means respecting how people want to be celebrated, not just that they should be celebrated.   Self-reflection Question: How do you currently recognize team members' achievements, and have you asked each person how they prefer to be acknowledged for their contributions?   [The Scrum Master Toolbox Podcast Recommends]

BONUS: When AI Knows Your Emotional Triggers Better Than You Do — Navigating Mindfulness in the AI Age In this thought-provoking conversation, former computer engineer and mindfulness leader Mo Edjlali explores how AI is reshaping human meaning, attention, and decision-making. We examine the critical question: what happens when AI knows your emotional triggers better than you know yourself? Mo shares insights on remaining sovereign over our attention, avoiding dependency in both mindfulness and technology, and preparing for a world where AI may outperform us in nearly every domain. From Technology Pioneer to Mindfulness Leader "I've been very heavily influenced by technology, computer engineering, software development. I introduced DevOps to the federal government. But I have never seen anything change the way in which human beings work together like Agile." — Mo Edjlali   Mo's journey began in the tech world — graduating in 1998, he was on the front line of the internet explosion. He remembers the days before the internet, watched online multiplayer games emerge in 1994, and worked on some of the most complicated tech projects in federal government. Technology felt almost like magic, advancing at a logarithmic rate faster than anything else. But when Mo discovered mindfulness practices 12-15 years ago, he found something equally transformative: actual exercises to develop emotional intelligence and soft skills that the tech world talked about but never taught. Mindfulness provided logical, practical methods that didn't require "woo-woo" beliefs — just practice that fundamentally changed his relationship with his mind. This dual perspective — tech innovator and mindfulness teacher — gives Mo a unique lens for understanding where we're headed. The Shift from Liberation to Dependency "I was fortunate enough, the teachers I was exposed to, the mentality was very much: you're gonna learn how to meditate on your own, in silence. There is no guru. There is no cult of personality." — Mo Edjlali   Mo identifies a dangerous drift in the mindfulness movement: from teaching independence to creating dependency. His early training, particularly a Vipassana retreat led by S.N. Goenka, modeled true liberation — you show up for 10 days, pay nothing, receive food and lodging, learn to meditate, then donate what you can at the end. Critically, you leave being able to meditate on your own without worshiping a teacher or subscribing to guided meditations. But today's commercialized mindfulness often creates the opposite: powerful figures leading fiefdoms, consumers taught to listen to guided meditations rather than meditate independently. This dependency model mirrors exactly what's happening with AI — systems designed to make us rely on them rather than empower our own capabilities. Recognizing this parallel is essential for navigating both fields wisely. AI as a New Human Age, Not Just Another Tool "With AI, this is different. This isn't like mobile computing, this isn't like the internet. We're entering a new age. We had the Bronze Age, the Iron Age, the Industrial Age. When you enter a new age, it's almost like knocking the chess board over, flipping the pieces upside down. We're playing a new game." — Mo Edjlali   Mo frames AI not as another technology upgrade but as the beginning of an entirely new human age. In a new age, everything shifts: currency, economies, government, technology, even religions. The documentary about the Bronze Age collapse taught him that when ages turn over, the old rules no longer apply. This perspective explains why AI feels fundamentally different from previous innovations. ChatGPT 2.0 was interesting; ChatGPT 3 blew Mo's mind and made him realize we're witnessing something unprecedented. While he's optimistic about the potential for sustainable abundance and extraordinary breakthroughs, he's also aware we're entering both the most exciting and most frightening time to be alive. Everything we learned in high school might be proven wrong as AI rewrites human knowledge, translates animal languages, extends longevity, and achieves things we can't even imagine. The Mental Health Tsunami and Loss of Purpose "If we do enter the age of abundance, where AI could do anything that human beings could do and do it better, suddenly the system we have set up — where our purpose is often tied to our income and our job — suddenly, we don't need to work. So what is our purpose?" — Mo Edjlali   Mo offers a provocative vision of the future: a world where people might pay for jobs rather than get paid to work. It sounds crazy until you realize it's already happening — people pay $100,000-$200,000 for college just to get a job, politicians spend millions to get elected. If AI handles most work and we enter an age of abundance, jobs won't be about survival or income — they'll be about meaning, identity, and social connection. This creates three major crises Mo sees accelerating: attacks on our focus and attention (technology hijacking our awareness), polarization (forcing black-and-white thinking), and isolation (pushing us toward solo experiences). The mental health tsunami is coming as people struggle to find purpose in a world where AI outperforms them in domain after domain. The jobs will change, the value systems will shift, and those without tools for navigating this transformation will suffer most. When AI Reads Your Mind "Researchers at Duke University had hooked up fMRI brain scanning technology and took that data and fed it into GPT 2. They were able to translate brain signals into written narrative. So the implications are that we could read people's minds using AI." — Mo Edjlali   The future Mo describes isn't science fiction — it's already beginning. Three years ago, researchers used early GPT to translate brain signals into written text by scanning people's minds with fMRI and training AI on the patterns. Today, AI knows a lot about heavy users like Mo through chat conversations. Tomorrow, AI will have video input of everything we see, sensory input from our biometrics (pulse, heart rate, health indicators), and potentially direct connection to our minds. This symbiotic relationship is coming whether we're ready or not. Mo demonstrates this with a personal experiment: he asked his AI to tell him about himself, describe his personality, identify his strengths, and most powerfully — reveal his blind spots. The AI's response was outstanding, better than what any human (even his therapist or himself) could have articulated. This is the reality we're moving toward: AI that knows our emotional triggers, blind spots, and patterns better than we do ourselves. Using AI as a Mirror for Self-Discovery "I asked my AI, 'What are my blind spots?' Human beings usually won't always tell you what your blind spots are, they might not see them. A therapist might not exactly see them. But the AI has... I've had the most intimate kind of conversations about everything. And the response was outstanding." — Mo Edjlali   Mo's approach to AI is both pragmatic and experimental. He uses it extensively — at the level of teenagers and early college students who are on it all the time. But rather than just using AI as a tool, he treats it as a mirror for understanding himself. Asking AI to identify your blind spots is a powerful exercise because AI has observed all your conversations, patterns, and tendencies without the human limitations of forgetfulness or social politeness. Vasco shares a similar experience using AI as a therapy companion — not replacing his human therapist, but preparing for sessions and processing afterward. This reveals an essential truth: most of us don't understand ourselves that well. We're blind navigators using an increasingly powerful tool. The question isn't whether AI will know us better than we know ourselves — that's already happening. The question is how we use that knowledge wisely. The Danger of AI Hijacking Our Agency "There's this real danger. I saw that South Park episode about ChatGPT where his wife is like, 'Come on, put the AI down, talk to me,' and he's got this crazy business idea, and the AI keeps encouraging him along. It's a point where he's relying way too heavily on the AI and making really poor decisions." — Mo Edjlali   Not all AI use is beneficial. Mo candidly admits his own mistakes — sometimes leaning into AI feedback over his actual users' feedback for his Meditate Together app because "I like what the AI is saying." This mirrors the South Park episode's warning about AI dependency, where the character's AI encourages increasingly poor decisions while his relationships suffer. Social media demonstrates this danger at scale: AI algorithms tuned to steal our attention and hijack our agency, preventing us from thinking about what truly matters — relationships and human connection. Mo shares a disturbing story about Zoom bombers disrupting Meditate Together sessions, filming it, posting it on YouTube where it got 90,000 views, with comments thanking the disruptors for "making my day better." Technology created a cannibalistic dynamic where teenagers watched videos of their mothers, aunts, and grandmothers being harassed during meditation. When Mo tried to contact Google, the company's incentive structure prioritized views and revenue over human decency. Technology combined with capitalism creates these dangerous momentum toward monetizing attention at any cost. Remaining Sovereign Over Your Attention "Traditionally, mindfulness does an extraordinary job, if you practice right, to help you regain your agency of your focus and concentration. It takes practice. But reading is now becoming a concentration practice. It's an actual practice." — Mo Edjlali   Mo identifies three major symptoms affecting us: attacks on focus/attention, polarization into black-and-white thinking, and isolation. Mindfulness practices directly counter all three — but only if practiced correctly. Training attention, focus, and concentration requires actual practice, not just listening to guided meditations. Mo offers practical strategies: reading as concentration practice (asking "does anyone read anymore?" recognizing that sustained reading now requires deliberate effort), turning off AirPods while jogging or driving to find silence, spending time alone with your thoughts, and recognizing that we were given extraordinary power (smartphones) with zero training on how to be aware of it. Older generations remember having to rewind VHS tapes — forced moments of patience and stillness that no longer exist. We need to deliberately recreate those spaces where we're not constantly consuming entertainment and input. Dialectic Thinking: Beyond Polarization "I saw someone the other day wear a shirt that said, 'I'm perfect the way I am.' That's one-dimensional thinking. Two-dimensional thinking is: you're perfect the way that you are, and you could be a little better." — Mo Edjlali   Mo's book OpenMBSR specifically addresses polarization by introducing dialectic thinking — the ability to hold paradoxes and seeming contradictions simultaneously. Social media and algorithms push us toward one-dimensional, black-and-white thinking: good/bad, right/wrong, with me/against me. But reality is far more nuanced. The ability to think "I'm perfect as I am AND I can improve" or "AI is extraordinary AND dangerous" is essential for navigating complexity. This mirrors the tech world's embrace of continuous improvement in Agile — accepting where you are while always pushing for better. Chess players learned this years ago when AI defeated humans — they didn't freak out, they accepted it and adapted. Now AI in chess doesn't just give answers; it helps humans understand how it arrived at those answers. This partnership model, where AI coaches us through complexity rather than simply replacing us, represents the healthiest path forward. Building Community, Not Dependency "When people think to meditate, unfortunately, they think, I have to do this by myself and listen to guided meditation. I'm saying no. Do it in silence. If you listen to guided meditation, listen to guided meditation that teaches you how to meditate in silence. And do it with other people, with intentional community." — Mo Edjlali   Mo's OpenMBSR initiative explicitly borrows from the Agile movement's success: grassroots, community-centric, open source, transparent. Rather than creating fiefdoms around cult personalities, he wants mindfulness to spread organically through communities helping communities. This directly counters the isolation trend that technology accelerates. Meditate Together exists specifically to create spaces where people meditate with other human beings around the world, with volunteer hosts holding sessions. The model isn't about dependency on a teacher or platform — it's about building connection and shared practice. This aligns perfectly with how the tech world revolutionized collaborative work through Agile and Scrum: transparent, iterative, valuing individuals and interactions. The question for both mindfulness and AI adoption is whether we'll create systems that empower independence and community, or ones that foster dependency and isolation. Preparing for a World Where AI Outperforms Humans "AI is going to need to kind of coach us and ease us into it, right? There's some really dark, ugly things about ourselves that could be jarring without it being properly shared, exposed, and explained." — Mo Edjlali   Looking at his children, Mo wonders what tools they'll need in a world where AI may outperform humans in nearly every domain. The answer isn't trying to compete with AI in calculation, memory, or analysis — that battle is already lost. Instead, the essential human skills become self-awareness, emotional intelligence, dialectic thinking, community building, and maintaining agency over attention and decision-making. AI will need to become a coach, helping humans understand not just answers but how it arrived at those answers. This requires AI development that prioritizes human growth over profit maximization. It also requires humans willing to do the hard work of understanding themselves — confronting blind spots, managing emotional triggers, practicing concentration, and building genuine relationships. The mental health tsunami Mo predicts isn't inevitable if we prepare now by teaching these skills widely, building community-centric systems, and designing AI that empowers rather than replaces human wisdom and connection.   About Mo Edjlali   Mo Edjlali is a former computer engineer, and also the founder and CEO of Mindful Leader, the world's largest provider of Mindfulness-Based Stress Reduction training. Mo's new book Open MBSR: Reimagining the Future of Mindfulness explores how ancient practices can help us navigate the AI revolution with awareness and resilience.   You can learn more about Mo and his work at MindfulLeader.org, check out Meditate Together, and read his articles on AI's Mind-Reading Breakthrough and AI: Not Another Tool, but a New Human Age.

AI Assisted Coding: Building Reliable Software with Unreliable AI Tools In this special episode, Lada Kesseler shares her journey from AI skeptic to pioneer in AI-assisted development. She explores the spectrum from careful, test-driven development to quick AI-driven experimentation, revealing practical patterns, anti-patterns, and the critical role of judgment in modern software engineering. From Skeptic to Pioneer: Lada's AI Coding Journey "I got a new skill for free!"   Lada's transformation began when she discovered Anthropic's Claude Projects. Despite being skeptical about AI tools throughout 2023, she found herself learning Angular frontend development with AI—a technology she had no prior experience with. This breakthrough moment revealed something profound: AI could serve as an extension of her existing development skills, enabling her to acquire new capabilities without the traditional learning curve. The journey evolved through WindSurf and Claude Code, each tool expanding her understanding of what's possible when developers collaborate with AI. Understanding Vibecoding vs. AI-Assisted Development "AI assisted coding requires judgment, and it's never been as important to exercise judgment as now."   Lada introduces the concept of "vibecoding" as one extreme on a new dimension in software development—the spectrum from careful, test-driven development to quick, AI-driven experimentation. The key insight isn't that one approach is superior, but that developers must exercise judgment about which approach fits their context. She warns against careless AI coding for production systems: "You just talk to a computer, you say, do this, do that. You don't really care about code... For some systems, that's fine. When the problem arises is when you put the stuff to production and you really care about your customers. Please, please don't do that." This wisdom highlights that with great power comes great responsibility—AI accelerates both good and bad practices. The Answer Injection Anti-Pattern When Working With AI "You're limiting yourself without knowing, you're limiting yourself just by how you formulate your questions. And it's so hard to detect."   One of Lada's most important discoveries is the "answer injection" anti-pattern—when developers unconsciously constrain AI's responses by how they frame their questions. She experienced this firsthand when she asked an AI about implementing a feature using a specific approach, only to realize later that she had prevented the AI from suggesting better alternatives. The solution? Learning to ask questions more openly and reformulating problems to avoid self-imposed limitations. As she puts it, "Learn to ask the right way. This is one of the powers this year that's been kind of super cool." This skill of question formulation has become as critical as any technical capability.   Answer injection is when we—sometimes, unknowingly—ask a leading question that also injects a possible answer. It's an anti-pattern because LLM's have access to far more information than we do. Lada's advice: "just ask for anything you need", the LLM might have a possible answer for you. Never Trust a Single LLM: Multi-Agent Collaboration "Never trust the output of a single LLM. When you ask it to develop a feature, and then you ask the same thing to look at that feature, understand the code, find the issues with it—it suddenly finds improvements."   Lada shares her experiments with swarm programming—using multiple AI instances that collaborate and cross-check each other's work. She created specialized agents (architect, developer, tester) and even built systems using AppleScript and Tmux to make different AI instances communicate with each other. This approach revealed a powerful pattern: AI reviewing AI often catches issues that a single instance would miss. The practical takeaway is simple but profound—always have one AI instance review another's work, treating AI output with the same healthy skepticism you'd apply to any code review. Code Quality Matters MORE with AI "This thing is a monkey, and if you put it in a good codebase, like any developer, it's gonna replicate what it sees. So it behaves much better in the better codebase, so refactor!"   Lada emphasizes that code quality becomes even more critical when working with AI. Her systems "work silently" and "don't make a lot of noise, because they don't break"—a result of maintaining high standards even when AI makes rapid development tempting. She uses a memorable metaphor: AI is like a monkey that replicates what it sees. Put it in a clean, well-structured codebase, and it produces clean code. Put it in a mess, and it amplifies that mess. This insight transforms refactoring from a nice-to-have into a strategic necessity—good architecture and clean code directly improve AI's ability to contribute effectively. Managing Complexity: The Open Question "If I just let it do things, it'll just run itself to the wall at crazy speeds, because it's really good at running. So I have to be there managing complexity for it."   One of the most honest insights Lada shares is the current limitation of AI: complexity management. While AI excels at implementing features quickly, it struggles to manage the growing complexity of systems over time. Lada finds herself acting as the complexity manager, making architectural decisions and keeping the system maintainable while AI handles implementation details. She poses a critical question for the future: "Can it manage complexity? Can we teach it to manage complexity? I don't know the answer to that." This honest assessment reminds us that fundamental software engineering skills—architecture, refactoring, testing—remain as vital as ever. Context is Everything: Highway vs. Parking Lot "You need to be attuned to the environment. You can go faster or slow, and sometimes going slow is bad, because if you're on a highway, you're gonna get hurt."   Lada introduces a powerful metaphor for choosing development speed: highway versus parking lot. When learning or experimenting with non-critical systems, you can go fast, don't worry about perfection, and leverage AI's speed fully. But when building production systems where reliability matters, different rules apply. The key is matching your development approach to the risk level and context. She emphasizes safety nets: "In one project, we used AI, and we didn't pay attention to the code, as it wasn't important, because at any point, we could actually step back and refactor. We were not unsafe." This perspective helps developers make better judgment calls about when to accelerate and when to slow down. The Era of Discovery: We've Only Just Begun "We haven't even touched the possibilities of what is there out there right now. We're in the era of gentleman scientists—newbies can make big discoveries right now, because nobody knows what AI really is capable of."   Perhaps most exciting is Lada's perspective on where we stand in the AI-assisted development journey: we're at the very beginning. Even the creators of these tools are figuring things out as they go. This creates unprecedented opportunities for practitioners at all levels to experiment, discover patterns, and share learnings with the community. Lada has documented her discoveries in an interactive patterns and anti-patterns website, a Calgary Software Crafters presentation, and her Substack blog—contributing to the collective knowledge base that's being built in real-time. Resources For Further Study Video of Lada's talk: https://www.youtube.com/watch?v=_LSK2bVf0Lc&t=8654s Lada's Patterns and Anti-patterns website: https://lexler.github.io/augmented-coding-patterns/ Lada's Substack https://lexler.substack.com/ AI Assisted Coding episode with Dawid Dahl AI Assisted Coding episode with Llewellyn Falco Claude Flow - orchestration platform   About Lada Kesseler   Lada Kesseler is a passionate software developer specializing in the design of scalable, robust software systems. With a focus on best development practices, she builds applications that are easy to maintain, adapt, and support. Lada combines technical expertise with a keen eye for clean architecture and sustainable code, driving innovation in modern software engineering.   Currently exploring how these values translate to AI-assisted development and figuring out what it takes to build reliable software with unreliable tools.   You can link with Lada Kesseler on LinkedIn.

AI Assisted Coding: Treating AI Like a Junior Engineer - Onboarding Practices for AI Collaboration In this special episode, Sergey Sergyenko, CEO of Cybergizer, shares his practical framework for AI-assisted development built on transactional models, Git workflows, and architectural conventions. He explains why treating AI like a junior engineer, keeping commits atomic, and maintaining rollback strategies creates production-ready code rather than just prototypes. Vibecoding: An Automation Design Instrument "I would define Vibecoding as an automation design instrument. It's not a tool that can deliver end-to-end solution, but it's like a perfect set of helping hands for a person who knows what they need to do."   Sergey positions vibecoding clearly: it's not magic, it's an automation design tool. The person using it must know what they need to accomplish—AI provides the helping hands to execute that vision faster. This framing sets expectations appropriately: AI speeds up development significantly, but it's not a silver bullet that works without guidance. The more you practice vibecoding, the better you understand its boundaries. Sergey's definition places vibecoding in the evolution of development tools: from scaffolding to co-pilots to agentic coding to vibecoding. Each step increases automation, but the human architect remains essential for providing direction, context, and validation. Pair Programming with the Machine "If you treat AI as a junior engineer, it's very easy to adopt it. Ah, okay, maybe we just use the old traditions, how we onboard juniors to the team, and let AI follow this step."   One of Sergey's most practical insights is treating AI like a junior engineer joining your team. This mental model immediately clarifies roles and expectations. You wouldn't let a junior architect your system or write all your tests—so why let AI? Instead, apply existing onboarding practices: pair programming, code reviews, test-driven development, architectural guidance. This approach leverages Extreme Programming practices that have worked for decades. The junior engineer analogy helps teams understand that AI needs mentorship, clear requirements, and frequent validation. Just as you'd provide a junior with frameworks and conventions to follow, you constrain AI with established architectural patterns and framework conventions like Ruby on Rails. The Transactional Model: Atomic Commits and Rollback "When you're working with AI, the more atomic commits it delivers, more easy for you to kind of guide and navigate it through the process of development."   Sergey's transactional approach transforms how developers work with AI. Instead of iterating endlessly when something goes wrong, commit frequently with atomic changes, then rollback and restart if validation fails. Each commit should be small, independent, and complete—like a feature flag you can toggle. The commit message includes the prompt sequence used to generate the code and rollback instructions.  This approach makes the Git repository the context manager, not just the AI's memory. When you need to guide AI, you can reference specific commits and their context. This mirrors trunk-based development practices where teams commit directly to master with small, verified changes. The cost of rollback stays minimal because changes are atomic, making this strategy far more efficient than trying to fix broken implementations through iteration. Context Management: The Weak Point and the Solution "Managing context and keeping context is one of the weak points of today's coding agents, therefore we need to be very mindful in how we manage that context for the agent."   Context management challenges current AI coding tools—they forget, lose thread, or misinterpret requirements over long sessions. Sergey's solution is embedding context within the commit history itself. Each commit links back to the specific reasoning behind that code: why it was accepted, what iterations it took, and how to undo it if needed. This creates a persistent context trail that survives beyond individual AI sessions. When starting new features, developers can reference previous commits and their context to guide the AI. The transactional model doesn't just provide rollback capability—it creates institutional memory that makes AI progressively more effective as the codebase grows. TDD 2.0: Humans Write Tests, AI Writes Code "I would never allow AI to write the test. I would do it by myself. Still, it can write the code."   Sergey is adamant about roles: humans write tests, AI writes implementation code. This inverts traditional TDD slightly—instead of developers writing tests then code, they write tests and AI writes the code to pass them. Tests become executable requirements and prompts. This provides essential guardrails: AI can iterate on implementation until tests pass, but it can't redefine what "passing" means. The tests represent domain knowledge, business requirements, and validation criteria that only humans should control. Sergey envisions multi-agent systems where one agent writes code while another validates with tests, but critically, humans author the original test suite. This TDD 2.0 framework (a talk Sergey gave at the Global Agile Summit) creates a verification mechanism that prevents the biggest anti-pattern: coding without proper validation. The Two Cardinal Rules: Architecture and Verification "I would never allow AI to invent architecture. Writing AI agentic coding, Vibecoding, whatever coding—without proper verification and properly setting expectations of what you want to get as a result—that's the main mistake."   Sergey identifies two non-negotiables. First, never let AI invent architecture. Use framework conventions (Rails, etc.) to constrain AI's choices. Leverage existing code generators and scaffolding. Provide explicit architectural guidelines in planning steps. Store iteration-specific instructions where AI can reference them. The framework becomes the guardrails that prevent AI from making structural decisions it's not equipped to make. Second, always verify AI output. Even if you don't want to look at code, you must validate that it meets requirements. This might be through tests, manual review, or automated checks—but skipping verification is the fundamental mistake. These two rules—human-defined architecture and mandatory verification—separate successful AI-assisted development from technical debt generation. Prototype vs. Production: Two Different Workflows "When you pair as an architect or a really senior engineer who can implement it by himself, but just wants to save time, you do the pair programming with AI, and the AI kind of ships a draft, and rapid prototype."   Sergey distinguishes clearly between prototype and production development. For MVPs and rapid prototypes, a senior architect pairs with AI to create drafts quickly—this is where speed matters most. For production code, teams add more iterative testing and polishing after AI generates initial implementation. The key is being explicit about which mode you're in. The biggest anti-pattern is treating prototype code as production-ready without the necessary validation and hardening steps. When building production systems, Sergey applies the full transactional model: atomic commits, comprehensive tests, architectural constraints, and rollback strategies. For prototypes, speed takes priority, but the architectural knowledge still comes from humans, not AI. The Future: AI Literacy as Mandatory "Being a software engineer and trying to get a new job, it's gonna be a mandatory requirement for you to understand how to use AI for coding. So it's not enough to just be a good engineer."   Sergey sees AI-assisted coding literacy becoming as fundamental as Git proficiency. Future engineering jobs will require demonstrating effective AI collaboration, not just traditional coding skills. We're reaching good performance levels with AI models—now the challenge is learning to use them efficiently. This means frameworks and standardized patterns for AI-assisted development will emerge and consolidate. Approaches like AAID, SpecKit, and others represent early attempts to create these patterns. Sergey expects architectural patterns for AI-assisted development to standardize, similar to how design patterns emerged in object-oriented programming. The human remains the bottleneck—for domain knowledge, business requirements, and architectural guidance—but the implementation mechanics shift heavily toward AI collaboration. Resources for Practitioners "We are reaching a good performance level of AI models, and now we need to guide it to make it impactful. It's a great tool, now we need to understand how to make it impactful."   Sergey recommends Obie Fernandez's work on "Patterns of Application Development Using AI," particularly valuable for Ruby and Rails developers but applicable broadly. He references Andrey Karpathy's original vibecoding post and emphasizes Extreme Programming practices as foundational. The tools he uses—Cursor and Claude Code—support custom planning steps and context management. But more important than tools is the mindset: we have powerful AI capabilities now, and the focus must shift to efficient usage patterns. This means experimenting with workflows, documenting what works, and sharing patterns with the community. Sergey himself shares case studies on LinkedIn and travels extensively speaking about these approaches, contributing to the collective learning happening in real-time.   About Sergey Sergyenko   Sergey is the CEO of Cybergizer, a dynamic software development agency with offices in Vilnius, Lithuania. Specializing in MVPs with zero cash requirements, Cybergizer offers top-tier CTO services and startup teams. Their tech stack includes Ruby, Rails, Elixir, and ReactJS.   Sergey was also a featured speaker at the Global Agile Summit, and you can find his talk available in your membership area. If you are not a member don't worry, you can get the 1-month trial and watch the whole conference. You can cancel at any time.   You can link with Sergey Sergyenko on LinkedIn.

BONUS: Augmented AI Development - Software Engineering First, AI Second In this special episode, Dawid Dahl introduces Augmented AI Development (AAID)—a disciplined approach where professional developers augment their capabilities with AI while maintaining full architectural control. He explains why starting with software engineering fundamentals and adding AI where appropriate is the opposite of most frameworks, and why this approach produces production-grade software rather than technical debt. The AAID Philosophy: Don't Abandon Your Brain "Two of the fundamental developer principles for AAID are: first, don't abandon your brain. And the second is incremental steps."   Dawid's Augmented AI Development framework stands in stark contrast to "vibecoding"—which he defines strictly as not caring about code at all, only results on screen. AAID is explicitly designed for professional developers who maintain full understanding and control of their systems. The framework is positioned on the furthest end of the spectrum from vibe coding, requiring developers to know their craft deeply. The two core principles—don't abandon your brain, work incrementally—reflect a philosophy that AI is a powerful collaborator, not a replacement for thinking. This approach recognizes that while 96% of Dawid's code is now written by AI, he remains the architect, constantly steering and verifying every step. In this segment we refer to Marcus Hammarberg's work and his book The Bungsu Story. Software Engineering First, AI Second: A Hill to Die On "You should start with software engineering wisdom, and then only add AI where it's actually appropriate. I think this is super, super important, and the entire foundation of this framework. This is a hill I will personally die on."   What makes AAID fundamentally different from other AI-assisted development frameworks is its starting point. Most frameworks start with AI capabilities and try to add structure and best practices afterward. Dawid argues this is completely backwards. AAID begins with 50-60 years of proven software engineering wisdom—test-driven development, behavior-driven development, continuous delivery—and only then adds AI where it enhances the process. This isn't a minor philosophical difference; it's the foundation of producing maintainable, production-grade software. Dawid admits he's sometimes "manipulating developers to start using good, normal software engineering practices, but in this shiny AI box that feels very exciting and new." If the AI wrapper helps developers finally adopt TDD and BDD, he's fine with that. Why TDD is Non-Negotiable with AI "Every time I prompt an AI and it writes code for me, there is often at least one or two or three mistakes that will cause catastrophic mistakes down the line and make the software impossible to change."   Test-driven development isn't just a nice-to-have in AAID—it's essential. Dawid has observed that AI consistently makes 2-3 mistakes per prompt that could have catastrophic consequences later. Without TDD's red-green-refactor cycle, these errors accumulate, making code increasingly difficult to change. TDD answers the question "Is my code technically correct?" while acceptance tests answer "Is the system releasable?" Both are needed for production-grade software. The refactor step is where 50-60 years of software engineering wisdom gets applied to make code maintainable. This matters because AAID isn't vibe coding—developers care deeply about code quality, not just visible results. Good software, as Dave Farley says, is software that's easy to change. Without TDD, AI-generated code becomes a maintenance nightmare. The Problem with "Prompt and Pray" Autonomous Agents "When I hear 'our AI can now code for over 30 hours straight without stopping,' I get very afraid. You fall asleep, and the next morning, the code is done. Maybe the tests are green. But what has it done in there? Imagine everything it does for 30 hours. This system will not work."   Dawid sees two diverging paths for AI-assisted development's future. The first—autonomous agents working for hours or days without supervision—terrifies him. The marketing pitch sounds appealing: prompt the AI, go to sleep, wake up to completed features. But the reality is technical debt accumulation at scale. Imagine all the decisions, all the architectural choices, all the mistakes an AI makes over 30 hours of autonomous work. Dawid advocates for the stark contrast: working in extremely small increments with constant human steering, always aligned to specifications. His vision of the future isn't AI working alone—it's voice-controlled confirmations where he says "Yes, yes, no, yes" as AI proposes each tiny change. This aligns with DORA metrics showing that high-performing teams work in small batches with fast feedback loops. Prerequisites: Product Discovery Must Come First "Without Dave Farley, this framework would be totally different. I think he does everything right, basically. With this framework, I want to stand on the shoulders of giants and work on top of what has already been done."   AAID explicitly requires product discovery and specification phases before AI-assisted coding begins. This is based on Dave Farley's product journey model, which shows how products move from idea to production. AAID starts at the "executable specifications" stage—it requires input specifications from prior discovery work. This separates specification creation (which Dawid is addressing in a separate "Dream Encoder" framework) from code execution. The prerequisite isn't arbitrary; it acknowledges that AI-assisted implementation works best when the problem is well-defined. This "standing on shoulders of giants" approach means AAID doesn't try to reinvent software engineering—it leverages decades of proven practices from TDD pioneers, BDD creators, and continuous delivery experts. What's Wrong with Other AI Frameworks "When the AI decides to check the box [in task lists], that means this is the definition of done. But how is the AI taking that decision? It's totally ad hoc. It's like going back to the 1980s: 'I wrote the code, I'm done.' But what does that mean? Nobody has any idea."   Dawid is critical of current AI frameworks like SpecKit, pointing out fundamental flaws. They start with AI first and try to add structure later (backwards approach). They use task lists with checkboxes where AI decides when something is "done"—but without clear criteria, this becomes ad hoc decision-making reminiscent of 1980s development practices. These frameworks "vibecode the specs," not realizing there's a structured taxonomy to specifications that BDD already solved. Most concerning, some have removed testing as a "feature," treating it as optional. Dawid sees these frameworks as over-engineered, process-centric rather than developer-centric, often created by people who may not develop software themselves. AAID, in contrast, is built by a practicing developer solving real problems daily. Getting Started: Learn Fundamentals First "The first thing developers should do is learn the fundamentals. They should skip AI altogether and learn about BDD and TDD, just best practices. But when you know that, then you can look into a framework, maybe like mine."   Dawid's advice for developers interested in AI-assisted coding might seem counterintuitive: start by learning fundamentals without AI. Master behavior-driven development, test-driven development, and software engineering best practices first. Only after understanding these foundations should developers explore frameworks like AAID. This isn't gatekeeping—it's recognizing that AI amplifies whatever approach developers bring. If they start with poor practices, AI will help them build unmaintainable systems faster. But if they start with solid fundamentals, AI becomes a powerful multiplier that lets them work at unprecedented speed while maintaining quality. AAID offers both a dense technical article on dev.to and a gentler game-like onboarding in the GitHub repo, meeting developers wherever they are in their journey.   About Dawid Dahl   Dawid is the creator of Augmented AI Development (AAID), a disciplined approach where developers augment their capabilities by integrating with AI, while maintaining full architectural control. Dawid is a software engineer at Umain, a product development agency.   You can link with Dawid Dahl on LinkedIn and find the AAID framework on GitHub.

AI Assisted Coding: Swimming in AI - Managing Tech Debt in the Age of AI-Assisted Coding In this special episode, Lou Franco, veteran software engineer and author of "Swimming in Tech Debt," shares his practical approach to AI-assisted coding that produces the same amount of tech debt as traditional development—by reading every line of code. He explains the critical difference between vibecoding and AI-assisted coding, why commit-by-commit thinking matters, and how to reinvest productivity gains into code quality. Vibecoding vs. AI-Assisted Coding: Reading Code Matters "I read all the code that it outputs, so I need smaller steps of changes."   Lou draws a clear distinction between vibecoding and his approach to AI-assisted coding. Vibecoding, in his definition, means not reading the code at all—just prompting, checking outputs, and prompting again. His method is fundamentally different: he reads every line of generated code before committing it. This isn't just about catching bugs; it's about maintaining architectural control and accountability. As Lou emphasizes, "A computer can't be held accountable, so a computer can never make decisions. A human always has to make decisions." This philosophy shapes his entire workflow—AI generates code quickly, but humans make the final call on what enters the repository. The distinction matters because it determines whether you're managing tech debt proactively or discovering it later when changes become difficult. The Moment of Shift: Staying in the Zone "It kept me in the zone. It saved so much time! Never having to look up what a function's arguments were... it just saved so much time."   Lou's AI coding journey began in late 2022 with GitHub Copilot's free trial. He bought a subscription immediately after the trial ended because of one transformative benefit: staying in the flow state. The autocomplete functionality eliminated constant context switching to documentation, Stack Overflow searches, and function signature lookups. This wasn't about replacing thinking—it was about removing friction from implementation. Lou could maintain focus on the problem he was solving rather than getting derailed by syntax details. This experience shaped his understanding that AI's value lies in removing obstacles to productivity, not in replacing the developer's judgment about architecture and design. Thinking in Commits: The Right Size for AI Work "I think of prompts commit-by-commit. That's the size of the work I'm trying to do in a prompt."   Lou's workflow centers on a simple principle: size your prompts to match what should be a single commit. This constraint provides multiple benefits. First, it keeps changes small enough to review thoroughly—if a commit is too big to review properly, the prompt was too ambitious. Second, it creates a clear commit history that tells a story about how the code evolved. Third, it enables easy rollback if something goes wrong. This commit-sized thinking mirrors good development practices that existed long before AI—small, focused changes that each accomplish one clear purpose. Lou uses inline prompting in Cursor (Command-K) for these localized changes because it keeps context tight: "Right here, don't go look at the rest of my files... Everything you need is right here. The context is right here... And it's fast." The Tech Debt Question: Same Code, Same Debt "Based on the way I've defined how I did it, it's exactly the same amount of tech debt that I would have done on my own... I'm faster and can make more code, but I invest some of that savings back into cleaning things up."   As the author of "Swimming in Tech Debt," Lou brings unique perspective to whether AI coding creates more technical debt. His answer: not if you're reading and reviewing everything. When you maintain the same quality standards—code review, architectural oversight, refactoring—you generate the same amount of debt as manual coding. The difference is speed. Lou gets productivity gains from AI, and he consciously reinvests a portion of those gains back into code quality through refactoring. This creates a virtuous cycle: faster development enables more time for cleanup, which maintains a codebase that's easier for both humans and AI to work with. The key insight is that tech debt isn't caused by AI—it's caused by skipping quality practices regardless of how code is generated. When Vibecoding Creates Debt: AI Resistance as a Symptom "When you start asking the AI to do things, and it can't do them, or it undoes other things while it's doing them... you're experiencing the tech debt a different way. You're trying to make changes that are on your roadmap, and you're getting resistance from making those changes."   Lou identifies a fascinating pattern: tech debt from vibecoding (without code review) manifests as "AI resistance"—difficulty getting AI to make the changes you want. Instead of compile errors or brittle tests signaling problems, you experience AI struggling to understand your codebase, undoing changes while making new ones, or producing code with repetition and tight coupling. These are classic tech debt symptoms, just detected differently. The debt accumulates through architecture violations, lack of separation of concerns, and code that's hard to modify. Lou's point is profound: whether you notice debt through test failures or through AI confusion, the underlying problem is the same—code that's difficult to change. The solution remains consistent: maintain quality practices including code review, even when AI makes generation fast. Can AI Fix Tech Debt? Yes, With Guidance "You should have some acceptance criteria on the code... guide the LLM as to the level of code quality you want."   Lou is optimistic but realistic about AI's ability to address existing tech debt. AI can definitely help with refactoring and adding tests—but only with human guidance on quality standards. You must specify what "good code" looks like: acceptance criteria, architectural patterns, quality thresholds. Sometimes copy/paste is faster than having AI regenerate code. Very convoluted codebases challenge both humans and AI, so some remediation should happen before bringing AI into the picture. The key is recognizing that AI amplifies your approach—if you have strong quality standards and communicate them clearly, AI accelerates improvement. If you lack quality standards, AI will generate code just as problematic as what already exists. Reinvesting Productivity Gains in Quality "I'm getting so much productivity out of it, that investing a little bit of that productivity back into refactoring is extremely good for another kind of productivity."   Lou describes a critical strategy: don't consume all productivity gains as increased feature velocity. Reinvest some acceleration back into code quality through refactoring. This mirrors the refactor step in test-driven development—after getting code working, clean it up before moving on. AI makes this more attractive because the productivity gains are substantial. If AI makes you 30% faster at implementation, using 10% of that gain on refactoring still leaves you 20% ahead while maintaining quality. Lou explicitly budgets this reinvestment, treating quality maintenance as a first-class activity rather than something that happens "when there's time." This discipline prevents the debt accumulation that makes future work progressively harder. The 100x Code Concern: Accountability Remains Human "Directionally, I think you're probably right... this thing is moving fast, we don't know. But I'm gonna always want to read it and approve it."   When discussing concerns about AI generating 100x more code (and potentially 100x more tech debt), Lou acknowledges the risk while maintaining his position: he'll always read and approve code before it enters the repository. This isn't about slowing down unnecessarily—it's about maintaining accountability. Humans must make the decisions because only humans can be held accountable for those decisions. Lou sees potential for AI to improve by training on repository evolution rather than just end-state code, learning from commit history how codebases develop. But regardless of AI improvements, the human review step remains essential. The goal isn't to eliminate human involvement; it's to shift human focus from typing to thinking, reviewing, and making architectural decisions. Practical Workflow: Inline Prompting and Small Changes "Right here, don't go look at the rest of my files... Everything you need is right here. The context is right here... And it's fast."   Lou's preferred tool is Cursor with inline prompting (Command-K), which allows him to work on specific code sections with tight context. This approach is fast because it limits what AI considers, reducing both latency and irrelevant changes. The workflow resembles pair programming: Lou knows what he wants, points AI at the specific location, AI generates the implementation, and Lou reviews before accepting. He also uses Claude Code for full codebase awareness when needed, but the inline approach dominates his daily work. The key principle is matching tool choice to context needs—use inline prompting for localized changes, full codebase tools when you need broader understanding. This thoughtful tool selection keeps development efficient while maintaining control. Resources and Community Lou recommends Steve Yegge's upcoming book on vibecoding. His website, LouFranco.com, provides additional resources.    About Lou Franco   Lou Franco is a veteran software engineer and author of Swimming in Tech Debt. With decades of experience at startups, as well as Trello, and Atlassian, he's seen both sides of debt—as coder and leader. Today, he advises teams on engineering practices, helping them turn messy codebases into momentum.   You can link with Lou Franco on LinkedIn and visit his website at LouFranco.com.

AI Assisted Coding: From Designer to Solo Developer - Building Production Apps with AI In this special episode, Elina Patjas shares her remarkable journey from designer to solo developer, building LexieLearn—an AI-powered study tool with 1,500+ users and paying customers—entirely through AI-assisted coding. She reveals the practical workflow, anti-patterns to avoid, and why the future of software might not need permanent apps at all. The Two-Week Transformation: From Idea to App Store "I did that, and I launched it to App Store, and I was like, okay, so… If I can do THIS! So, what else can I do? And this all happened within 2 weeks."   Elina's transformation happened fast. As a designer frustrated with traditional software development where maybe 10% of your original vision gets executed, she discovered Cursor and everything changed. Within two weeks, she went from her first AI-assisted experiment to launching a complete app in the App Store. The moment that shifted everything was realizing that AI had fundamentally changed the paradigm from "writing code" to "building the product." This wasn't about learning to code—it was about finally being able to execute her vision 100% the way she wanted it, with immediate feedback through testing. Building LexieLearn: Solving Real Problems for Real Users "I got this request from a girl who was studying, and she said she would really appreciate to be able to iterate the study set... and I thought: "That's a brilliant idea! And I can execute that!" And the next morning, it was 9.15, I sent her a screen capture."   Lexie emerged from Elina's frustration with ineffective study routines and gamified edtech that didn't actually help kids learn. She built an AI-powered study tool for kids aged 10-15 that turns handwritten notes into adaptive quizzes revealing knowledge gaps—private, ad-free, and subscription-based. What makes Lexie remarkable isn't just the technology, but the speed of iteration. When a user requested a feature, Elina designed and implemented it overnight, sending a screen capture by 9:15 AM the next morning. This kind of responsiveness—from customer feedback to working feature in hours—represents a fundamental shift in how software can be built. Today, Lexie has over 1,500 users with paying customers, proving that AI-assisted development isn't just for prototypes anymore. The Workflow: It's Not Just "Vibing" "I spend 30 minutes designing the whole workflow inside my head... all the UX interactions, the data flow, and the overall architectural decisions... so I spent a lot of time writing a really, really good spec. And then I gave that to Claude Code."   Elina has mixed feelings about the term "vibecoding" because it suggests carelessness. Her actual workflow is highly disciplined. She spends significant time designing the complete workflow mentally—all UX interactions, data flow, and architectural decisions—then writes detailed specifications. She often collaborates with Claude to write these specs, treating the AI as a thinking partner. Once the spec is clear, she gives it to Claude Code and enters a dialogue mode: splitting work into smaller tasks, maintaining constant checkpoints, and validating every suggestion. She reads all the code Claude generates (32,000 lines client-side, 8,000 server-side) but doesn't write code herself anymore. This isn't lazy—it's a new kind of discipline focused on design, architecture, and clear communication rather than syntax. Reading Code vs. Writing Code: A New Skill Set "AI is able to write really good code, if you just know how to read it... But I do not write any code. I haven't written a single line of code in a long time."   Elina's approach reveals an important insight: the skill shifts from writing code to reading and validating it. She treats Claude Code as a highly skilled companion that she needs to communicate with extremely well. This requires knowing "what good looks like"—her 15 years of experience as a designer gives her the judgment to evaluate what the AI produces. She maintains dialogue throughout development, using checkpoints to verify direction and clarify requirements. The fast feedback loop means when she fails to explain something clearly, she gets immediate feedback and can course-correct instantly. This is fundamentally different from traditional development where miscommunication might not surface until weeks later. The Anti-Pattern: Letting AI Run Rampant "You need to be really specific about what you want to do, and how you want to do it, and treat the AI as this highly skilled companion that you need to be able with."   The biggest mistake Elina sees is treating AI like magic—giving vague instructions and expecting it to "just figure it out." This leads to chaos. Instead, developers need to be incredibly specific about requirements and approach, treating AI as a skilled partner who needs clear communication. The advantage is that the iteration loop is so fast that when you fail to explain something properly, you get feedback immediately and can clarify. This makes the learning curve steep but short. The key is understanding that AI amplifies your skills—if you don't know what good architecture looks like, AI won't magically create it for you. Breaking the Gatekeeping: One Person, Ten Jobs "I think that I can say that I am a walking example of what you can do, if you have the proper background, and you know what good looks like. You can do several things at a time. What used to require 10 people, at least, to build before."   Elina sees herself as living proof that the gatekeeping around software development is breaking down. Someone with the right background and judgment can now do what previously required a team of ten people. She's passionate about others experiencing this same freedom—the ability to execute their vision without compromise, to respond to user feedback overnight, to build production-quality software solo. This isn't about replacing developers; it's about expanding who can build software and what's possible for small teams. For Elina, working with a traditional team would actually slow her down now—she'd spend more time explaining her vision than the team would save through parallel work. The Future: Intent-Based Software That Emerges and Disappears "The software gets built in an instance... it's going to this intent-based mode when we actually don't even need apps or software as we know them."   Elina's vision for the future is radical: software that emerges when you need it and disappears when you don't. Instead of permanent apps, you'd have intent-based systems that generate solutions in the moment. This shifts software from a product you download and learn to a service that materializes around your needs. We're not there yet, but Elina sees the trajectory clearly. The speed at which she can now build and modify Lexie—overnight feature implementations, instant bug fixes, continuous evolution—hints at a future where software becomes fluid rather than fixed. Getting Started: Just Do It "I think that the best resource is just your own frustration with some existing tools... Just open whatever tool you're using, is it Claude or ChatGPT and start interacting and discussing, getting into this mindset that you're exploring what you can do, and then just start doing."   When asked about resources, Elina's advice is refreshingly direct: don't look for tutorials, just start. Let your frustration with existing tools drive you. Open Claude or ChatGPT and start exploring, treating it as a dialogue partner. Start building something you actually need. The learning happens through doing, not through courses. Her own journey proves this—she went from experimenting with Cursor to shipping Lexie to the App Store in two weeks, not because she found the perfect tutorial, but because she just started building. The tools are good enough now that the biggest barrier isn't technical knowledge—it's having the courage to start and the judgment to evaluate what you're building.   About Elina Patjas   Elina is building Lexie, an AI-powered study tool for kids aged 10–15. Frustrated by ineffective "read for exams" routines and gamified edtech fluff, she designed Lexie to turn handwritten notes into adaptive quizzes that reveal knowledge gaps—private, ad-free, and subscription-based. Lexie is learning, simplified.   You can link with Elina Patjas on LinkedIn.

Sara Di Gregorio: Coaching Product Owners from Isolation to 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 Great Product Owner: Using User Story Mapping to Break Down PO Isolation "One of the key strengths is the ability to build a strong collaborative relationship with the Scrum team. We constantly exchange feedback, with the shared goal of improving both our collaborating and the way of working." - Sara Di Gregorio   Sara considers herself fortunate—she currently works with Product Owners who exemplify what great collaboration looks like. One of their key strengths is the ability to build strong collaborative relationships with the Scrum team. They don't wait for sprint reviews to exchange feedback; instead, they constantly communicate with the shared goal of improving both collaboration and ways of working.  These Product Owners involve the team early, using techniques like user story mapping after analysis phases to create open discussions around upcoming topics and help the team understand potential dependencies. They make themselves truly available—they observe daily stand-ups not as passive attendees but as engaged contributors. If the team needs five minutes to discuss something afterward, the Product Owner is ready. They attend Scrum events with genuine interest in working with the team, not just fulfilling an attendance requirement. They encourage open dialogue, even participating in retrospectives to understand how the team is working and where they can improve collaboration. What sets these Product Owners apart is their communication approach. They don't come in thinking they know everything or that they need to do everything alone. Their mindset is collaborative: "We're doing this together." They recognize that developers aren't just executors—they're users of the product, experts who can provide valuable perspectives.  When Product Owners ask "Why do you want this?" and developers respond with "If we do it this way, we can be faster, and you can try your product sooner," that's when magic happens. Great Product Owners understand that strong communication skills and collaborative relationships create better products, better teams, and better outcomes for everyone involved.   Self-reflection Question: How are your Product Owners involving the team early in discovery and analysis, and are they building collaborative relationships or just attending required events? The Bad Product Owner: The Isolated Expert Who Thinks Teams Just Execute   "Sometimes they feel very comfortable in their subject, so they assume they know everything, and the team has only to execute what they asked for." - Sara Di Gregorio   Sara has encountered Product Owners who embody the worst anti-pattern: they believe they don't need to interact with the development team because they're confident in their subject matter expertise. They assume they know everything, and the team's job is simply to execute what they ask for. These Product Owners work isolated from the development team, writing detailed user stories alone and skipping the interesting discussions with developers. They only involve the team when they think it's necessary, treating developers as order-takers rather than collaborators who could contribute valuable insights.  The impact is significant—teams lose the opportunity to understand the "why" behind features, Product Owners miss perspectives that could improve the product, and collaboration becomes transactional instead of transformational. Sara's approach to addressing this anti-pattern is patient but deliberate. She creates space for dialogue and provides training with the Product Owner to help them understand how important it is to collaborate and cooperate with the team. She shows them the impact of including the team from the beginning of feature study.  One powerful technique she uses is user story mapping workshops, bringing both the team and Product Owner together. The Product Owner explains what they want to deliver from their point of view, but then something crucial happens: the team asks lots of questions to understand "Why do you want this?"—not just "I will do it."  Through this exercise, Sara watched Product Owners have profound realizations. They understood they could change their mindset by talking with developers, who often are users of the product and can offer perspectives like "If we do it this way, we can be faster, and you can try your product sooner."  The workshop helps teams understand the big picture of what the Product Owner is asking for while helping the Product Owner reflect on what they're actually asking. It transforms the relationship from isolation to collaboration, from directive to dialogue, from assumption to shared understanding.   In this segment, we refer to the User Story Mapping blog post by Jeff Patton.   Self-reflection Question: Are your Product Owners writing user stories in isolation, or are they involving the team in discovery to create shared understanding and better solutions?   [The Scrum Master Toolbox Podcast Recommends]

Sara Di Gregorio: How to Know Your Team Has Internalized Agile Values 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.   "Scrum isn't just a process to follow, it's a way of working." - Sara Di Gregorio   For Sara, success as a Scrum Master isn't measured by what the team delivers—it's measured by how they grow. She knows that if you facilitate team growth in communication and collaboration, delivery will naturally improve.  The indicators she watches for are subtle but powerful. When teams come to her with specific requests outside the regular schedule—"Can we have 30 minutes to talk and reflect mid-sprint?"—she knows something has shifted. When teams want to reflect outside the retrospective cycle, it means they've internalized the value of continuous improvement, not just going through the motions. She listens for the word "goal" during sprint planning.  When team members start their planning by talking about goals, she feels a surge of recognition: "Okay, for me, this is very, very, very important." Success shows up in unexpected places. One of her colleague's teams pushed back during a cross-team meeting, saying "We're going out of the timebox" and suggesting they move the discussion to a different time. That kind of proactive leadership and accountability signals maturity. It means the team isn't just attending Scrum events because they have to—they truly understand why each event matters and actively participate to make them valuable.  When Sara first met a team, they asked if she wanted to change things. She said no. What she focuses on is how people improve and understand the process better. For her, it starts with the people—when people change and understand the value, that's when real changes happen in the company. It's about helping people feel good and be guided well, because when they're working well, that's when transformation becomes possible. As Sara reminds us, Scrum isn't just a process to follow—it's a way of working that teams must embrace, understand, and make their own.   Self-reflection Question: Are your teams coming to you asking for reflection time outside scheduled events, and what does that tell you about how deeply they've internalized continuous improvement? Featured Retrospective Format for the Week: Unstructured Retrospective After facilitating many structured retrospectives, Sara started experimenting with an unstructured format that brought new energy to team reflection. Instead of using predefined frameworks, she brings white paper, sticky notes, and sharpies of different colors. She opens with a simple question: "Guys, what impacted you mostly during the last week? How do you feel today?" Sometimes she starts with data and metrics; other times, she begins with how the team is feeling.  The key is creating open space for conversation rather than forcing it into a predetermined structure. What Sara discovered is remarkable: "They are more engaged, more open, and more present in the conversation, maybe because it was something new." Instead of the same structured format every time, the unstructured approach breaks the routine and creates space for true reflections that bring out something deeper and more meaningful. It allows people to express what's genuinely going on for them, not just what fits into a predefined template.  Sara doesn't abandon structured formats entirely—she alternates between structured and unstructured to keep retrospectives fresh and engaging. She also recommends, if you work hybrid, trying to schedule unstructured retrospectives for days when the team is in the office together. The physical presence combined with the open format creates an environment where teams can be more vulnerable, more creative, and more honest about what's really happening. The unstructured retrospective isn't about chaos—it's about trusting the team to surface what matters most to them, with the Scrum Master providing light facilitation and space for authentic reflection.   [The Scrum Master Toolbox Podcast Recommends]

Sara Di Gregorio: Facilitating Deeper Retrospectives—When to Step In and When to Step Back 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 they start connecting and having an interesting discussion, I go to the corner, and I'm only trying to listen." - Sara Di Gregorio   Sara faces a challenge that many Scrum Masters encounter: teams that want to discuss too many topics during retrospectives without going deep on any of them. The team had plenty to talk about, but conversations stayed surface-level, never reaching the insights that drive real improvement. Sara recognized that the aim of the retrospective isn't to talk about everything—it's to go deeper on topics the team genuinely cares about.  So she started coaching teams to select just three main topics they wanted to discuss, helping them understand why prioritization matters and making explicit which topics are most important. But her real skill emerged in how she facilitated the discussions. When she saw communication starting to flow and team members becoming deeply connected to the topic, she moved to the corner and listened. She didn't abandon the team—she remained present, ready to help shy or quiet members speak up, watching the clock to respect timeboxes.  But she understood that when teams connect authentically, the Scrum Master's job is to create space, not fill it. Sara learned to ask better questions too. Instead of repeatedly asking "Why? Why? Why?"—which can feel accusatory—she reformulated: "How did you approach it? What happens?" When teams started blaming other teams, she redirected: "What can we influence? What can we do from our side?" She used visual tools like white paper, sharpies, and sticky notes to help teams visualize their discussion steps and create structured moments for questions.  Sometimes, when teams discussed complex technical topics beyond her understanding, she empowered them: "You are the main expert of this topic. Please, when someone sees that we're going out of topic or getting too detailed, raise your hand and help me bring the communication back to what we've chosen to talk about."  This balance—knowing when to step in with structure and when to step back and listen—is what transforms retrospectives from checkbox events into genuine opportunities for team growth.   Self-reflection Question: In your facilitation, are you creating space for deep team connection, or are you inadvertently filling the space that teams need to discover insights for themselves?   [The Scrum Master Toolbox Podcast Recommends]

Sara Di Gregorio: Rebuilding Agile Team Connection in the Remote Work Era 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 book helped me to shift from reacting to connecting, which completely changed the quality of conversation." - Sara Di Gregorio   When COVID forced Sara's team into full remote work, she noticed something troubling—the team was losing real connection. Replicating in-office meetings online simply didn't work. People attended meetings but weren't truly present. The spontaneous coffee machine conversations that built relationships and surfaced important information had vanished.  So Sara started experimenting. She introduced 5-minute chit-chat sessions at the start of every meeting: "Guys, how are you today? What happened yesterday?" She created "coffee all together" moments—10-minute virtual breaks where the team could drink coffee or have aperitivos together, sometimes three times per week. She established weekly feedback sessions every Friday morning—30 minutes to recap the week and understand what could improve.  These weren't just social niceties; they were deliberate efforts to recreate the human connections that remote work had stripped away. Sara recognized that mechanized interactions—"here are the things I need you to do, let's talk next steps"—kill team dynamics. Teams need moments where they relate to each other as people, not just as functions.  The experiments worked because they created space for genuine connection, allowing the team to maintain the trust and collaboration that makes effective teamwork possible, even when working remotely.   In this episode, we refer to Non-Violent Communication concepts and practices.   Self-reflection Question: How are you creating moments for your remote or hybrid team to connect as people, not just as colleagues executing tasks? Featured Book of the Week: Nonviolent Communication by Marshall Rosenberg Sara credits Nonviolent Communication by Marshall Rosenberg (translated in Italian as "Words are Windows, or They are Walls") as having a deep impact on her career. The book explores how to listen without judging, how to ask the right questions, and how to observe people to understand their real needs. But above all, it teaches how to communicate in a way that builds connection rather than creating barriers.  For Sara, the book was remarkably practical—she didn't just read it, she experimented with the techniques afterward. She explains: "I think that without this mindset, it's easy to fall into reactive communication, trying to defend, justify, or give quick answers. But that often blocks real understanding." The book helped her shift from reacting to connecting, which completely changed the quality of her conversations.  As a Scrum Master working with people every day—facilitating meetings, mediating conflicts, supporting teams—the way we communicate determines whether we open dialogue or close it. Sara found that taking time to reflect instead of giving quick answers transformed her ability to help teams discover dependencies, improve dialogue, and address communication issues. For anyone in the Scrum Master role, this book provides essential skills for building the kind of connection that makes true collaboration possible. In this segment, we also refer to the NVC episodes we have on the podcast. Check those out to learn more about Nonviolent Communication   [The Scrum Master Toolbox Podcast Recommends]

Sara Di Gregorio: When Teams Lose Trust—How Scrum Masters Rebuild It One Small Change at a Time 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 continue to approach this situation with openness, positivity, and trust, because I truly believe that even the smallest changes can make a difference over time." - Sara Di Gregorio   Sara faced one of the most challenging situations a Scrum Master can encounter—a team member who had lost all trust in change, creating a negative atmosphere that weighed heavily on the entire team. She remembers the heaviness on her shoulders, feeling personally responsible for the team's wellbeing. The negativity was palpable during every meeting, and it threatened to undermine the team's progress.  But Sara refused to give up. She started experimenting with different approaches: one-to-one conversations to understand what was happening, bringing intentional energy to meetings, and trying new facilitation techniques in retrospectives. She added personal check-ins, asking "How are you today?" at the start of stand-ups, consciously bringing positive energy even on days when she didn't feel it herself.  She discovered that listening—truly listening, not just hearing—means understanding how people feel, not just what they're saying. Sara learned that the energy you bring to interactions matters deeply. Starting the day with genuine interest, asking about the team's wellbeing, and even making small comments about the weather could create tiny shifts—a small smile that signaled something had changed.  Her approach was rooted in persistence and belief: she continued approaching the situation with openness, positivity, and trust, knowing that even the smallest changes can make a difference over time. For Sara, reestablishing a good environment wasn't about quick fixes—it was about showing up every day with the right energy and never giving up on her team.   Self-reflection Question: What energy are you bringing to your interactions with the team today, and how might that be shaping the team's atmosphere?   [The Scrum Master Toolbox Podcast Recommends]

BONUS: Flawless Execution — Translating Fighter Pilot Precision to Business Results In this powerful conversation, former fighter pilot Christian "Boo" Boucousis reveals how military precision translates into agile business leadership. We explore the FLEX model (Plan-Brief-Execute-Debrief), the critical difference between control-based and awareness-based leadership, and why most organizations fail to truly embrace iterative thinking. From Cockpit to Boardroom: An Unexpected Journey "I learned over time that it doesn't matter what you do if you're always curious, and you're always intentional, and you're always asking questions." — Christian "Boo" Boucousis   Christian's path from fighter pilot to leadership consultant wasn't planned—it was driven by necessity and curiosity. After 11 years as a fighter pilot (7 in Australia, 4 in the UK), an autoimmune condition ended his flying career at age 30. Rather than accepting a comfy job flying politicians around, he chose entrepreneurship. He moved to Afghanistan with a friend and built a reconstruction company that grew to a quarter billion dollars in four years. The secret? The debrief skills he learned as a fighter pilot. By constantly asking "What are you trying to achieve? How's it going? Why is there a gap?" he approached business with an agile mindset before he even knew what agile was. This curiosity-driven, question-focused approach became the foundation for everything that followed. The FLEX Model: Plan-Brief-Execute-Debrief "Agile and scrum were co-created by John Sutherland, who was a fighter pilot, and its origins sit in the OODA loop and iteration. Which is why it's a circle." — Christian "Boo" Boucousis   The FLEX model isn't new—fighter pilots have used this Plan-Brief-Execute-Debrief cycle for 60 years. It's the ultimate simple agile model, designed to help teams accelerate toward goals using the same accelerated learning curve the Air Force uses to train fighter pilots. The key insight: everything in this model is iterative, not linear. Every mission has a start, middle, and end, and every stage involves constant adaptation. Afterburner (the company Christian now leads as CEO) has worked with nearly 3,800 companies and 2.8 million people over 30 years, teaching this model. What's fascinating is that the DNA of agile is baked into fighter pilot thinking—John Sutherland, co-creator of Scrum, wrote the foreword for Christian's book "The Afterburner Advantage" because they share the same roots in the OODA loop and iterative thinking. Why Iterative Thinking Doesn't Come Naturally "Iterative thinking is not a natural human model. Most of the time we learn from mistakes. We don't learn as a habit." — Christian "Boo" Boucousis   Here's the hard truth: agile as a way of working is very different from the way human beings naturally think. Business leadership models still hark back to Frederick Winslow Taylor's 1911 book on scientific management—industrial era leadership designed for building buildings, not creating software. Time is always linear (foundation, then structure, then finishing), and this shapes how we think about planning. Humans also tend to organize like villages with chiefs, warriors, and gatherers—hierarchical and political. Fighter pilots created a parallel system where politics exist outside missions, but during execution, personality clashes can't interfere. The challenge for business isn't the method—it's getting human minds to embrace iteration as a habit, not just a process they follow when forced. Planning: Building Collective Consciousness, Not Task Lists "Planning isn't all about sequencing actions—that's not planning. That's the byproduct of planning, which is collectively agreeing what good looks like at the end." — Christian "Boo" Boucousis   Most people plan in their head or in front of a spreadsheet by themselves. That's not planning—that's collecting thoughts. Real planning means bringing everyone on the team together to build collective consciousness about what's possible. The plan is always "the best idea based on what we know now." Once airborne, everything changes because the enemy doesn't cooperate with your plan. Planning is about the destination, not the work to get there. Think about airline pilots: they don't tell you about traffic delays on their commute or maintenance issues. They say "Welcome aboard, our destination is Amsterdam, there's weather on the way, we'll land 5 minutes early." That's a brief—just the effect on you based on all their work. Most business meetings waste 55 minutes on backstory and 5 minutes deciding to have another meeting. Fighter pilots focus entirely on: What are we trying to achieve? What might get in the way? Let's go. Briefing: The 25-Minute Focus Window "You need 25 minutes of focus before your brain really focuses on the task. You program your brain for the mission at hand." — Christian "Boo" Boucousis   The brief is the moment between planning and execution when the plan is as accurate as it'll ever get. It's called "brief" for a reason—it's really short. The team checks that everyone understands the plan in today's context, accounting for last-minute changes (broken equipment, weather, personnel changes). Then comes the critical part: creating the mission bubble. From the brief until mission end, there are no distractions, no notifications. If someone tries to interrupt a fighter pilot walking to the jet, the response is clear: "I'm in my mission bubble. No distractions." This isn't optional—research shows it takes 25 minutes of uninterrupted focus before your brain truly locks onto a task. Yet most business leaders expect constant availability, with notifications pinging every few minutes. If you need everyone to have notifications on to run your business, you're doing a really bad job at planning. Execution: Awareness-Based Leadership vs. Control-Based Leadership "The reason we have so many meetings is because the leader is trying to control the situation and own all the awareness. It's not humanly possible to do that." — Christian "Boo" Boucousis   During execution, fighter pilots fly the plan until it doesn't work anymore—then they adapt. A mission commander might lead 70 airplanes, but can't possibly track all 69 others. Instead, they create "gates"—checkpoints where everyone confirms they're in the right place within 10 seconds. They plan for chaos, creating awareness points where the team is generally on track or not. The key shift: from control-based leadership (the leader tries to control everything) to awareness-based leadership (the leader facilitates and listens for divergences). This includes "subordinated leadership"—any of the four pilots in a formation can take the lead if they have better awareness. If a wingman calls out a threat the leader doesn't see, the immediate response is "Press! You take the lead." This works because they planned for it and have criteria. Business teams profess to want this kind of agile collaboration, but struggle because they haven't invested in the planning and shared understanding that makes fluid leadership transitions possible. Abort Criteria: Knowing When to Stop "We have this concept called abort criteria. If certain criteria are hit, we abort the mission. I think that's a massive opportunity for business." — Christian "Boo" Boucousis   There are degrees of things going wrong: a little bit, a medium amount, and everything going wrong. When everything's going wrong, fighter pilots stop and turn around—they don't keep pressing a bad situation. This "abort criteria" concept is massively underutilized in business. Too often, teams press bad situations, transparency disappears, people stop talking, and everyone goes into survival mode (protect myself, blame others). This never happens with fighter pilots. If something goes wrong, they take accountability and make the best decision. The most potent team size is four people: a leader, deputy leader, and two wingmen. This small team size with clear roles and shared abort criteria creates psychological safety to call out problems and adapt quickly. The Retrospective Mindset: Not Just a Ritual "A retrospective isn't a ritual. It's actually a way of thinking. It's a cognitive model. If you approached everything as a retrospective—what are we trying to achieve? How's it going? Why is it not going where we want? What's the one action to get back on track?" — Christian "Boo" Boucousis   The debrief—the retrospective—is the most important part of fighter pilot culture translated into agile. It's not just a meeting you have at the end of a sprint. It's a mindset you apply to everything: projects, relationships, personal development. Christian introduces "Flawless Leadership" built on three M's: Method (agile practices), Mindset (growth mindset developed through acting iteratively), and Moments (understanding when to show up as a people leader vs. an impact leader). The biggest mistake in technology: teams do retrospectives internally but don't include the business. They get a brief from the business, build for two months, come back, and the business says "What is this? This isn't what I expected." If they'd had the business in every scrum, every iteration, trust would build naturally. Everyone involved in the mission must be part of the planning, briefing, executing, and debriefing. Leading in the Moment: Three Layers of Leadership "Your job as a scrum master, as a leader—it doesn't matter if you're leading a division of people—is to be aware. And you're only going to be aware by listening." — Christian "Boo" Boucousis   Christian breaks leadership into three layers: People Leadership (political, emotional, dealing with personalities and overwhelm), Impact Leadership (the agile layer, results-driven, scientific), and Leading Now (the reactive, amygdala-driven panic response when things go wrong). The mistake: mixing these layers. Don't try to be a people leader during execution—that's not the time. But if you're really good at impact leadership (planning, breaking epics into stories, getting work done), you become high trust and high credibility. People leadership becomes easier because success eliminates excuses. During execution, watch for individual traits and blind spots. Use one-on-ones with a retrospective mindset: "What does good look like for you? How do we get to where you're not frustrated?" When leaders aren't present—checking phones and watches during meetings—they lose people. Your job as a leader is to turn your ears on, facilitate (not direct), and listen for divergences others don't see. The Technology-Business Disconnect "Every time you're having a scrum, every time you're coming together to talk about the product, just have the business there with you. It's easy." — Christian "Boo" Boucousis   One of the biggest packages of work Afterburner does: technology teams ask them to help build trust with the business. The solution is shockingly simple—include the business in every scrum, every planning session, every retrospective. Agile is a tech-driven approach, creating a disconnect. Technology brings overwhelming information about how hard they're working and problems they've solved, but business doesn't care about the past. They care about the future: what are you delivering and when? During the Gulf War, the military scaled this fighter pilot model to large-scale planning. Fighter pilots work with marines, special forces, navy, CIA agents—everyone is part of the plan. If one person is missing from planning, execution falls apart. If someone on the ground doesn't know how an F-18 works, the jet is just expensive decoration. Planning is about learning what everyone else does and how to support them best—not announcing what you'll do and how you'll do it. High-Definition Destinations: Beyond Goals "Planning is all about the destination, not the work to get there. Think about when you hop on an airplane—the pilot doesn't tell you the whole backstory. They say 'Welcome aboard, our destination is Amsterdam, there's weather on the way, we'll land 5 minutes early.' All you want is the effect on you." — Christian "Boo" Boucousis   Christian uses the term "High-Definition Destinations" rather than goals. The difference is clarity and vividness. When you board a plane, you don't get the pilot's commute story or maintenance details—you get the destination, obstacles, and estimated arrival. That's communication focused on effect, not process. Most business communication does the opposite: overwhelming context, backstory, and detail, with the destination buried somewhere in the middle. The brief should always be: Here's where we're going. Here's what might get in the way. Let's go. This communication style—focused on outcomes and effects rather than processes and problems—transforms how teams align and execute. It eliminates the noise and centers everyone on what actually matters: the destination.   About Christian "Boo" Boucousis   Christian "Boo" Boucousis is a former fighter pilot who now helps leaders navigate today's fast-moving world. As CEO of Afterburner and author of The Afterburner Advantage, he shares practical, people-centered tools for turning chaos into clarity, building trust, and delivering results without burning out.   You can link with Christian "Boo" Boucousis on LinkedIn, visit Afterburner.com, check out his personal site at CallMeBoo.com, or interact with his AI tool at AIBoo.com.  

Alidad Hamidi: When Product Owners Facilitate Vision Instead of Owning It Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Co-Creating Vision Through Discovery "The best product owner I worked with was not a product owner, but a project manager. And she didn't realize that she's acting as a product owner." - Alidad Hamidi   The irony wasn't lost on Alidad. The best Product Owner he ever worked with didn't have "Product Owner" in her title—she was a project manager who didn't even realize she was acting in that capacity. The team was working on a strategic project worth millions, but confusion reigned about what value they were creating. Alidad planned an inception workshop to create alignment among stakeholders, marketing, operations, advisors, and the team.   Twenty minutes into the session, Alidad asked a simple question: "How do we know the customer has this problem, and they're gonna pay for it?" Silence. No one knew. To her immense credit, the project manager didn't retreat or deflect. Instead, she jumped in: "What do we need to do?" Alidad suggested assumptions mapping, and two days later, the entire team and stakeholders gathered for the workshop. What happened next was magic. "She didn't become a proxy," Alidad emphasizes. She didn't say, "I'll go find out and come back to you." Instead, she brought everyone together—team, stakeholders, and customers—into the same room.   The results were dramatic. The team was about to invest millions integrating with an external vendor. Through the assumption mapping workshop, they uncovered huge risks and realized customers didn't actually want that solution. "We need to pivot," she declared. Instead of the expensive integration, they developed educational modules and scripts for customer support and advisors. The team sat with advisors, listening to actual customer calls, creating solutions based on real needs rather than assumptions. The insight transformed not just the project but the project manager herself. She took these discovery practices across the entire organization, teaching everyone how to conduct proper discovery and fundamentally shifting the product development paradigm. One person, willing to facilitate rather than dictate, made this impact. "Product owner can facilitate creation of that [vision]," Alidad explains. "It's not just product owner or a team. It's the broader stakeholder and customer community that need to co-create that."   Self-reflection Question: Are you facilitating the creation of vision with your stakeholders and customers, or are you becoming a proxy between the team and the real sources of insight? The Bad Product Owner: Creating Barriers Instead of Connections "He did the opposite, just creating barriers between the team and the environment." - Alidad Hamidi   The Product Owner was new to the organization, technically skilled, and genuinely well-intentioned. The team was developing solutions for clinicians—complex healthcare work requiring deep domain understanding. Being new, the PO naturally leaned into his strength: technical expertise. He spent enormous amounts of time with the team, drilling into details, specifying exactly how everything should look, and giving the team ready-made solutions instead of problems to solve.   Alidad kept telling him: "Mate, you need to spend more time with our stakeholder, you need to understand their perspective." But the PO didn't engage with users or stakeholders. He stayed comfortable in his technical wheelhouse, designing solutions in isolation. The results were predictable and painful. Halfway through work, the PO would realize, "Oh, we really don't need that." Or worse, the team would complete something and deliver it to crickets—no one used it because no one wanted it. "Great person, but it created a really bad dynamic," Alidad reflects. What should have been the PO's job—understanding the environment, stakeholder needs, and market trends—never happened. Instead of putting people in front of the environment to learn and adapt, he created barriers between the team and reality.   Years later, Alidad's perspective has matured. He initially resented this PO but came to realize: "He was just being human, and he didn't have the right support and the environment for him." Sometimes people learn only after making mistakes. The coaching opportunity isn't to shame or blame but to focus on reflection from failures and supporting learning. Alidad encouraged forums with stakeholders where the PO and team could interact directly, seeing each other's work and constraints. The goal isn't perfection—it's creating conditions where Product Owners can connect teams to customers rather than standing between them.   Self-reflection Question: What barriers might you be unintentionally creating between your team and the customers or stakeholders they need to serve, and what would it take to remove yourself from the middle?   [The Scrum Master Toolbox Podcast Recommends]

Alidad Hamidi: Maximizing Human Potential as the Measure of Success Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Does my work lead into maximizing human potential? Maximizing the ability of the human to use their potential and freedom." - Alidal Hamidi   Alidad calls himself a "recovering agility coach," and for good reason. For years, he struggled to define success in his work. As an enterprise coach, he plants seeds but never sees the trees grow. By the time transformation takes root, he's moved on to the next challenge. This distance from outcomes forced him to develop a more philosophical definition of success—one rooted not in deliverables or velocity charts, but in human potential and freedom.   His measure of success centers on three interconnected questions. First, are customers happy with what the teams create? Notice he says "create," not "deliver"—a deliberate choice. "I really hate the term product delivery, because delivery means you have a feature factory," he explains. Creating value requires genuine interaction between people who solve problems and people who have problems, with zero distance between them. Second, what's the team's wellbeing? Do they have psychological safety, trust, and space for innovation? And third, is the team growing—and by "team," Alidad means the entire organization, not just the squad level.   There's a fourth element he acknowledges: business sustainability. A bank could make customers ecstatic by giving away free money, but that's not viable long-term. The art lies in balance. "There's always a balance, sometimes one grows more than the other, and that's okay," Alidad notes. "As long as you have the awareness of why, and is that the right thing at the right time." This definition of success requires patience with the messy reality of organizations and faith that when humans have the freedom to use their full potential, both people and businesses thrive.   Self-reflection Question: If you measured your success solely by whether you're maximizing human potential and freedom in your organization, what would you start doing differently tomorrow? Featured Retrospective Format for the Week: Six Intrinsic Motivators Alidad's favorite retrospective format comes from Open Systems Theory—the Six Intrinsic Motivators. This approach uses the OODA Loop philosophy: understanding reality and reflecting on actions. "Let's see what actually happened in reality, rather than our perception," Alidad explains.   The format assesses six elements. Three are personal and can have too much or too little (rated -10 to +10): autonomy in decision making, continuous learning and feedback, and variety in work. Three are team environment factors that you can't have too much of (rated 0 to 10): mutual support and respect, meaningfulness (both socially useful work and seeing the whole product), and desirable futures (seeing development opportunities ahead).   The process is elegantly simple. Bring the team together and ask each person to assess themselves on each criterion. When individuals share their numbers, fascinating conversations emerge. One person's 8 on autonomy might surprise a teammate who rated themselves a 3. These differences spark natural dialogue, and teams begin to balance and adjust organically. "If these six elements don't exist in the team, you can never have productive human teams," Alidad states. He recommends running this at least every six months, or every three months for teams experiencing significant change. The beauty? No intervention from outside is needed—the team naturally self-organizes around what they discover together.   [The Scrum Master Toolbox Podcast Recommends]

Alidad Hamidi: The Tax Agile Teams Pay for Organizational Standards 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 set targets for people, they will achieve the target, even if that means destroying the system around them." - W. Edwards Deming (quoted by Alidad)   The tension is familiar to every Scrum Master working in large organizations: leadership demands standard operating models, flow time metrics below specific numbers, and reporting structures that fit neat boxes. Meanwhile, teams struggle under the weight of context-insensitive measurements that ignore the nuanced reality of their work. Alidad faces this challenge daily—creating balance between organizational demands and what teams actually need to transform and thrive.   His approach starts with a simple but powerful question to leaders: "What is it that you want to achieve with these metrics?" Going beyond corporate-speak to have real conversations reveals that most leaders want outcomes, not just numbers. Alidad then involves teams in defining strategies to achieve those outcomes, framing metrics as "the tax we pay" or "the license to play." When teams understand the intent and participate in the strategy, something surprising happens—most metrics naturally improve because teams are delivering genuine value, customers are happy, and team dynamics are healthy.   But context sensitivity remains critical. Alidad uses a vivid analogy: "If you apply lean metrics to Pixar Studio, you're gonna kill Pixar Studio. If you apply approaches of Pixar Studio to production line, they will go bankrupt in less than a month." Toyota's production line and Pixar's creative studio both need different approaches based on their context, team evolution, organizational maturity, and market environment. He advocates aligning teams to value delivery with end-to-end metrics rather than individual team measurements, recognizing that organizations operate in ecosystem models beyond simple product paradigms.   Perhaps most important is patience. "Try to not drink coffee for a week," Alidad challenges. "Even for a single person, one practice, it's very hard to change your behavior. Imagine for organization of hundreds of thousands of people." Organizations move through learning cycles at their own rhythm. Our job isn't to force change at the speed we prefer—it's to take responsibility for our freedom and find ways to move the system, accepting that systems have their own speed.   Self-reflection Question: Which metrics are you applying to your teams without considering their specific context, and what conversation do you need to have with leadership about the outcomes those metrics are meant to achieve?   [The Scrum Master Toolbox Podcast Recommends]

Alidad Hamidi: When a Billion-Dollar Team Becomes Invisible 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.   "Most of the times, it's not teams that are self-destructive or anything... Simple analogy is when a flower is not blooming, you don't fix the flower, you fix the soil." - Alidad Hamidi   The team sat on the sidelines, maintaining a large portfolio of systems while the organization buzzed with excitement about replatforming initiatives. Nobody seemed to care about them. Morale was low. Whenever technical challenges arose, everyone pointed to the same person for help. Alidad tried the standard playbook—team-building activities, bonding exercises—but the impact was minimal. Something deeper was broken, and it wasn't the team.   Then Alidad shifted his lens to systems thinking. Instead of fixing the flower, he examined the soil. Using the Viable Systems Model, he started with System 5—identity. Who were they? What value did they create? He worked with stakeholders to map the revenue impact of the systems this "forgotten" team maintained. The number shocked everyone: one billion dollars. These weren't legacy systems gathering dust—they were revenue-generating engines critical to the business. Alidad asked the team to run training series for each other, teaching colleagues about the ten different systems they managed. They created self-assessments of skill sets, making visible what had been invisible for too long. When Alidad made their value explicit to the organization, everything shifted. The team's perspective transformed. Later, when asked what made the difference, their answer was unanimous: "You made us visible. That's it." People have agency to change their environment, but sometimes they need someone to help the system see what it's been missing. Ninety percent of the time, when teams struggle, it's not the team that needs fixing—it's the soil they're planted in.   Self-reflection Question: What teams in your organization are maintaining critical systems but remain invisible to leadership, and what would happen if you made their value explicit? Featured Book of the Week: More Time to Think by Nancy Kline Alidad describes Nancy Kline's More Time to Think as transformative for his facilitation practice. While many Scrum Masters focus on filling space and driving conversations forward, this book teaches the opposite—how to create space and listen deeply. "It teaches you to create a space, not to fill it," Alidad explains. The book explores how to design containers—meetings, workshops, retrospectives—that allow deeper thinking to emerge naturally among team members.   For Alidad, the book answered a fundamental question: "How do you help people to find the solution among themselves?" It transformed his approach from facilitation to liberation, helping teams slow down so they can think more clearly. He first encountered the audiobook and was so impacted that he explored both "Time to Think" and this follow-up. While both are valuable, "More Time to Think" resonated more deeply with his coaching philosophy. The book pairs beautifully with systems thinking, helping Scrum Masters understand that creating the right conditions for thinking is often more powerful than providing the right answers. In this segment, we also refer to the book Confronting our freedom, by Peter Block et al.    [The Scrum Master Toolbox Podcast Recommends]

Alidad Hamidi: When Silence Becomes Your Most Powerful Coaching Tool 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 purposefully designed a moment of silence. Staying in the anxiety of being silenced. Do not interrupt the team. Put the question there, let them come up with a solution. It is very hard. But very effective." - Alidad Hamidi   Alidad walked into what seemed like a straightforward iteration manager role—what some use, instead of Scrum Master. The organization was moving servers to the cloud, a transformation with massive implications. When leadership briefed him on the team's situation, they painted a clear picture of challenges ahead. Yet when Alidad asked the team directly about the transformation's impact, the response was uniform: "Nothing."   But Alidad knew better. After networking with other teams, he discovered the truth—this team maintained software generating over half a billion dollars in revenue, and the transformation would fundamentally change their work. When he asked again, silence filled the room. Not the comfortable silence of reflection, but the heavy silence of fear and mistrust. Most facilitators would have filled that void with words, reassurance, or suggestions. Alidad did something different—he waited. And waited. For what felt like an eternity, probably a full minute, he stood in that uncomfortable silence, about to leave the room.   Then something shifted. One team member picked up a pen. Then another joined in. Suddenly, the floodgates opened. Debates erupted, ideas flew, and the entire board filled with impacts and concerns. What made the difference? Before that pivotal moment, Alidad had invested in building relationships—taking the team to lunch, standing up for them when managers blamed them for support failures, showing through his actions that he genuinely cared. The team saw that he wasn't there to tell them how to do their jobs. They started to trust that this silence wasn't manipulation—it was genuine space for their voices. This moment taught Alidad a profound lesson about Open Systems Theory and Socio-Technical systems—sometimes the most powerful intervention is creating space and having the courage to hold it.   Self-reflection Question: When was the last time you designed a moment of silence for your team, and what held you back from making it longer?   [The Scrum Master Toolbox Podcast Recommends]

Karim Harbott: From Requirements Documents to Customer Obsession—Redefining the PO Role 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: Strategic, Customer-Obsessed, and Vision-Driven   "The PO role in the team is strategic. These POs focus on the customer, outcomes, and strategy. They're customer-obsessed and focus on the purpose and the why of the product." - Karim Harbott   Karim believes the industry fundamentally misunderstands what a Product Owner should be. The great Product Owners he's seen are strategic thinkers who are obsessed with the customer. They don't just manage a backlog—they paint a vision for the product and help the entire team become customer-obsessed alongside them.  These POs focus relentlessly on outcomes rather than outputs, asking "why are we building this?" before diving into "what should we build?" They understand the purpose of the product and communicate it compellingly.  Karim references Amazon's "working backwards" approach, where Product Owners start with the customer experience they want to create and work backwards to figure out what needs to be built. Great POs also embrace the framework of Desirability (what customers want), Viability (what makes business sense), Feasibility (what's technically possible), and Usability (what's easy to use). While the PO owns desirability and viability, they collaborate closely with designers on usability and technical teams on feasibility.  This is critical: software is a team sport, and great POs recognize that multiple roles share responsibility for delivery. Like David Marquet teaches, they empower the team to own decisions rather than dictating every detail. The result? Teams that understand the "why" and can innovate toward it autonomously.   Self-reflection Question: Does your Product Owner paint a compelling vision that inspires the team, or do they primarily manage a list of tasks? The Bad Product Owner: The User Story Writer "The user story writer PO thinks it's their job to write full, long requirements documents, put it in JIRA, and assign it to the team. This is far away from what the PO role should be." - Karim Harbott   The anti-pattern Karim sees most often is the "User Story Writer" Product Owner. These POs believe their job is to write detailed requirements documents, load them into JIRA, and assign them to the team. It's essentially waterfall disguised as Agile—treating user stories like mini-specifications rather than conversation starters. This approach completely misses the collaborative nature of product development.  Instead of engaging the team in understanding customer needs and co-creating solutions, these POs hand down fully-formed requirements and expect the team to execute without question. The problem is that this removes the team's ownership and creativity. When POs act as the sole source of product knowledge, they become bottlenecks.  The team can't make smart tradeoffs or innovate because they don't understand the underlying customer problems or business context. Using the Desirability-Viability-Feasibility-Usability framework, bad POs try to own all four dimensions themselves instead of recognizing that designers, developers, and other roles bring essential perspectives. The result is disengaged teams, slow delivery, and products that miss the mark because they were built to specifications rather than shaped by collaborative discovery. Software is a team sport—but the User Story Writer PO forgets to put the team on the field.   Self-reflection Question: Is your Product Owner engaging the team in collaborative discovery, or just handing down requirements to be implemented?   [The Scrum Master Toolbox Podcast Recommends]

Karim Harbott: Don't Scale Dysfunction—Fix the Team First Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "How do you define the success of a football manager? Football managers are successful when the team is successful. For Scrum Masters it is also like that. Is the team better than it was before?" - Karim Harbott   Karim uses a powerful analogy to define success for Scrum Masters: think of yourself as a football manager. A football manager isn't successful because they personally score goals—they're successful when the team wins. The same principle applies to Scrum Masters. Success isn't measured by how many problems you solve or how busy you are. It's measured by whether the team is better than they were before.  Are they more self-organizing? More effective? More aligned with organizational outcomes?  This requires a mindset shift. Unlike sprinters competing individually, Scrum Masters succeed by enabling others to be better.  Karim recommends involving the team when defining success—what does "better" mean to them? He also emphasizes linking the work of the team to organizational objectives. When teams understand how their efforts contribute to broader goals, they become more engaged and purposeful. But there's a critical warning: don't scale dysfunction! If a team isn't healthy, improving it is far more important than expanding your coaching to more teams.  A successful Scrum Master creates teams that don't need constant intervention—teams that can manage themselves, make decisions, and deliver value consistently. Just like a great football manager builds a team that plays brilliantly even when the manager isn't on the field.   Self-reflection Question: Is your team more capable and self-sufficient than they were six months ago, or have they become more dependent on you? Featured Retrospective Format for the Week: Systems Modeling with Causal Loop Diagrams "It shows how many aspects of the system there are and how things are interconnected. This helps us see something that we would not come up with in normal conversations." - Karim Harbott   Karim recommends using systems modeling—specifically causal loop diagrams—as a retrospective format. This approach helps teams visualize the complex interconnections between different aspects of their work. Instead of just listing what went wrong or right, causal loop diagrams reveal how various elements influence each other, often uncovering hidden feedback loops and unintended consequences.  The power of this format is that it surfaces insights the team wouldn't discover through normal conversation. Teams can then think of their retrospective actions as experiments—ways to interact with the system to test hypotheses about what will improve outcomes. This shifts retrospectives from complaint sessions to scientific inquiry, making them far more actionable and engaging. If your team is struggling with recurring issues or can't seem to break out of patterns, systems modeling might reveal the deeper dynamics at play.   [The Scrum Master Toolbox Podcast Recommends]

Karim Harbott: You Can't Make a Flower Grow Faster—The Oblique Approach to Shaping Culture Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "How can I make a flower grow faster? Culture is a product of the behaviors of people in the system." - Karim Harbott   For Karim, one of the biggest challenges—and enablers—in his current work is creating a supporting culture. After years of learning what doesn't work, he's come to understand that culture isn't something you can force or mandate. Like trying to make a flower grow faster by pulling on it, direct approaches to culture change often backfire.  Instead, Karim uses what he calls the "oblique approach"—changing culture indirectly by adjusting the five levers: leadership behaviors, organizational structure, incentives, metrics, and systems. Leadership behaviors are particularly crucial.  When leaders step back and encourage ownership rather than micromanaging, teams transform. Incentives have a huge impact on how teams work—align them poorly, and you'll get exactly the wrong behaviors.  Karim references Team of Teams by General Stanley McChrystal, which demonstrates how changing organizational structure and leadership philosophy can unlock extraordinary performance. He also uses the Competing Values Framework to help leaders understand different cultural orientations and their tradeoffs. But the most important lesson? There are always unexpected consequences. Culture change requires patience, experimentation, and a willingness to observe how the system responds. You can't force a flower to grow, but you can create the conditions where it thrives.   Self-reflection Question: Are you trying to change your organization's culture directly, or are you adjusting the conditions that shape behavior?   [The Scrum Master Toolbox Podcast Recommends]

Karim Harbott: Why System Design Beats Individual Coaching Every Time Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "You can't change people, but you can change the system. Change the environment, not the people." - Karim Harbott   Karim was coaching a distributed team that was struggling with defects appearing constantly during sprints. The developers and testers were at different sites, and communication seemed fractured. But Karim knew from experience that when teams are underperforming, the problem usually isn't the people—it's the system they're working in. He stepped back to examine the broader context, implementing behavior-driven development(BDD) and specification by example to improve clarity through BDD scenarios.  But the defects persisted.  Then, almost by accident, Karim discovered the root cause: the developers and testers were employed by different companies. They had competing interests, different incentives, and fundamentally misaligned goals. No amount of coaching the individuals would fix a structural problem like that.  It took months, but eventually the system changed—developers and testers were reorganized into unified teams from the same organization. Suddenly, the defects dropped dramatically. As Jocko Willink writes in Extreme Ownership, when something isn't working, look at the system first. Karim's experience proves that sometimes the most compassionate thing you can do is stop trying to fix people and start fixing the environment they work in.   Self-reflection Question: When your team struggles, do you look at the people or at the system they're embedded in? Featured Book of the Week: Scaling Lean and Agile Development by Craig Larman and Bas Vodde "This book was absolute gold. The way it is written, and the tools they talk about went beyond what I was talking about back then. They introduced many concepts that I now use." - Karim Harbott   Karim discovered Scaling Lean and Agile Development by accident, but it resonated with him immediately. The concepts Craig Larman and Bas Vodde introduced—particularly around LeSS (Large-Scale Scrum)—went far beyond the basics Karim had been working with. The book opened his eyes to system-level thinking at scale, showing how to maintain agility even as organizations grow.  It's packed with practical tools and frameworks that Karim still uses today. For anyone working beyond a single team, this book provides the depth and nuance that most scaling frameworks gloss over. Also worth reading: User Stories Applied by Mike Cohn, another foundational text that shaped Karim's approach to working with teams.   [The Scrum Master Toolbox Podcast Recommends]

Karim Harbott: The Day I Discovered I Was a Scrum Project Manager, Not a Scrum Master Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I was telling the team what to do, instead of helping the team to be better on their own. There's a lot more to being a Scrum Master than Agile—working with people is such a different skillset." - Karim Harbott   Karim thought he had mastered Scrum. He had read the books, understood the framework, and was getting things done. His team seemed to be moving forward smoothly—until he stepped away for a few weeks.  But, when he returned, everything had fallen apart. The team couldn't function without him constantly directing their work. That's when Karim realized he had fallen into one of the most common anti-patterns in Agile: the Scrum Project Manager.  Instead of enabling his team to be more effective, he had become their bottleneck. Every decision flowed through him, every task needed his approval, and the team had learned to wait for his direction rather than taking ownership themselves. The wake-up call was brutal but necessary.  Karim discovered that pushing project management responsibilities to the people doing the work—as David Marquet advocates—was far more powerful than being the hero who solves all problems. The real skill wasn't in telling people what to do; it was in creating an environment where they could figure it out themselves. Geoff Watts calls this servant leadership, and Karim learned it the hard way: a great Scrum Master makes themselves progressively less necessary, not more indispensable.   Self-reflection Question: Are you enabling your team to be more effective, or have you become the person they can't function without?   [The Scrum Master Toolbox Podcast Recommends]

BONUS: Organizations as Ecosystems — Understanding Complexity, Innovation, and the Three-Body Problem at Work In this fascinating conversation about complex adaptive systems, Simon Holzapfel helps us understand why traditional planning and control methods fail in knowledge work — and what we can do instead. Understanding Ecosystems vs. Systems "Complex adaptive systems are complex in nature and adaptive in that they evolve over time. That's different from a static system." — Simon Holzapfel   Simon introduces the crucial distinction between mechanical systems and ecosystems. While mechanical systems are predictable and static, ecosystems — like teams and organizations — are complex, adaptive, and constantly evolving. The key difference lies in the interactions among team members, which create emergent properties that cannot be predicted by analyzing individuals separately. Managers often fall into the trap of focusing on individuals rather than the interactions between them, missing where the real magic happens. This is why understanding your organization as an ecosystem, not a machine, fundamentally changes how you lead. In this segment, we refer to the Stella systems modeling application. The Journey from Planning to Emergence "I used to come into class with a lesson plan — doop, doop, doop, minute by minute agenda. And then what I realized is that I would just completely squash those questions that would often emerge from the class." — Simon Holzapfel   Simon shares his transformation from rigid classroom planning to embracing emergence. As a history and economics teacher for 10 years, he learned that over-planning kills the spontaneous insights that make learning powerful. The same principle applies to leadership: planning is essential, but over-planning wastes time and prevents novelty from emerging. The key is separating strategic planning (the "where" and "why") from tactical execution (the "how"), letting teams make local decisions while leaders focus on alignment with the bigger picture. "Innovation Arrives Stochastically" "Simply by noticing the locations where you've had your best ideas, we notice the stochasticness of arrival. Might be the shower, might be on a bike ride, might be sitting in traffic, might be at your desk — but often not." — Simon Holzapfel   Simon unpacks the concept of stochastic emergence — the idea that innovation cannot be scheduled or predicted in advance. Stochastic means something is predictable over large datasets but not in any given moment. You know you'll have ideas if you give yourself time and space, but you can't predict when or where they'll arrive. This has profound implications for managers who try to control when and how innovation happens. Knowledge work is about creating things that haven't existed before, so emergence is what we rely on. Try to squash it with too much control, and it simply won't happen. In this segment, we refer to the Systems Innovation YouTube channel. The Three-Body Problem: A Metaphor for Teams "When you have three nonlinear functions working at the same time within a system, you have almost no ability to predict its future state beyond just some of the shortest time series data." — Simon Holzapfel   Simon uses the three-body problem from physics as a powerful metaphor for organizational complexity. In physics, when you have three bodies (like planets) influencing each other, prediction becomes nearly impossible. The same is true in business — think of R&D, manufacturing, and sales as three interacting forces. The lesson: don't think you can master this complexity. Work with it. Understand it's a system. Most variability comes from the system itself, not from any individual person. This allows us to depersonalize problems — people aren't good or bad, systems can be improved. When teams understand this, they can relax and stop treating every unpredictable moment as an emergency. Coaching Leaders to Embrace Uncertainty "I'll start by trying to read their comfort level. I'll ask about their favorite teachers, their most hated teachers, and I'll really try to bring them back to moments in time that were pivotal in their own development." — Simon Holzapfel   How do you help analytical, control-oriented leaders embrace complexity and emergence? Simon's approach is to build rapport first, then gently introduce concepts based on each leader's background. For technical people who prefer math, he'll discuss narrow tail distributions and fat tails. For humanities-oriented leaders, he uses narrative and storytelling. The goal is to get leaders to open up to possibilities without feeling diminished. He might suggest small experiments: "Hold your tongue once in a meeting" or "Ask questions instead of making statements." These incremental changes help managers realize they don't have to be superhuman problem-solvers who control everything. Giving the Board a Number: The Paradox of Prediction "Managers say we want scientific management, but they don't actually want that. They want predictive management." — Simon Holzapfel   Simon addresses one of the biggest tensions in agile adoption: leaders who say "I just need to give the board a number" while also wanting innovation and adaptability. The paradox is clear — you cannot simultaneously be open to innovation and emergent possibilities while executing a predetermined plan with perfect accuracy. This is an artifact of management literature that promoted the "philosopher king" manager who knows everything. But markets are too movable, consumer tastes vary too much, and knowledge work is too complex for any single person to control. The burnout we see in leaders often comes from trying to achieve an impossible standard. In this segment, we refer to the episodes with David Marquet.  Resources for Understanding Complexity "Eric Beinhocker's book called 'The Origin of Wealth' is wonderful. It's a very approachable and well-researched piece that shows where we've been and where we're going in this area." — Simon Holzapfel   Simon recommends two key resources for anyone wanting to understand complexity and ecosystems. First, Eric Beinhocker's "The Origin of Wealth" explains how we developed flawed economic assumptions based on 19th-century Newtonian physics, and why we need to evolve our understanding. Second, the Systems Innovation YouTube channel offers brilliant short videos perfect for curious, open-minded managers. Simon suggests a practical approach: have someone on your team watch a video and share what they learned. This creates shared language around complexity and makes the concepts less personal and less threatening. The Path Forward: Systems Over Individuals "As a manager, our goal is to constantly evaluate the performance of the system, not the people. We can always put better systems in place. We can always improve existing systems. But you can't tell people what to do — it's not possible." — Simon Holzapfel   The conversation concludes with a powerful insight from Deming's work: about 95% of a system's productivity is linked to the system itself, not individual performance. This reframes the manager's role entirely. Instead of trying to control people, focus on improving systems. Instead of treating burnout as individual failure, see it as information that something in the system isn't working. Organizations are ever-changing ecosystems with dynamic properties that can only be observed, never fully predicted. This requires a completely different way of thinking about management — one that embraces uncertainty, values emergence, and trusts teams to figure things out within clear strategic boundaries. Recommended Resources As recommended resources for further reading, Simon suggests:  The Origin of Wealth, by Eric Beinhocker The Systems Innovation YouTube channel   About Simon Holzapfel   Simon Holzapfel is an educator, coach, and learning innovator who helps teams work with greater clarity, speed, and purpose. He specializes in separating strategy from tactics, enabling short-cycle decision-making and higher-value workflows. Simon has spent his career coaching individuals and teams to achieve performance with deeper meaning and joy. Simon is also the author of the Equonomist newsletter on Substack, where he explores the intersection of economics, equality, and equanimity in the workplace.   You can link with Simon Holzapfel on LinkedIn.

Darryl Wright: The PONO—Product Owners in Name Only and How They Destroy 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 Great Product Owner: Collaborative, Present, and Clear in Vision   "She was collaborative, and that meant that she was present—the opposite of the MIA product owner. She came, and she sat with the team, and she worked with them side by side. Even when she was working on something different, she'd be there, she'd be available." - Darryl Wright   Darryl shares an unusual story about one of the best Product Owners he's ever encountered—someone who had never even heard of Agile before taking the role. Working for a large consulting company with 170,000 staff worldwide, they faced a difficult project that nobody wanted to do. Darryl suggested running it as an Agile project, but the entire team had zero Agile experience. The only person who'd heard of Agile was a new graduate who'd studied it for one week at university—he became the Scrum Master. The executive sponsor, with her business acumen and stakeholder management skills, became the Product Owner despite having no idea what that meant.  The results were extraordinary: an 18-month project completed in just over 7 months, and when asked about the experience, the team's highest feedback was how much fun they had working on what was supposed to be an awful, difficult project. Darryl attributes this success to mindset—the team was open and willing to try something new.  The Product Owner brought critical skills to the role even without technical Agile knowledge: She was collaborative and present, sitting with the team and remaining available. She was decisive, making prioritization calls clearly so nobody was ever confused about priorities. She had excellent communication skills, articulating the vision with clarity that inspired the team. Her stakeholder management capabilities kept external pressures managed appropriately. And her business acumen meant she instantly understood conversations about value, time to market, and customer impact.  Without formal training, she became an amazing Product Owner simply by being open, willing, and committed. As Darryl reflects, going from never having heard of the role to being an inspiring Product Owner in 7 months was incredible—one of the most successful projects and teams he's ever worked with.   Self-reflection Question: If you had to choose between a Product Owner with deep Agile certification and no business skills, or one with strong business acumen and willingness to learn—which would serve your team better? The Bad Product Owner: The PONO—Product Owner in Name Only   "The team never saw the PO until the showcase. And so, the team would come along with work that they deemed was finished, and the product owner had not seen it before because he wasn't around. So he would be seeing it for the first time in the showcase, and he would then accept or reject the work in the showcase, in front of other stakeholders." - Darryl Wright   The most destructive anti-pattern Darryl has witnessed was the MIA—Missing in Action—Product Owner, someone who was a Product Owner in Name Only (PONO). This senior business person was too busy to spend time with the team, only appearing at the sprint showcase. The damage this created was systematic and crushing. The team would build work without Product Owner engagement, then present it in the showcase looking to be proud of their accomplishment.  The PO, seeing it for the first time, would accept or reject the work in front of stakeholders. When he rejected it, the team was crushed, deflated, demoralized, and made to look like fools in front of senior leaders—essentially thrown under the bus. This pattern violates multiple principles of Agile teamwork. First, there's no feedback loop during the sprint, so the team works blind, hoping they're building the right thing. Second, the showcase becomes a validation ceremony rather than a collaborative feedback session, creating a dynamic of subservience rather than curiosity. The team seeks approval instead of engaging as explorers discovering what delivers customer value together. Third, the PO positions themselves as judge rather than coach—extracting themselves from responsibility for what's delivered while placing all blame on the team.  As Deming's quote reminds us, "A leader is a coach, not a judge." When the PO takes the judge role, they're betraying fundamental Agile values.  The responsibility for what the team delivers belongs strictly to the Product Owner; the team owns how it's delivered.  When Darryl encounters this situation as a Scrum Master, he lobbies intensely with the PO: "Even if you can't spare any other time for the entire sprint, give us just one hour the night before the showcase." That single hour lets the team preview what they'll present, getting early yes/no decisions so they never face public rejection. The basic building block of any Agile or Scrum way of working is an empowered team—and this anti-pattern strips all empowerment away.   Self-reflection Question: Does your Product Owner show up as a coach who's building something together with the team, or as a judge who pronounces verdicts? How does that dynamic shape what your team is willing to try?   [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: The Retrospective Formats That Actually Generate Change 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. "My success is, how much have I helped the team achieve what they want? If what they want is to uplift quality, or to reduce their time to market, well then, my success is helping them achieve that." - Darryl Wright When Darryl enters a new organization, he's often told his success will be measured by percentage of Agile adoption or team maturity assessment scores. His response is direct: those are vanity metrics that show something for its own sake, not real success. True success requires multiple measures, carefully balanced to prevent gaming and to capture both the human and business dimensions of work. Darryl advocates balancing quantitative metrics like lead time and flow efficiency with qualitative measures like employee happiness and team self-assessment of productivity. He balances business outcomes like customer satisfaction and revenue with humanity metrics that track the team's journey toward high performance. Most importantly, Darryl believes his success metrics should be co-created with the team. If he's there to help the team, then success must be defined by how much he's helped them achieve what they want—not what he wants. When stakeholders fixate on output metrics like "more story points," Darryl uses a coaching approach to shift the conversation toward outcomes and value. "Would you be happy if your team checked off more boxes, but your customers were less happy?" he asks. This opens space for exploring what they really want to achieve and why it matters. The key is translating outputs into impacts, helping people articulate the business value or customer experience improvement they're actually seeking. As detailed in Better Value, Sooner, Safer, Happier by Jonathan Smart, comprehensive dashboards can track value across multiple domains simultaneously—balancing speed with quality, business success with humanity, quantitative data with qualitative experience. When done well, Agile teams can be highly productive, highly successful, and have high morale at the same time. We don't have to sacrifice one for the other—we can have both. Self-reflection Question: If your team could only track two metrics for the next sprint, what would they choose? What would you choose? And more importantly, whose choice should drive the selection? Featured Retrospective Format for the Week: The 4 L's and Three Little Pigs Darryl offers two favorites, tailored to different contexts. For learning environments, he loves the 4 L's retrospective: Liked, Learned, Lacked, and Longed For. This format creates space for teams to reflect on their learning journey, surfacing insights about what worked, what was missing, and what they aspire to moving forward. For operational environments, he recommends the Three Little Pigs retrospective, which brilliantly surfaces team strengths and weaknesses through a playful metaphor. The House of Straw represents things the team is weak at—nothing stands up, everything falls over. The House of Sticks is things they've put structure around, but it doesn't really work. The House of Bricks represents what they're solid on, what they can count on every time. Then comes the most important part: identifying the Big Bad Wolf—the scary thing, the elephant in the room that nobody wants to talk about but everyone knows is there. This format creates psychological safety to discuss the undiscussable. Darryl emphasizes two critical success factors for retrospectives: First, vary your formats. Teams that hear the same questions sprint after sprint will disengage, asking "why are you asking me again?" Different questions provide different lenses, generating fresh insights. Second, ensure actions come out of every retro. Nothing kills engagement faster than suggestions disappearing into the void. When people see their ideas lead to real changes, they'll eagerly return to the next retrospective. And don't forget to know your team—if they're sports fans, use sports retros; if they're scientists, use space exploration themes. Just don't make the mistake of running a "sailboat retro" with retiring mainframe engineers who'll ask if you think they're kindergarten children. For more retrospective formats, check out Retromat. [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: Why AI Adoption Will Fail Just Like Agile Did—Unless We Change 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. "People are looking to AI to solve their problems, and they're doing it in the same way that they previously looked to Agile to solve their problems for them. The problem with that is, of course, that Agile doesn't solve problems for you. What it does is it shines a light on where your problems are." - Darryl Wright The world has gone AI crazy, and Darryl sees history repeating itself in troubling ways. Organizations are rushing to adopt AI with the same magical thinking they once applied to Agile—believing that simply implementing the tool will solve their fundamental problems. But just as Agile reveals problems rather than solving them, AI will do the same. Worse, AI threatens to accelerate existing problems: if you have too many things moving at once, AI won't fix that, it will amplify the chaos. If you automate a bad process, you've simply locked in badness at higher speed. As Darryl points out, when organizations don't understand that AI requires them to still do the hard work of problem-solving, they're setting themselves up for disillusionment, and in five or twenty years, we'll hear "AI is dead" just like we now hear "Agile is dead." The challenge for Scrum Masters and Agile coaches is profound: how do you help people with something they don't know they need? The answer lies in returning to first principles. Before adopting any tool—whether Agile or AI—organizations must clearly define the problem they're trying to solve. As Einstein reportedly said, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions." Value stream mapping becomes essential, allowing teams to visualize where humans and AI agents should operate, with clear handovers and explicit policies. The cognitive load on software teams will increase dramatically as AI generates more code, more options, and more complexity. Without clear thinking about problems and deliberate design of systems, AI adoption will follow the same disappointing trajectory as many Agile adoptions—lots of activity, little improvement, and eventually, blame directed at the tool rather than the system. Self-reflection Question: Are you adopting AI to solve a clearly defined problem, or because everyone else is doing it? If you automated your current process with AI, would you be locking in excellence or just accelerating dysfunction? [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: The Agile Team That Committed to Failure for 18 Sprints Straight 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. "As Deming said, a bad system will beat a good person every time." - Darryl Wright Darryl was called in to help a struggling team at a large energy retailer. The symptoms seemed straightforward—low morale, poor relationships, and chronic underdelivery. But as he asked questions, a heartbreaking pattern emerged. The team had been "committing" to 110 story points per sprint while consistently delivering only 30. For 18 sprints. When Darryl asked why the team would commit to numbers they couldn't possibly achieve, the answer was devastating: "The business needs that much." This wasn't a problem of skill or capability—it was learned helplessness in action. Sprint after sprint, the team experienced failure, which made them more despondent and less effective, creating a vicious downward spiral. The business lost trust, the team lost confidence, and everyone was trapped in a system that guaranteed continued failure. When Darryl proposed the solution—committing to a realistic 30 points—he was told it was impossible because "the business needs 110 points." But the business wasn't getting 110 points anyway. They were getting broken promises, a demoralized team, stress leave, high churn, and a relationship built on distrust. Darryl couldn't change the system in that case, but the lesson was clear: adult people who manage their lives perfectly well outside work can become completely helpless inside work when the system repeatedly tells them their judgment doesn't matter. As Ricardo Semler observes in Maverick!, people leave their initiative at the door when organizations create systems that punish honest assessment and reward false promises. Self-reflection Question: Is your team committing to what they believe they can achieve, or to what they think someone else wants to hear? What would happen if they told the truth? Featured Book of the Week: Better Value, Sooner, Safer, Happier by Jonathan Smart Darryl describes Better Value, Sooner, Safer, Happier by Jonathan Smart as a treasure trove of real-life experience from people who have "had their sleeves rolled up in the trenches" for decades. What he loves most is the authenticity—the authors openly share not just their successes, but all the things that didn't work and why. One story that crystallizes the book's brilliance involves Barclays Bank and their ingenious approach to change adoption. Facing resistance from laggards who refused to adopt Agile improvements despite overwhelming social proof, they started publishing lists of "most improved teams." When resisters saw themselves at the bottom of these public lists, they called to complain—and were asked, "Did you have improvements we didn't know about?" The awkward pause would follow, then the inevitable question: "How do I get these improvements?" Demand creation at its finest. Darryl particularly appreciates that the authors present at conferences saying, "Let me tell you about all the things we've stuffed up in major agile transformations all around the world," bringing genuine humility and practical wisdom to every page. [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: When Enthusiasm Became Interference—Learning to Listen as a Scrum Master Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Wait stands for Why Am I Talking? Just ask yourself, wait, why am I talking? Is this the right moment for you to give an idea, or is this the right moment to just listen and let them have space to come up with ideas?" - Darryl Wright   Early in his Agile journey, Darryl was evangelically enthusiastic about the principles and practices that had transformed his approach to leadership. He believed he had discovered the answers people were seeking, and his excitement manifested in a problematic pattern—he talked too much. Constantly jumping in with solutions, ideas, and suggestions, Darryl dominated conversations without realizing the impact. Then someone pulled him aside with a generous gift: "You're not really giving other people time to come up with ideas or take ownership of a problem."  They introduced him to WAIT—Why Am I Talking?—an acronym that would fundamentally shift his coaching approach. This simple tool forced Darryl to pause before speaking and examine his motivations. Was he trying to prove himself? Did he think he knew better? Or was this genuinely the right moment to contribute? As he practiced this technique, Darryl discovered something profound: when he held space and waited, others would eventually step forward with insights and solutions.  The concept of "small enough to try, safe enough to fail" became his framework for deciding when to intervene. Not every moment requires a Scrum Master to step in—sometimes the most powerful coaching happens in silence. By developing better skills in active listening and learning to hold space for others, Darryl transformed from someone who provided all the answers into someone who created the conditions for shared leadership to emerge.   In this episode, we refer to David Marquet's episodes on the podcast for practical techniques on holding space and enabling leadership in others.   Self-reflection Question: When was the last time you caught yourself jumping in with a solution before giving your team space to discover it themselves? What would happen if you waited just five more minutes?   [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: How to Coach POs Who Treat Developers Like Mindless Robots In this episode, we refer to the previous episodes with David Marquet, author of Turn the Ship Around! The Great Product Owner: Trust and the Sprint Review That Changes 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. "She was like, oh my gosh, I've never seen this before, I didn't think it was possible. I just saw you deliver stuff in 2 weeks that I can actually use." - Alex Sloley In 2011, Alex worked with a client organization creating software for external companies. They needed a Product Owner for a new Agile team, and a representative from the client—who had never experienced Scrum—volunteered for the role. She was initially skeptical, having never witnessed or heard of this approach. Alex gently coached her through the process, asking her to trust the team and be patient. Then came the first Sprint Review, and everything changed. For the first time in her career, she saw working product delivered in just two weeks that she could actually touch, see, and use. Her head exploded with possibility. Even though it didn't have everything and wasn't perfect, it was remarkably good. That moment flipped a switch—she became fully engaged and transformed into a champion for Agile adoption, not just for the team but for the entire company. Alex reflects that she embodied all five Scrum values: focus (trusting the team's capacity), commitment (attending and engaging in all events), openness (giving the new approach a chance), respect (giving the team space to succeed), and courage (championing an unfamiliar process). The breakthrough wasn't about product ownership techniques—it was about creating an experience that reinforced Scrum values, allowing her to see the potential of a bright new future. Self-reflection Question: What practices, techniques, or processes can you implement that will naturally and automatically build the five Scrum values in your Product Owner? The Bad Product Owner: When Control Becomes Domination Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "They basically just owned the team. The developers on the team might as well have been mindless robots, because they were being assigned all the work, told how much work they could do in a sprint, what the work was." - Alex Sloley In 2018, while working with five interconnected Product Owners, Alex observed a Sprint Planning session that revealed a severe anti-pattern. One Product Owner completely controlled everything, telling the team exactly what work they would take into the Sprint, assigning specific work to specific people by name, and dictating precisely how they would implement solutions down to technical details like which functions and APIs to use. The developers were reduced to helpless executors with no autonomy, while the Scrum Master sat powerless in the corner. Alex wondered what caused this dynamic—was the PO a former project manager? Had the team broken trust in the past? What emotional baggage or trauma led to this situation? His approach started with building trust through coffee meetings and informal conversations, crucially viewing the PO not as the problem but as someone facing their own impediment. He reframed the challenge as solving the Product Owner's problem rather than fixing the Product Owner. When he asked, "Why do you have to do all this? Can't you trust the team?" and suggested the PO could relax if they delegated, the response was surprisingly positive. The PO was willing to step back once given permission and assurance. Alex's key lesson: think strategically about how to build trust and who needs to build trust with whom. Sometimes the person who appears to be creating problems is actually struggling under their own burden. Self-reflection Question: When you encounter a controlling Product Owner, do you approach the situation as "fixing" the PO or as "solving the PO's problem"? How might this reframe change your coaching strategy? [The Scrum Master Toolbox Podcast Recommends]

Alex Sloley: Why Sticky Notes Are Your Visualization Superpower in Retrospectives 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. "Like the smell, the vibe is something you feel. If you're having a successful impact on the organization or on teams as a Scrum Master, you can feel it, you can smell it. It's intangible." - Alex Sloley Alex introduces a compelling concept from Sumantra Ghoshal about "the smell of the workplace"—you can walk into an environment and immediately sense whether it smells like fresh strawberries and cream or a dumpster fire. In Australia, there's a cultural reference from the movie "The Castle" about "the vibe of the thing," and Alex emphasizes that as a successful Scrum Master, you can feel and smell when you're having an impact. While telling executives you're measuring "vibe" might be challenging, Alex shares three concrete ways he's measured success. The key insight is that success isn't always measurable in traditional ways, but successful Scrum Masters develop an intuition for sensing when their work is making a meaningful difference. Self-reflection Question: Can you articulate the "vibe" or "smell" of your current team or organization? What specific indicators tell you whether your Scrum Master work is truly making an impact beyond the metrics? Featured Retrospective Format for the Week: Sticky Notes for Everything Alex champions any retrospective format that includes sticky notes, calling them a "visualization superpower." With sticky notes, teams can visualize anything—the good, the bad, improvements, options, possibilities, and even metrics. They make information transparent, which is critical for the inspect-and-adapt cycle that forms the heart of Scrum. Alex emphasizes being strategic about visualization: identify a challenge, figure out how to make it visual, and then create experiments around that visualization. Once something becomes visible, magic happens because the team can see patterns they've never noticed before. You can use different sizes, colors, and positions to visualize constraints in the system, including interruptions, unplanned work, blocker clustering, impediments, and flow. This approach works not just in retrospectives but in planning, reviews, and daily scrums. The key principle is that you must have transparency in order to inspect, and you must inspect to adapt. Alex's practical advice: be strategic about what you choose to visualize, involve the team in determining how to make challenges visible, and watch as the transparency naturally leads to insights and improvement ideas. [The Scrum Master Toolbox Podcast Recommends]