If it’s not in the hands of users, it’s not done. I’ve said this countless times in workshops, coaching sessions, and retrospectives, and yet it still bears repeating. Writing code isn’t done. Testing code isn’t done. Demoing something in a meeting isn’t done. Done means that the increment is live in production, gathering telemetry, and delivering real evidence against real goals.
This is a lesson I’ve learned the hard way, both in my own practice and in helping teams across industries. There’s a persistent temptation to celebrate “fake finishes”—to pat ourselves on the back for code that’s merged, or features that pass QA, or stories that look good in a demo. But let’s be honest: none of that matters to your customers. They don’t care about completed tasks, tickets, or internal milestones. They care about what’s available to them right now, in their hands, making a difference.
Here’s what I see time and again:
- Teams equate “code complete” with “done,” and then wonder why stakeholders are frustrated.
- Organisations celebrate the wrong milestones, focusing on internal progress rather than customer impact.
- Valuable learning is delayed because work sits in a queue, waiting for release, rather than being put in front of real users.
Let’s be clear: work that isn’t live isn’t learning. And if it isn’t learning, it isn’t delivering value.
Why “Done” Must Mean “In Production”
When we talk about agility, we’re not just talking about moving faster or ticking boxes. We’re talking about creating a feedback loop between the team and the real world. That loop only closes when the increment is live, and we can see—through telemetry, usage data, and customer feedback—whether we’re actually achieving our goals.
- Evidence over assumptions: Until your work is in production, everything is a hypothesis. Only real usage provides evidence.
- Learning over guessing: Shipping to production lets you learn what works and what doesn’t, so you can adapt quickly.
- Value over vanity: Customers don’t care about your internal process. They care about outcomes they can use.
Shifting from Fake Finishes to Real Value
If your teams are confusing “code complete” with “done,” it’s time to shift the conversation. Here’s how I help teams make that transition:
- Redefine “Done”: Make it explicit that “done” means live in production, not just ready for release.
- Shorten the path to production: Invest in automation, continuous integration, and deployment pipelines so that shipping is routine, not a special event.
- Celebrate real outcomes: Recognise and reward the delivery of value to users, not just the completion of tasks.
- Gather telemetry: Build in measurement from the start, so you know what’s working and what isn’t.
- Close the feedback loop: Use real data to inform your next steps, rather than relying on assumptions or wishful thinking.
My Advice: Make “Done” Mean Something
If you take one thing away from this, let it be this: “done” is not a matter of internal agreement or process compliance. It’s a matter of real-world impact. If your work isn’t live, it isn’t done. If it isn’t gathering evidence, it isn’t learning. And if it isn’t learning, it isn’t delivering value.
So, the next time you’re tempted to celebrate a “done” story that isn’t in production, pause and ask: is this really done? Or are we just fooling ourselves?
If you want to talk about shifting your teams from fake finishes to real value delivery, let’s have that conversation. Because in the end, only live work learns—and only learning delivers value.
