We recently built an automated email notification. If a particular process ran over 24 hours, the system would email the member of the public to let them know. Simple, well-defined, useful.
It took two days to develop. QA tested it the same week. Everything passed against the acceptance criteria.
It took six weeks to get it into production.
The feature was done. Tested. Validated. But before it could go live, the product owner wanted to demo it to stakeholders. Which sounds reasonable, until you try to get five busy people into a room at the same time.
Meetings got scheduled. Meetings got postponed. The feature sat in staging, waiting. On more than one occasion we had to pull it off staging to make room for other work that needed demoing, then put it back when the meeting was rescheduled.
People would message asking why they couldn’t find it on staging. “Where is it? When can I view it?”
What should have been a deployment became a management task. I spent more time coordinating the demo than we spent building the thing.
Here’s what nobody talks about when work sits unreleased for weeks: the developer who built it loses context.
By the time our demo finally happened, the developer felt less confident explaining what he’d built and why certain decisions were made. He had to go back and relearn his own work. Not because it was complex, but because six weeks is a long time when you’ve moved on to three other things since.
The original copy for the email had been written seven or eight weeks earlier. By the time stakeholders reviewed it, they wanted changes, not because the copy was wrong, but because their thinking had shifted. The context that informed those words had evolved, and the feature hadn’t had a chance to keep up.
That’s the real cost. Not just delayed delivery, but the slow erosion of clarity that existed when the work was fresh.
The feedback from the demo wasn’t from users. It couldn’t be. Nobody had used the feature yet. It was stakeholders in a meeting room, imagining how it might work rather than responding to how it actually works.
Because people had weeks to think about it without seeing it in production, they started changing their minds. New ideas crept in. Adjustments to something that hadn’t even been released. The product owner felt compelled to schedule a second demo to show the copy changes, which in my opinion was completely unnecessary.
This is what happens when you don’t deliver working software frequently. The feedback loop breaks. Instead of real-world data informing improvements, you get hypothetical opinions delaying a launch.
While the feature waited for sign-off, the codebase moved on. main kept changing. Other features got merged. The staging branch needed constant attention, merging main back in, resolving conflicts, re-testing to make sure nothing had broken.
This isn’t theoretical. We’ve had situations where two features were developed independently, both touching the same process, and both got approved for release in quick succession after their respective demos. Merging them back-to-back caused undesired effects that our regression testing didn’t catch, precisely because the features had been developed against a version of the codebase that no longer existed.
Long-lived branches are a well-documented anti-pattern for exactly this reason. The longer code sits unmerged, the more it diverges from reality.
The irony is that the demo process exists to reduce risk. But by delaying deployment, it creates the very risk it’s trying to prevent.
In any reasonable agile workflow, the process is straightforward. You gather requirements, the product owner writes meaningful user stories with clear acceptance criteria, development happens, QA validates against that criteria, and the feature goes to production. Real-world feedback then informs continuous improvement.
The first four steps work. We’re good at those. The problem is the gap between QA passing and the feature going live, in the unofficial step where the product owner wants a sign-off meeting, and then a stakeholder wants their own sign-off meeting, and suddenly there are two layers of approval in a process that was supposed to be lean.
I’ve raised this. If QA has validated the work against acceptance criteria written by the product owner, then a secondary demo is redundant. The acceptance criteria is the agreement. That’s what it’s for.
But changing process is harder than changing code. People are attached to the visibility that demos provide. Product owners want stakeholders to see the work. Stakeholders want to feel involved. None of that is wrong in principle. It’s just happening at the wrong point in the cycle.
The real casualty isn’t efficiency. It’s morale.
Developers build something, see it pass testing, and then watch it sit in limbo for weeks. The satisfaction of shipping, of seeing your work in the hands of real users, gets replaced by calendar management and staging environment logistics.
Lead time for changes is one of the four key metrics in software delivery performance for a reason. It’s not just about speed. It’s about the health of the team and the process.
When a two-day build takes six weeks to release, something has gone wrong. Not with the development. Not with the testing.
With everything that happens after the work is done.