Software Delivery as a Flow

In this fictional delivery example, a developer starts a change on Monday and has it working by Wednesday. It reaches a user six weeks later. Along the way it waits for code review, a test environment, a fortnightly release train, and a change advisory board. A missing approval also causes rework.

Improving the two days of coding alone leaves the other delays in this example largely untouched. People can remain busy on other tasks while this change waits. To choose an improvement, follow the work and measure where its elapsed time goes; coding time, waiting, and rework can each matter.

That shift from individual activity to the flow of a change explains why delivery metrics are useful. It also explains why a numerical target can mislead when it rewards a count without checking what improved.

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

DORA recommends value stream mapping with stakeholders from business, design, testing, operations, and support. Its suggested starting scale is 5 to 15 process blocks, each showing the activity and responsible team. Use that scale to make the flow readable, then subdivide a block when its internal waits or rework need investigation.

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

• Lead time measures elapsed time from a process accepting work to handing it to the next process, including waiting.
• Process time estimates how long one item would take with the necessary information and resources available and the work uninterrupted.
• Percent complete and accurate (%C/A) measures the share of incoming work usable without rework.

A large lead-time-to-process-time gap is a reason to investigate. Compare the same work and measurement boundary, distinguish calendar from working time, and record how rework is counted. Separate active work from interruptions and waits before attributing the gap to a queue. Low downstream %C/A points to a handoff that needs investigation; unclear acceptance rules or defects may require changes on either side.

The map needs both shared knowledge of the path and evidence of how that path operates.

DORA warns against assuming that one person understands the whole stream. Bring the people who perform and receive the work into the discussion. A map starting at developer pickup leaves out earlier prioritization and approval delays, so state the boundary and include the full request-to-customer path when that is the question.

Record the current process rather than its intended service times. In the fictional example, a four-day review wait should not become four hours merely because an urgent review once finished that quickly. Use observed timings where available, label estimates, and test them against later work.

A utilization dashboard alone does not show how long an item waited while people worked on other tasks. A flow dashboard can: acceptance, start, pause, and completion timestamps, together with work in progress and item age, expose those intervals. DORA recommends ongoing visual displays alongside a map; the map adds shared interpretation of the steps and their relationships.

Why the batch gets big, and what to do

Once the queues are visible, consider whether small batches would shorten feedback or reduce work waiting for a shared release. Compare that option with the constraint the map actually revealed.

DORA identifies fixed handoff cost as one reason batches grow. If each release requires two days of coordination regardless of size, combining changes spreads that cost over more work. It also delays feedback and can increase recovery risk. Those costs belong in the decision; amortizing coordination alone does not establish the best batch size.

continuous delivery aims to make small changes economical by reducing repeated delivery work. Lower handoff costs remove one barrier, but teams still need the design skill to divide work and the discipline to test, integrate, and remove temporary release controls.

DORA applies INVEST to work batches: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Its guidance recommends increments of hours to a couple of days and treats more than a week to complete and check a code batch as too large. These are sizing recommendations for feedback, including validation time, rather than a measure of how fast someone types.

Integration frequency and the point at which feedback begins connect batch size to the rest of the flow.

DORA recommends integrating small releasable changes into trunk at least daily, even when a larger feature is still in progress. A completed, independently usable slice can be released to users. A path that does not yet meet its contract needs isolation, for example through dark launching, feature toggles, or branch by abstraction. Hiding a UI element does not establish that initialization, migrations, or shared dependencies leave existing behavior intact: test the production and fallback paths and their compatibility. These techniques help avoid long-lived branches; Git branch and merge explains the histories those branches eventually combine.

In DORA’s small-batch approach, work is complete when it has reached production and feedback has begun. Merged but undeployed work remains inventory awaiting that evidence. Earlier checks still provide useful feedback: unit and integration tests make relevant behaviors cheaper to verify before rollout. Production observation then tests assumptions that those earlier checks could not settle.

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 responds when it breaks at night? Agree on the initial responder and escalation path. An SRE or operations team can respond first while developers retain responsibility for fixes and learn through incident reviews and operational work. The feedback gap occurs when that evidence never returns to development, not simply when another team carries the pager.
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? Record who decides, the response expectation, and the observed wait. An external decision may be immediate; an internal one may queue. A release gate should be assessed through the risk it controls and the delay it introduces, rather than its location alone. Use the map and incident evidence to determine whether a gate remains justified.

End-to-end responsibility adds work, and cognitive load is finite. platform engineering and an internal developer platform can reduce repeated operational effort, but neither is a prerequisite for responsible ownership. Managed services, simpler designs, training, staffing, and a narrower supported scope may be appropriate. Google’s SRE engagement model describes explicit collaboration between operations and developers; Evan Bottcher’s platform discussion explains how shared capabilities reduce coordination. Choose support that makes the operating commitment sustainable.

Compare the workflow with team and authority boundaries. Six queues do not imply six teams: one team can have several queues, and several teams can use one decision route. Conway’s law motivates examining how communication structures shape delivery, but the actual map must show who owns each step and why work waits. Some delays need a responsibility change; others need capacity, scheduling, or a clearer decision rule.

What the standard metrics measure

DORA’s January 2026 guidance defines five DORA metrics, grouped below. Its history explains that failed deployment recovery time replaced the broader MTTR measure by focusing on recovery from failed production changes. An MTTR label alone does not reveal a dashboard’s age or event population. If it is used as a substitute for the DORA measure, inspect which failures it counts; an all-cause operational recovery metric can coexist with the narrower delivery metric.

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.

DORA observes that high-performing teams tend to combine speed and stability over time. Its discussion also cites David Farley’s long-term argument that better engineering can improve delivery speed and software quality. This sustained team-level relationship challenges the assumption that being slow proves diligence, but does not show that every local control is free of delay: a review or gate can reduce a particular risk while adding time.

Evaluate each control through the failure it prevents, the cost of its queue, and whether automation can provide the same protection without the wait. The long-term finding gives a strategic reason to improve engineering; it does not justify removing a step merely because fast teams have fewer steps. A local change still needs evidence about both delay and risk.

As outcomes of delivery practices, these measures also signal associations with later organizational performance and employee well-being in DORA’s guidance. They indicate where to investigate; a map, incident evidence, and conversations about the work help decide what to change.

How the metrics get misused

DORA’s guidance describes several ways measurement can distort delivery decisions. The following examples show why definitions and context belong beside the numbers.

• Setting the metric as the goal. A quota for deployments can reward repeated no-op deployments or counting steps of one rollout as separate deployments. That differs from dividing work into independently validated small changes, which can shorten feedback and reduce the scope of a failure. Read frequency alongside batch size, feedback time, and instability.
• Comparing unlike contexts. DORA recommends application- or service-level measurement. A mobile app and a mainframe can have different release constraints, so a ranking or blended average can obscure more than it reveals. For a fleet report, state the population and weighting and show the distribution.
• Splitting ownership. Development, operations, and release teams need a shared view of all five measures. Assigning throughput to one group and instability to another can reward local improvements that impose costs downstream.
• Competing on the numbers. Use comparable history to guide the service’s improvement rather than treating teams with different contexts as contestants.
• Measuring instead of improving. DORA suggests conversations or a self-assessment when precise integrations would delay useful action. Instrumentation can enable improvement, but the time spent building it is not evidence that delivery improved. Check which decisions and outcomes it changed.
• 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.

Delivery performance does not establish that a feature met a user need. A team can deliver reliably and quickly while building things nobody uses. Pair delivery measures with evidence about adoption, task success, or the business outcome the change was intended to support.

Where to start

DORA recommends establishing a baseline, discussing friction across the teams responsible for the service, and agreeing on a significant constraint to improve. Plan a concrete change and a relevant local signal, such as review turnaround time. Carry out the change, compare results, and repeat rather than treating the initial map as a permanent diagnosis.

Distinguish capacity from useful completed work. In a simple serial model with fixed demand, work mix, quality, and rework, and a bottleneck kept supplied and unblocked, speeding a non-bottleneck step does not raise the capacity ceiling. Real improvements elsewhere can reduce the bottleneck’s rework or idle time and increase useful throughput. For example, if a stage checks ten items per day but upstream defects make half fail, preventing those defects can raise accepted output from five to ten without increasing its checking capacity. Individual lead time is another outcome: with waiting fixed at forty hours, reducing active work from two hours to one reduces elapsed time from forty-two to forty-one. These are illustrative models; measure which conditions change in the actual flow.

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 — Software delivery performance metrics (January 5, 2026)
• DORA — A history of software delivery metrics
• DORA — Visibility of work in the value stream
• DORA — Value stream mapping for software delivery
• DORA — Working in small batches (December 8, 2025)
• Pete Hodgson — Feature Toggles
• Google — SRE Engagement Model
• Evan Bottcher — What I Talk About When I Talk About Platforms