Episodes

  • Why Agile Fatigue Means We Need to Change Our Approach | Steve Martin

    Why Agile Fatigue Means We Need to Change Our Approach | Steve Martin
    Dec 31 2025
    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.
    Show more Show less
    17 mins
  • When a Distributed Team's Energy Vanishes into the Virtual Void | Steve Martin

    When a Distributed Team's Energy Vanishes into the Virtual Void | Steve Martin
    Dec 30 2025
    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.
    Show more Show less
    18 mins
  • When the Gospel of Agile Becomes a Barrier to Change | Steve Martin

    When the Gospel of Agile Becomes a Barrier to Change | Steve Martin
    Dec 29 2025
    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.
    Show more Show less
    15 mins
  • 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 With Vasco Duarte
    Dec 26 2025
    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...
    Show more Show less
    28 mins
  • BONUS Breaking Through The Organizational Immune System | Vasco Duarte

    BONUS Breaking Through The Organizational Immune System | Vasco Duarte
    Dec 25 2025
    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 ...
    Show more Show less
    29 mins
  • BONUS: Recovering the Essence of Agile - What's Already Working With Vasco Duarte

    BONUS: Recovering the Essence of Agile - What's Already Working With Vasco Duarte
    Dec 24 2025
    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, ...
    Show more Show less
    24 mins
  • Xmas Special: Why project management tools fail software development - and what works instead!

    Xmas Special: Why project management tools fail software development - and what works instead!
    Dec 23 2025
    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 ...
    Show more Show less
    21 mins
  • Xmas Special: Software Industry Transformation - Why Software Development Must Mature With Vasco Duarte

    Xmas Special: Software Industry Transformation - Why Software Development Must Mature With Vasco Duarte
    Dec 22 2025
    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 - ...
    Show more Show less
    17 mins