Coaching Product Owners to Be the Voice of the Customer | Steve Martin
Steve Martin: Coaching Product Owners to Be the Voice of the Customer In this episode, we refer to Henrik Kniberg's "Product Owner in a Nutshell" video and Product Ownership by Geoff Watts. The Great Product Owner: Rob Gard's Customer Obsession 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 role of the PO really is to help the team empathize with the user, the customer of the product, because that's how they can develop great solutions." - Steve Martin Rob Gard worked at a fintech firm and is now CPO of a major fintech company. Steve describes him as having a brilliant mind and being a real agileist—someone Steve learned a huge amount about Agile from. Rob's defining characteristic was his absolute obsession with the user. Everything focused on customer pain points. Working with engineering teams serving military customers, Rob held regular workshops with those customers to understand their pain firsthand. He was literally the voice of the customer, not theoretically but practically. Rob pushed and challenged teams to be more innovative, always looking for better ways of providing better software. His gift was communication—specifically, briefing the team on the problem rather than just reading out stories in refinement sessions. This is the anti-pattern many Product Owners fall into: going through the motions, reading requirements without context. Real product ownership, as Rob demonstrated, is telling a story that helps the team empathize and understand the pain. When teams can internalize customer problems, they develop better solutions. Rob's ability to communicate the problem into the minds of teams enabled them to serve customers more effectively. This is the essence of great Product Ownership: not being a proxy for management, not juggling multiple teams, but being deeply connected to customer pain and translating that pain into context the team can work with. Self-reflection Question: Do your refinement sessions tell stories that help the team empathize with customer pain, or do you just read out requirements? The Bad Product Owner: Proxies for Management Instead of Customer Advocates 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 weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte Steve emphasizes that Product Owners often have great intentions but struggle due to lack of training and coaching. The anti-patterns are systemic: commercial managers "dressed up" as Product Owners without understanding the role. Project managers transitioning to PO roles—though Steve notes PMs can make really good POs with proper support. The most damaging pattern is Product Owners spread across multiple teams, having very little time to focus on any single team or their customers. These POs become proxies—representing the voice of senior management rather than the voice of the customer. They cascade requirements downward instead of bringing customer insights upward. The solution isn't to criticize these struggling Product Owners but to help them understand their role and see what good looks like. Steve recommends Henrik Kniberg's "Product Owner in a Nutshell" video—15 minutes, 15 years old, still profoundly relevant. He also points to Product Ownership by Geoff Watts and formal training like CSPO or IC Agile Product Ownership courses. The fundamental issue is meeting Product Owners where they are, providing coaching and support to transform them from management proxies into customer advocates. When POs understand their role as empathy builders between customers and teams, everything changes. Self-reflection Question: Is your Product Owner the voice of senior management or the voice of the customer? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Steve Martin You can link with Steve Martin on LinkedIn. Steve is an Agile Coach, mentor, and founder of The Agile Master Academy. After over 14 years leading Agile transformation programmes, he's on a mission to elevate Scrum Masters—building high-performing teams, measurable impact, and influence—and raising industry standards of Agile mastery through practical, evidence-led coaching. You can also find Steve's insights on his YouTube channel: Agile Mastery Show.
2 Tammi 13min
Making Scrum Master Success Visible with OKRs That Actually Work | Steve Martin
Steve Martin: Making Scrum Master Success Visible with OKRs That Actually Work Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "It is not the retrospective that is the success of the retrospective. It is the ownership and accountability where you take improvements after the session." - Steve Martin The biggest problem for Scrum Masters isn't just defining success—it's being able to shout it from the rooftops with tangible evidence. Steve champions OKRs as an amazing way to define and measure success, but with a critical caveat: they've historically been poorly written and implemented in dark rooms by executives, then cascaded down to teams who never bought in. Steve's approach is radically different. Create OKRs collectively with the team, stakeholders, and end users. Start by focusing on the pain—what problems or pain points do customers, users, and stakeholders actually experience? Make the objective the goal to solve that problem, then define how to measure progress with key results. When everyone is bought in—Scrum Master, engineers, Product Owner, stakeholders, leaders—all pulling in the same direction, magic happens. Make progress visible on the wall like a speedometer, showing exactly where you are at any moment. For an e-commerce checkout, the problem might be too many steps. The objective: reduce pain for users checking out quickly. The baseline: 15 steps today. The target: 5 clicks in three months. Everyone can see the dial moving. Everything should focus on the customer as the endpoint. The challenge is distinguishing between targets imposed from above ("increase sales by 10%") and objectives created collaboratively based on factors the team can actually control. Find what you can control first, work with customers to understand their pain, and start from there. Self-reflection Question: Can you articulate your team's success with specific, measurable outcomes that everyone—from developers to executives—understands and owns? Featured Retrospective Format for the Week: Post-Retro Actions and Ownership The success of a retrospective isn't the retrospective itself—it's what happens after. Steve emphasizes that ownership and accountability matter more than the format of the session. Take improvements from the retrospective and bring them into the sprint as user stories with clear structure: this is the problem, how we'll solve it, and how we'll measure impact. Assign collective ownership—not just a single person, but the whole team owns the improvement. Then bring improvements into the demo so the team showcases what changed. This creates cultural transformation: the team themselves want to bring improvements, not just because the Scrum Master pushed them. For ongoing impediments, conduct root cause analysis. Create a system to escalate issues beyond the team's control—make these visible on another board or with the leadership team. Find peers in pain: teams with the same problems can work together collectively. The retrospective format matters less than this system of ownership, action, measurement, and visibility. Stop retrospective theatre—going through the motions without taking action. Make improvements real by treating them like any other work: visible, measured, owned, and demonstrated. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Steve Martin You can link with Steve Martin on LinkedIn. Steve is an Agile Coach, mentor, and founder of The Agile Master Academy. After over 14 years leading Agile transformation programmes, he's on a mission to elevate Scrum Masters—building high-performing teams, measurable impact, and influence—and raising industry standards of Agile mastery through practical, evidence-led coaching. You can also find Steve's insights on his YouTube channel: Agile Mastery Show.
1 Tammi 18min
Why Agile Fatigue Means We Need to Change Our Approach | Steve Martin
Steve Martin: Why Agile Fatigue Means We Need to Change Our Approach 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 teach transformation, we support transformation, we help change, but we don't really understand what they're changing from." - Steve Martin Steve believes Agile as a whole is on the back foot, possibly regressing. There's palpable fatigue in the industry, and transformation in its current form hasn't been the success we hoped. Organizations still need to work in a state of agility—making rapid decisions, aligning teams, delivering value at pace—but they're exhausted by how we've implemented Agile. As Agile professionals, Steve argues, we have a responsibility to take stock and reflect on what's not working. The problem isn't that organizations don't need agility; it's that we've been force-feeding them frameworks without understanding their context. Steve invokes an ancient principle: "When the student is ready, the teacher will appear." But we haven't waited for readiness—we've barged in with Big Bang transformations, bringing 10, 15, or 20 Agile coaches to "save the world." The solution requires meeting people where they are, understanding what they're changing from, not just what they're changing to. Steve's coaching conversation centers on a radical idea: stop trying to help teams that don't want to be helped. Focus on teams already interested in incremental, adaptable delivery. Run small pilots, learn what works, then scale when ready. The age of prescriptive transformation is over. We need to adapt to the reality of the moment, experiment with what works, and have the courage to change the plan when our approach isn't working. Self-reflection Question: Are you forcing Agile on teams that aren't ready, or are you working with those who genuinely want to improve their delivery approach? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Steve Martin You can link with Steve Martin on LinkedIn. Steve is an Agile Coach, mentor, and founder of The Agile Master Academy. After over 14 years leading Agile transformation programmes, he's on a mission to elevate Scrum Masters—building high-performing teams, measurable impact, and influence—and raising industry standards of Agile mastery through practical, evidence-led coaching. You can also find Steve's insights on his YouTube channel: Agile Mastery Show.
31 Joulu 202516min
When a Distributed Team's Energy Vanishes into the Virtual Void | Steve Martin
Steve Martin: When a Distributed Team's Energy Vanishes into the Virtual Void 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 weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte (describing Steve's team situation) The infrastructure team looked promising on paper: Product Owner in Italy, hardware engineers in Budapest, software engineers in Bucharest, designers in the UK. The team started with energy and enthusiasm, but within a month, something shifted. People stopped showing up for daily stand-ups. Cameras went dark during meetings. Engagement in retrospectives withered. This wasn't just about being distributed—plenty of teams work across time zones successfully. The problem ran deeper. The Scrum Master had a conflict of interest, serving dual roles as both facilitator and engineer. Team members were simultaneously juggling three or four other projects, treating this work as just another item on an impossibly long list. Steve spent a couple of months watching the deterioration before recognizing the root cause: there was no leadership sponsorship or buy-in. Stakeholders weren't invested. The team wasn't actually a team—they were individuals happening to work on the same project. Steve considers this a failure because he couldn't solve it. Sometimes, the absence of organizational support creates an unsolvable puzzle. Without leadership commitment, even the most skilled Scrum Master can't manufacture the conditions for team success. In this episode, we refer to The Phoenix Project by Gene Kim, a book about organizational culture disguised as a DevOps novel. Self-reflection Question: Is your team truly dedicated to one mission, or are they a collection of individuals spread across competing priorities? Featured Book of the Week: The Phoenix Project by Gene Kim "There's a lot of good lightning bulb moments that go off." - Steve Martin Steve describes The Phoenix Project as a book about culture, not just DevOps. Written like a novel following a mock company, it creates continuous light bulb moments for readers. The book resonated deeply with Steve because it exposed patterns he'd experienced firsthand—particularly the anti-pattern of single points of failure. Steve had worked with an engineer who would spend entire weekends doing releases, holding everything in his head, then burning out and taking three days off to recover. This engineer was the bottleneck, the single point of failure that put the entire system at risk. The Phoenix Project illuminates how knowledge hoarding and dependency on individuals creates organizational fragility. The solution isn't just technical—it's cultural. Teams need to share knowledge and understanding, deliberately de-risking the concentration of expertise in one person's mind. Steve recommends this book for anyone trying to understand why organizational transformation requires more than process changes—it demands a fundamental shift in how teams think about knowledge, risk, and collaboration. [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Steve Martin You can link with Steve Martin on LinkedIn. Steve is an Agile Coach, mentor, and founder of The Agile Master Academy. After over 14 years leading Agile transformation programmes, he's on a mission to elevate Scrum Masters—building high-performing teams, measurable impact, and influence—and raising industry standards of Agile mastery through practical, evidence-led coaching. You can also find Steve's insights on his YouTube channel: Agile Mastery Show.
30 Joulu 202518min
When the Gospel of Agile Becomes a Barrier to Change | Steve Martin
Steve Martin: When the Gospel of Agile Becomes a Barrier to 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. "It took me a while to realize that that's what I was doing. I felt the reason wasn't working was them, it wasn't me." - Steve Martin Steve carried the Scrum Guide like a Bible in his early days as an Agile coach. He was a purist—convinced he had an army of Agile practitioners behind him, ready to transform every team he encountered. When teams questioned his approach, he would shut down the conversation: "Don't challenge me on this, because this is how it's supposed to be." But pushing against the tide and spreading the gospel created something unexpected: resistance. The more Steve insisted on his purist view, the more teams pushed back. It took him a couple of years to recognize the pattern. The problem wasn't the teams refusing to change—it was his approach. Steve's breakthrough came when he started teaching and realized he needed to meet people where they are, not force them to come to him. Like understanding a customer's needs, he learned to build empathy with teams, Product Owners, and leaders. He discovered the power of creating personas for the people he was coaching, understanding their context before prescribing solutions. The hardest part wasn't learning this lesson—it was being honest about his failures and admitting that his righteous certainty had been the real impediment to transformation. Self-reflection Question: Are you meeting your teams where they are, or are you pushing them toward where you think they should be? [The Scrum Master Toolbox Podcast Recommends] 🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥 Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people. 🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue. Buy Now on Amazon [The Scrum Master Toolbox Podcast Recommends] About Steve Martin You can link with Steve Martin on LinkedIn. Steve is an Agile Coach, mentor, and founder of The Agile Master Academy. After over 14 years leading Agile transformation programmes, he's on a mission to elevate Scrum Masters—building high-performing teams, measurable impact, and influence—and raising industry standards of Agile mastery through practical, evidence-led coaching. You can also find Steve's insights on his YouTube channel: Agile Mastery Show.
29 Joulu 202514min
BONUS The Operating System for Software-Native Organizations - The Five Core Principles With Vasco Duarte
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.
26 Joulu 202527min
BONUS Breaking Through The Organizational Immune System | Vasco Duarte
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.
25 Joulu 202529min
BONUS: Recovering the Essence of Agile - What's Already Working With Vasco Duarte
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.
24 Joulu 202523min
