BONUS: Why Large Organizations Struggle to Innovate With Elliott Parker

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

23 Dec 21min

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

22 Dec 17min

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

19 Dec 17min

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

18 Dec 17min

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

17 Dec 18min

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

16 Dec 15min

Natalia Curusi: When Your Technical Expertise Becomes Your Biggest Scrum Master Weakness Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "I thought my technical background was my biggest strength, but I understood that this was my biggest weakness—I was coming into stand-ups saying 'I know how we need to fix that issue,' and I was a Scrum Master." - Natalia Curusi   Natalia stepped into her first blended role as team leader and Scrum Master full of confidence. With years of programming experience behind her, she believed she could guide her team through any technical challenge. But during morning stand-ups, she found herself suggesting solutions, directing technical approaches, and sharing her expertise freely. The team listened—after all, she was their former leader. They implemented her suggestions, but when those solutions failed, the team didn't have the thinking process to adapt them to their context.  Natalia realized she was preventing the team's learning and ownership by taking control away from them. The turning point came when she made a deliberate choice: she selected the most technical person on the team to become the technical authority and committed to never stepping on his feet again. From that moment forward, she focused purely on the Scrum Master role—asking questions, fostering collaboration, and shutting up to listen actively.  Years later, that technical lead followed her to another job, and they remain friends to this day. Natalia learned that her contribution wasn't about giving solutions—it was about keeping the team from losing ownership of their work.   Self-reflection Question: When you attend your team's daily stand-up, are you contributing to collaboration, or is your contribution keeping the team from owning their work?   [The Scrum Master Toolbox Podcast Recommends] 🔥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 Natalia Curusi   With over 20 years in software delivery, Natalia Curusi is an expert in Agile Transformations, Delivery Optimisation, and Systems Thinking. As an Agile Coach at Endava, she leads Asia Pacific initiatives, driving business agility and continuous improvement while mentoring teams to build customer-centric, high-performing, and collaborative cultures.   You can link with Natalia Curusi on LinkedIn.

15 Dec 14min

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

13 Dec 33min