Why “Done” Only Counts When It’s Live: Moving Beyond Fake Finishes to Real Value in Software Delivery

TL;DR

Work is only truly done when it is live in production and delivering value to users, not just when code is written, tested, or demoed. Teams often mistake internal milestones for real progress, which delays learning and frustrates stakeholders; real feedback and value come only from live usage and telemetry. Development managers should redefine “done” as live in production, invest in automation to shorten release cycles, and focus on measuring and celebrating actual user impact.

7 May 2025
Written by Martin Hinshelwood
3 minute read
Subscribe

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:

  1. Redefine “Done”: Make it explicit that “done” means live in production, not just ready for release.
  2. Shorten the path to production: Invest in automation, continuous integration, and deployment pipelines so that shipping is routine, not a special event.
  3. Celebrate real outcomes: Recognise and reward the delivery of value to users, not just the completion of tasks.
  4. Gather telemetry: Build in measurement from the start, so you know what’s working and what isn’t.
  5. 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.

Subscribe

What to read next

Video Product Development Engineering Excellence

Why Your Definition of Done Is the Secret Weapon for Real Business Impact and Agile Growth

Transform your definition of done into a strategic advantage, deliver real value, reduce risk, and drive business impact with every sprint.

Watch video
Video Product Development Engineering Excellence

Why Your Definition of Done Is the Secret Weapon Your Team Needs to Win

Unlock your team's true potential, discover why a powerful definition of done drives real business impact, customer value, and lasting …

Watch video
Video Product Development Engineering Excellence

Why Your Definition of “Done” Is Holding Back Quality, Agility, and Trust, And How to Raise the Bar

Is your team’s “done” really done? Discover how a clear, objective definition of done boosts quality, agility, and trust in product …

Watch video
Article Product Development Scrum

Delivery is the only Measure of Progress in Scrum

Scrum teams must deliver working software to real users every Sprint; true progress is measured by delivery to production, not just by …

Read article
Video Engineering Excellence Scrum

Stop Paying the Hidden Costs of Weak Delivery: Why a Strong Definition of Done Transforms Your Team’s Results

Stop paying the hidden costs of weak delivery. Discover how a strong, shared definition of done builds trust, quality, and real agility in …

Watch video
Video Product Development Engineering Excellence

Bridging the Gap: Understanding the True Meaning of "Done" in Agile Teams

Explores how Agile teams can clarify and align on the true meaning of "done" to ensure quality, reduce rework, and meet leadership …

Watch video