Six Weeks of Waiting, Two Days of Work: Software Delivery as a Flow

A developer picks up a change on a Monday and has it working by Wednesday. It reaches a user six weeks later. In between: four days waiting for code review, a week waiting for a test environment, two weeks in a release train that departs fortnightly, a change advisory board that meets on Thursdays, and a rejected first attempt because the ticket was missing an approval nobody had mentioned.

Ask why delivery is slow and you will usually be told about the two days. Every improvement effort that starts there — better tooling for developers, more people, higher story point velocity — is optimizing two days out of forty-two. And the reason this is so easy to miss is that nobody was idle. Everyone was busy the entire six weeks. It was the work that was waiting, not the people.

That shift — from asking how fast people work to asking how work flows — is what this article is about. It is also the reason the standard delivery metrics measure what they measure, and the reason they mislead when used as targets.

Three words that are not competitors

SDLC, Agile, and DevOps get discussed as if an organization has to choose one. They answer different questions, and reading them as three layers rather than three options makes the rest of this easier.

	The question it answers	What it does not settle
SDLC	What activities must happen between a request and running software — requirements, design, build, test, release, operate	How often they happen, in what size, or who does them
Agile	How work is decided and sized: small increments, feedback from real use, changing direction on evidence	How a finished increment actually reaches production
DevOps	How a change gets to production and stays healthy, and who is responsible once it is there	What to build, or whether it was worth building

The activities in the first row never disappear. A team doing continuous deployment still gathers requirements, still designs, still tests — often several times a day, in pieces small enough that the steps stop looking like phases. What changes is the size and frequency, not the list.

Which is why “we do Agile but releases take six weeks” is a coherent sentence and a common condition. Deciding work in two-week increments does nothing about a release train that departs fortnightly, an environment that takes a week to obtain, or a board that meets on Thursdays. The second and third rows have to be addressed separately, and the flow view is how you find out which of them is actually costing you.

Draw the flow before improving it

The technique for this is value stream mapping, and its published form is specific enough to follow. Gather stakeholders from every part of the process — “the business line, design, testing, QA, operations, and support” — and “break the value stream into 5 to 15 process blocks,” recording in each the activity performed and the team that performs it.

Then measure three things per block. The definitions matter, because two of them look like the same number and are not.

• Lead time — “the time from the point a process accepts a piece of work to the point it hands that work off to the next downstream process.” Wall-clock, including everything.
• Process time — “the time it would take to complete a single item of work if the person performing it had all the necessary information and resources to complete it and could work uninterrupted.” The work itself, with nothing in the way.
• Percent complete and accurate (%C/A) — “the proportion of times that a process receives something from an upstream process that it can use without requiring rework.”

The gap between the first two is the waiting, and it is where the six weeks went. The guidance for reading a finished map says exactly this: look for “processes that have long lead times relative to the process time,” and for blocks “that produce poor quality work, which then require a lot of downstream rework,” visible as a low %C/A in the block downstream.

Two things make this exercise worth the afternoon it costs.

The first is that it surfaces knowledge no individual has. The published pitfall is blunt about it — “in any organization, nobody has a good view into the whole value stream” — which is why the map has to be built by people from across it, and why the accompanying warning is to map the whole stream rather than the part your team owns. A map that starts at “developer picks up ticket” hides the three weeks the request spent before that.

The second is a discipline that is easy to skip and ruins the result: “you always record the state of the processes as they really are on the day the exercise is performed. Make sure that you determine the actual metrics, not what people would like the metrics to be.” Code review takes four days on average, not the four hours it takes when someone is watching. If the map records the intended process, it will confirm that the process is fine.

The reason a map tells you something your existing dashboards cannot is structural. Those dashboards track whether people are occupied — and everyone is. Work waiting in a handoff shows up as nobody’s idle time, so a block with a long lead time and a short process time is a finding no amount of diligent measurement of utilization will surface.

Why the batch gets big, and what to do

Once you can see the queues, the most effective lever is usually not making any block faster. It is making each unit of work smaller, which is the practice of small batches.

Published guidance names the cause of large batches precisely, and it is economic rather than cultural: “one reason work is done in large batches is because of the large fixed cost of handing off changes.” If a release costs two days of coordination regardless of size, then batching a quarter’s work into it is the rational response. Teams are not being careless; they are amortizing a cost you gave them.

That framing points at the actual fix, and it is the same one continuous delivery is for: “a goal of continuous delivery is to change the economics of the software delivery process, making it viable to work in small batches.” Lower the fixed cost of a handoff and small batches stop requiring discipline, because they become the cheaper option.

For sizing the work itself, the recommended test is the INVEST set — each batch should be Independent, Negotiable, Valuable, Estimable, Small, and Testable — with “small” given a concrete meaning: completable “in small increments of time, meaning hours to a couple days.” And a usable upper bound: “any batch of code that takes longer than a week to complete and check is too big.”

Two consequences of that are worth stating plainly, because they are where the practice usually breaks.

One: getting changes into trunk daily — the recommendation is “checking multiple small releasable changes into trunk at least once per day” — means committing code for features that are not finished. That is only safe if the unfinished part is not reachable by users, which is what dark launching and feature toggles are for. Without one of those, “commit daily” and “don’t ship half a feature” are in direct conflict, and teams resolve it with long-lived branches whose merge cost is the thing they were trying to avoid — see Git branch and merge.

Two: batches “aren’t complete until they’re deployed to production and the feedback process has begun to validate the changes.” That definition of done is stricter than most teams use, and it is the one that makes the flow view coherent — work sitting merged but undeployed is inventory, not progress. Making that definition affordable is what test automation is actually for, which is where unit and integration tests earn their keep: not proving correctness in the abstract, but making it cheap to find out.

One caution about language, since the word travels. “Batch” here means the size of a change being delivered. It has nothing to do with batch data processing, where a batch is a bounded set of records. A team can process data in nightly batches and still deliver code in small ones.

Who owns it after it ships

The flow does not end at deployment, and the handoff at that point is where a lot of organizations quietly break their own map. Four questions decide whether the last block works, and they are worth answering explicitly rather than discovering during an incident.

1. Who is called when it breaks at night? If that is never the team that wrote the change, the feedback loop the whole flow depends on is cut at its most informative point.
2. Who decides to roll back? During an incident is the wrong time to find out, and the answer needs to be a role that is actually awake.
3. What does “healthy” mean, in numbers? Without a stated SLO, “is this good enough to ship” is settled by whoever is most anxious, which is a slow and inconsistent way to decide.
4. Which decisions need someone outside the team? Every one of those is a queue. Some are worth it; a release gate that catches real problems earns its wait. One that exists because nobody has revisited it since an incident in 2019 does not, and the map shows you which is which.

Giving a team end-to-end responsibility has a cost that is usually left out of the pitch: it adds operational surface to a group already carrying the domain, and cognitive load is finite. The answer is not to take the responsibility back but to reduce what exercising it requires, which is the whole argument for platform engineering and for an internal developer platform. “You build it, you run it” without a platform underneath is a transfer of burden dressed as empowerment.

And the shape of the map is rarely an accident. Handoffs fall on team boundaries, so a flow with six queues usually reflects an organization with six groups that each own a step — which is Conway’s law read from the delivery side. Some queues cannot be removed without moving a responsibility, and that is a decision above the delivery team.

What the standard metrics measure

The best-known measures of delivery performance come from the DORA research program, and the first thing to correct is the count. Most people know them as “the four keys.” There are currently five, and the shift is documented: the program describes “shifting from the original four keys to the current five-metric model,” including “the move from MTTR to Failed Deployment Recovery Time.” If your dashboard says MTTR, it predates the current definitions. The DORA metrics split into two groups.

Group	Metric	Published definition
Throughput	Change lead time	“The amount of time it takes for a change to go from committed to version control to deployed in production”
	Deployment frequency	“The number of deployments over a given period or the time between deployments”
	Failed deployment recovery time	“The time it takes to recover from a deployment that fails and requires immediate intervention”
Instability	Change fail rate	“The ratio of deployments that require immediate intervention following a deployment”
	Deployment rework rate	“The ratio of deployments that are unplanned but happen as a result of an incident in production”

Note what change lead time does not include: it starts at the commit. The three weeks a request spent before anyone wrote code are outside it. That is a reasonable scope for a delivery metric and a serious gap if you treat it as the time from request to value — which is precisely why the mapping exercise earlier covers the whole stream and this metric covers one segment of it. Both are useful; they are not the same measurement.

The research finding that makes the set worth taking seriously is that the two groups do not trade off: “speed and stability are not tradeoffs. In fact, we see that the metrics are correlated for most teams. Top performers do well across all five metrics, and low performers do poorly.” The published framing of the actual choice, quoted from David Farley, is that “the real trade-off, over long periods of time, is between better software faster and worse software slower.”

Be careful about how far that carries, because it is easy to overclaim. What the finding says is that at the level of teams and over long periods, high speed and high stability go together — so “we are slow because we are careful” does not describe the teams that are actually most stable. What it does not establish is the causal claim that no individual control can reduce risk at the cost of some delay. A specific review step or a specific gate might well do exactly that.

So the finding settles the strategic question and not the local one. Each control still has to be argued on its own terms: what failure it actually prevents, what the queue in front of it costs, and whether an automated check could give the same protection without the wait. The correlation is a reason to stop treating slowness as evidence of diligence, not a reason to remove a step because removing steps is what fast teams do.

One subtlety in how to read them. The same five values work as “leading indicators for organizational performance and employee well-being” and as “lagging indicators for software development and delivery practices.” So they tell you something about where the organization is heading and something about what your practices already did — but they never tell you what to change. That answer comes from the map.

How the metrics get misused

The DORA guidance ships with its own list of pitfalls, which is unusual and worth reading as part of the definition rather than as a footnote. The ones I have seen do the most damage:

• Setting the metric as the goal. The warning is explicit about the mechanism — “ignoring Goodhart’s law and making broad statements like, ‘Every application must deploy multiple times per day by year’s end,’ increases the likelihood that teams will try to game the metrics.” Deployment frequency is trivially gameable by splitting one deployment into five.
• Comparing things that are not comparable. The metrics are “best suited for measuring one application or service at a time,” and comparing “a mobile app and a mainframe system” produces a ranking that means nothing. Blending them into an organization-wide number is the same error at scale.
• Splitting ownership of the metrics. Sharing all five “across development, operations, and release teams fosters collaboration”; assigning throughput to developers and instability to operations “can lead to friction and finger-pointing,” because each group can then improve its number at the other’s expense.
• Competing on them. The stated goal is “to improve your team’s performance over time, not to compete against other teams or organizations.”
• Measuring instead of improving. Building integrations to get precise figures “might not be worth the initial investment” — the recommendation is to start with conversations or a self-assessment. A team six months into a measurement project has improved nothing.
• Using the industry as a shield. Regulated industries are named specifically: compliance requirements are a real constraint and not a reason the status quo cannot change.

One limit beyond that list deserves saying, since it is the one that costs the most. These metrics say nothing about whether the change was worth making. A team can reach elite delivery performance shipping features nobody uses, and the metrics will look excellent throughout. They measure the delivery system, which is what they claim to measure — treating them as a measure of value produced is a substitution nobody in the research made.

Where to start

The published starting sequence is short, and its order is the useful part: set a baseline for the application’s current performance; have a conversation about the friction points, with the map to support it; get the whole team to “commit to making an improvement in the most significant constraint or bottleneck”; turn that into a plan with a leading indicator of its own — “you may decide to measure how long code reviews take”; do the work, with the honest note that “there are very few shortcuts”; then check progress and repeat.

The word carrying the weight is constraint, and it is worth being precise about what improving something other than the constraint does and does not do. It does not raise throughput — the rate at which the system can deliver is set by its narrowest point, which is why a team can adopt three new tools and ship no more per month. It can still shorten how long one change takes: in a serial flow of two hours of work and forty hours of waiting, halving the work time takes a change from forty-two hours to forty-one. A real improvement, a small one, and not a throughput improvement at all.

Two related cautions on reading a map. The longest wait is the first place to look and is not automatically the capacity constraint — a long queue can also come from batching, from a handoff that happens weekly, or from a scheduling rule. And having fixed one thing, the constraint may move somewhere else or may not; that is a question to answer by measuring again rather than by assuming.

So: draw the whole flow with the people who own each part, record what actually happens rather than what is supposed to, decide which target you are optimizing — throughput, the time one change takes, or the rework rate — and fix the one thing that moves it. Then measure again and find out what the flow looks like now.

References: DORA, DORA’s software delivery performance metrics (documentation dated 2026-01-05); DORA, Visibility of work in the value stream; DORA, Working in small batches (documentation dated 2025-12-08). All checked September 2026; Martin Fowler, Talking about platforms.