AI becomes useful when it moves from generic answers into the daily work of solving real problems. In this BONUS episode, William Davis shares how he started building his own AI-assisted project management tools, what went wrong when the code grew too fast, and how Scrum Masters can use AI more carefully at individual, team, and project levels.
When AI Stops Being a Curiosity
“I really need to get a handle on how to productively use AI in my job.”
William’s shift started with a familiar problem: release plans are full of uncertainty, but stakeholders still need to understand what might happen and when. Instead of handcrafting uncertain delivery ranges in Excel, William used AI to build a desktop application that created probabilistic Gantt charts. In his work, these were not traditional command-and-control schedules. They were release plans that showed stakeholders a realistic range of possible delivery dates, making uncertainty visible instead of hiding it behind a false promise.
“Nobody really told me, okay, this is what success looks like. And that’s a very dangerous thing, because you can just go in there and be busy and be executing.” – Mukhtar Kadiri
Early in his career, Mukhtar was sitting on the bench with nothing to do — and his days felt numbered. When a low-priority project came along, he jumped at it, eager to prove himself. He met the contract holder, understood the terrain, laid out a plan, and started executing. Then a stakeholder he hadn’t even mapped called him into her office and blasted him.
The project wasn’t aligned with her vision — and it turned out she was more powerful than the contract holder, even though she appeared nowhere on the org chart. That moment forced Mukhtar to rethink everything. He started scheduling one-on-ones with every stakeholder he could find, asking each one what success looked like from their perspective, and then asking them to point him to the next person he should talk to.
What emerged was a comprehensive success criteria that no single person had articulated before — because even the leaders hadn’t sat down to define it. Mukhtar learned that in complex, ambiguous environments, success isn’t handed to you. It’s your job to surface it, articulate it, and get everyone aligned. As he puts it, don’t be fooled by org charts — the real stakeholder map is one you have to build yourself through one-on-one conversations.
Self-reflection Question: When was the last time you validated your stakeholder map beyond the org chart — and could there be an invisible stakeholder whose definition of success you haven’t yet discovered?
Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters
Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today!The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!
About Mukhtar Kadiri
Mukhtar Kadiri is a PM career coach with 15+ years in project management. He specializes in helping project and program managers land $100–300K roles. He’s been named the #1 PM in Canada. He also has a LinkedIn following of 67K+ professionals. He shares practical insights for FREE on LinkedIn, where he talks about job search, career growth, and thriving as a PM.
This episode is a cross-post from The EBFC Show, Felipe Engineer-Manriquez’s podcast exploring Lean and Agile in construction. In this conversation, Felipe interviews Vasco about the #NoEstimates movement, throughput-based planning, and why traditional project management is still stuck in the middle ages of managing creative work.
The Human Side of Scrum That the Scrum Guide Doesn’t Cover
“When you go into a daily meeting and you start looking at the people in that room, maybe they are the exact same people that were there yesterday, but the team is totally different. Somebody might have had a bad night’s sleep, somebody might have had an argument with their spouse. These are human beings. These are not machines that you can just distribute work to.”
Vasco’s path to agile coaching started with a realization that most practitioners eventually reach: the problems in software development aren’t technological. They’re about people — getting agreements, sharing information at the right time, making the collective brain of a team actually function.
The Scrum Guide gives you organizing principles — how many meetings, who’s in them — but it says almost nothing about the real-time feedback cycle between humans that makes or breaks a team. That’s why the Scrum Master role exists: to be the lubricant for human interactions, to break down complex ideas into items the collective mind can process. It’s the piece that makes Scrum work, and it’s the piece that’s hardest to teach.
From Project Manager to #NoEstimates — The Bet That Changed Everything
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.
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.
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.
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.”
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.
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a clickable PO Cheat Sheet
This handy Coach Your PO cheat-sheet includes questions to help you define the problem, and links to handy, easy techniques to help you coach your Product Owner
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Enter e-mail to download a checklist to help your PO manage their time
This simple checklist and calendar handout, with a coaching article will help you define the minimum enagement your PO must have with the team
Internal Conference
Checklist
Internal Conference
Checklist
Download a detailed How-To to help measure success for your team
Motivate your team with the right metrics, and the right way to visualize and track them. Marcus presents a detailed How-To document based on his experience at The Bungsu Hospital
Download a detailed How-To to help measure success for your team
Read about Visualization and
TRANSFORM
The way your team works
A moving story of how work at the Bungsu Hospital was transformed by a simple tool that you can use to help your team.
Read about Visualization and
TRANSFORM
The way your team works
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners. Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners. Access three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Overcome Team Resistance and Gain Leadership Buy-In
Discover practical, real-world solutions from leading Agile practitioners.
Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
FREE! Audiobook Chapters: Overcome Team Resistance and Gain Leadership Buy-In
Download three free chapters from 'Tips from the Trenches Scrum Master Edition' and start transforming your Agile practices today!
Your FREE ticket is on the way!
Check your inbox for details.
Email us at
ProductOwnerSummit.org if you have questions
Check Your Inbox For Details
Email us if you have questions:
ProductOwnerSummit@oikosofy.com
Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! 
Mukhtar Kadiri is a PM career coach with 15+ years in project management. He specializes in helping project and program managers land $100–300K roles. He’s been named the #1 PM in Canada. He also has a LinkedIn following of 67K+ professionals. He shares practical insights for FREE on LinkedIn, where he talks about job search, career growth, and thriving as a PM.
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.
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.