
Sign up to save your podcasts
Or


AI coding tools made your developers faster. So why isn't anything reaching customers sooner? In this episode, Lance Dacy tracks down where that speed actually went, and why most leadership dashboards can't see it.
It starts in a staff meeting. A VP is beaming over a chart that's way up, until the product leader asks how much faster the team is shipping. Not one day.
If your teams are producing more than ever and delivery hasn't budged, this one is for you. The fix is simple, and it's going to feel backwards.
A coach is working with four teams. Every Daily Scrum stays inside the time box. Every retrospective produces action items. Sprint reviews are well attended, and people actually make decisions in them.
By every measure that coach was hired to improve, the teams are thriving. They've also missed every delivery date this quarter.
So the coach does what the job seems to ask for: a fresh retro format, a framework refresher, tighter facilitation. The events get healthier. The dates keep slipping.
In the final episode of Q3, Lance Dacy digs into what the latest State of Agile survey says about coaches, a role now being pulled in several directions at once, and what it can't say about which of those directions has a future. He brings in DORA's 2025 research on AI and delivery, and a 2009 book that saw this problem coming long before AI sped everything up.
His argument: the coach doesn't need a better checklist. The coach needs to look somewhere the checklist never points.
If your events look great and your dates don't, this is the episode to start with.
A team finished an AI course feeling great. Clean prompts, certificates, real progress from where they started six weeks earlier.
Two weeks later, the model handed one of them an answer that was confident, specific, and completely wrong. It cited a number that didn't exist. It went into a document, and the document went to a client before anyone caught it.
When Lance asked how it slipped through, the answer was simple: nobody questioned it. It looked fine.
That's the gap this episode is about: the space between using an AI tool and knowing when not to trust it. Lance Dacy makes the case that most AI training is quietly solving the wrong problem. It builds fluency, which is getting cheaper every month, while skipping the skill that's actually scarce and getting more valuable. He digs into why a certificate on the wall can leave a team less safe, and what a program has to do differently before the training ever changes what people do at their desks.
If you're spending money teaching your team to use AI, this is the question to sit with first.
A product manager sits down for backlog refinement. A year ago that meant estimating, clarifying, dragging cards and tidying columns nobody reads. Today she describes a feature out loud and has three working prototypes before lunch.
So the posts go up again. Product management is finished. Somebody go update the org chart.
The administrative half of the role really is evaporating, and most of it should. Nobody grew up dreaming of grooming a backlog. The trouble is that the busy work is what filled the calendar, and a full calendar looked like a job.
In this episode, Lance Dacy argues the replacement case makes one specific mistake: it treats the tasks and the role as the same thing. The tasks were only ever how the role showed up when building software was slow. Take the slowness away and what is left is the part that was always the job, and it is now more expensive to get wrong, not less.
He walks one real customer request all the way through to show exactly where the judgment calls land, and closes with a one-week exercise that makes the change visible on your own calendar.
Progress over perfection.
Somebody on your team opens a ticket. It says "add a way for customers to export their data." One line. How hard could that be?
By lunch there is a working export button, passing tests, and a pull request waiting for review. It is fast, it is confident, and it is the wrong feature.
Here is the uncomfortable part: nothing failed. The code compiled. The tests passed. The reviewer approved it, because review checks the code against the ticket. Nobody was checking the ticket against reality.
Previously, a vague requirement like that was survivable, and not because anyone was careful. Because building was slow enough to catch it. That filter is gone.
So the expensive part of the work has moved. It used to be building. Now it is deciding, and almost nobody has reorganized around that.
In this episode, Lance Dacy argues that AI did not create your requirements problem. It removed the delay that was hiding it. He also shares the one-page approach he now uses to force the decision out into the open before anyone writes a line of code, including the one field almost every team skips.
Progress over perfection.
The AI demo works on the first try. Someone leans over and says "this changes everything." There's applause, a follow-up meeting goes on the calendar, and then everyone leaves. Six months later, nobody can tell you what happened to the tool. Lance Dacy calls that place pilot purgatory, and in this episode he digs into why AI pilots stall after the demo.
His argument: pilots almost never die on the model. They die on ownership, the part nobody was assigned once the applause stopped. Lance names the gap in five loops, who runs it, who owns the outcome, who can pause or kill it, who gets paged when it breaks, and how you'll know it worked. None of the five is about the model. Every one is about people making a decision out loud. He also makes the case for designing a pilot backward from production instead of forward from the demo, because a pilot built to survive operations is less impressive in the room and far more likely to still be running in September.
Along the way he pulls in the data with the caveats it deserves: Deloitte's State of AI in the Enterprise 2026 (access up 50% in a year while daily use stays flat, and only a quarter of organizations shipping 40% or more of their experiments) and KPMG's Q2 2026 AI Pulse (a third of leaders overriding AI outputs with no formal criteria). The episode ends with the week's tool, the Pilot-to-Production Readiness Checklist, and a test you can run on any pilot this week: name who runs it in production, then name who can kill it. If either answer takes more than a few seconds, you've found the work.
Subscribe to the Big Agile newsletter at https://big-agile.com/newsletter and explore workshops and consulting at https://big-agile.com/events.
Even the dashboards have a dashboard now. Somewhere in your organization a team added a batch of new ones this quarter, and meanwhile a monitor in IT ops has been frozen on a session-timeout screen since March that nobody has noticed. That contradiction is the whole episode.
We've never had more visibility into how we build software, and the people running those systems say delivery keeps getting harder, not easier. Lance Dacy calls this the visibility paradox, and he walks through why both things are true at once. Drawing on Digital.ai's 18th State of Agile Report, two years of DORA research on AI and delivery stability, DORA's 2026 "instability tax," and Mark Graban's work on signal versus noise, he makes a simple case: a metric only earns its place if it changes a decision, and AI has removed the cost that used to kill the weak ones.
The practical core is a tool Lance calls the dashboard-to-decision audit: one record per metric, five lines each. Name it, name who actually reads it, name the last decision it changed, ask what breaks if it disappeared tonight, then keep it, cut it, or merge it. He runs it live on the executive summary dashboard, makes the case that this is leadership work rather than team housekeeping, and closes with a challenge you can run before your next review.
Subscribe to the Big Agile newsletter at https://big-agile.com/newsletter and explore workshops and consulting at https://big-agile.com/events.
Your team shipped more code last quarter than in any previous quarter, and delivery is slower than it was last spring. Both things are true, and they are related.
Nobody stopped working. The work stopped moving. It is sitting in the review column, and it has been sitting there long enough that nobody on the team remarks on it anymore.
In this episode Lance Dacy works through what happens when generation gets cheap and verification does not. GitClear's 2026 research puts roughly a quarter of detected commits as AI-assisted, with two-week churn running about 15% above its 2023 level. The 2025 Stack Overflow survey found that the number one developer frustration, at 66%, is output that is almost right but not quite, with 45% saying debugging AI-generated code takes longer. And DORA reversed part of its 2024 finding: throughput flipped positive in 2025, while delivery instability did not improve.
Lance's argument is that review is not a step in your process, it is a queue, and queues behave in ways that make this worse than it looks. Drawing on Donald Reinertsen's 2009 book The Principles of Product Development Flow, he covers why this inventory is invisible on every report you own, why queue size spikes rather than climbs as you approach full capacity, and what rate matching means when your fast sender is an AI and your slow receiver is a human reviewer.
Then the practical part: four numbers that tell you how many AI-assisted items your team can genuinely verify in a week, worked through with a real example, plus where to put the limit. The answer is counterintuitive. You cap generation to protect verification, and you set that cap light rather than tight.
Closing thought: verification is not overhead added to the real work. It is the work. The scarce person on your team is no longer the one who can produce a plausible change, it is the one who can look at a plausible change and tell you whether it is right.
Your homework is two numbers. What you generated last week, and what you can actually review. If they are not close, you do not have a productivity story. You have a queue.
Sources referenced: GitClear 2026 code quality research, Stack Overflow 2025 Developer Survey, DORA 2024 and 2025 reports, Donald Reinertsen, The Principles of Product Development Flow (2009).
Weekly newsletter: https://big-agile.com/newsletter
Workshops and consulting: https://big-agile.com/events
84% of developers use AI. 46% don't trust it. Both can be true, because using a tool and handing it work are two different relationships. Lance Dacy breaks down a five-rung delegation ladder and the one question that decides which rung a task belongs on.
"A human will remain in the loop." It's in most AI policies, and it usually protects nothing. Lance Dacy explains why AI oversight fails at agent speed, the four postures every decision already falls into, and how to test whether your named human can actually stop the line.
From the publisher's feed