Managing Flow Under Variability

Most elapsed time is not visible as work

A Work Order may be active in an administrative sense while no one can advance it. It can wait for a decision, an environment, a specialist, a supplier, an interface change, test evidence, a release window, or user feedback. It may also appear to move while accumulating unresolved assumptions that return later as rework. A status report built around tasks completed can miss all of these conditions.

Flow time is the elapsed time a work item spends inside a declared boundary. Work in progress is the population of items that have entered that boundary but have not left it. Throughput is the rate at which items leave. Little's Law relates their long-run averages: average work in progress equals average throughput multiplied by average flow time. The relationship is powerful because it forces the boundary and the counting rule into view. It is limited for the same reason: it is an identity under stated averaging conditions, not proof that lowering one variable will independently improve another.A03

Suppose a Production Line counts a Work Order as started when authorized and complete only when the resulting capability is operating with acceptance evidence. That boundary exposes decision waits and release waits that a coding-only boundary would exclude. If the line instead starts counting at the first code change and stops at merge, it answers a different question. Neither measure is inherently correct. A measure becomes useful when its boundary matches the decision leaders need to make.

Software makes boundary discipline especially important. Items differ in size. Some are abandoned after discovery. Some split or merge. Rework can appear as a new item or remain hidden inside the original one. Expedites preempt ordinary work. Priority classes experience different waits. The mix changes over time. Under these conditions, an average can conceal an aging tail and the identity can be estimated badly even when the arithmetic is correct.

The practical implication is not to discard flow measures. It is to ask what population they describe. A leader should know which work classes are included, when the clock starts and stops, how blocked time and rework are represented, and whether the observation window includes a major shift in demand or capacity. If those answers are missing, a trend line may reflect a changed counting rule rather than a changed system.

This is also why activity is a weak substitute for flow. A specialist can be fully occupied while the work requiring that specialist waits longer each week. A team can close many small items while a consequential migration ages. A release function can meet its local service target while upstream teams accumulate completed but unreleased changes. Local busyness says little about the movement of the outcome.

The management object is therefore not a person-hour. It is the relationship among demand, viable capacity, waiting, feedback, and consequence across the Production Line. That relationship gives leaders several levers, but none is safe to use alone.

Why the last increment of capacity is different

When variable demand meets finite capacity, queues form. This is not a moral failure and does not imply that people are inefficient. A queue may be an economically justified buffer, a deliberate risk control, or the unavoidable result of stochastic arrivals. The problem begins when leaders treat the queue as free or assume that a small increase in utilization has only a small effect on delay.

Queueing theory provides a conditional explanation. In Kingman's heavy-traffic result, expected waiting becomes increasingly sensitive to variability and residual capacity as load approaches effective service capacity. The model is asymptotic and single-server. A software organization is neither a single queue nor a collection of interchangeable servers. Yet the mechanism remains useful: when little capacity remains to absorb variation, an arrival that is larger, earlier, or more specialized than expected has fewer viable paths around the existing work.A04

Figure F09.1 makes that mechanism visible through a reference M/G/1 queue. It assumes Poisson arrivals, one server, first-come/first-served processing, normalized mean service time of 1, and three service-time variability conditions. These assumptions do not describe an observed software team. They produce an auditable comparison of how modeled queue wait changes as utilization rises.C09-B01

Figure F09.1 — Modeled queue wait steepens near full utilization. At 80% utilization, modeled mean queue wait is 2, 4, or 10 times mean service time across the three variability assumptions. At 95%, it is 9.5, 19, or 47.5 times mean service time. Every value is a reference-model calculation, not observed team data and not a staffing target.

Values are multiples of mean service time. Source: editorial calculation from the Pollaczek–Khinchine M/G/1 mean-value relation, audited against C09-B01, with mechanism constrained by A03 and A04. Reference queue model; not observed software-team data.

The important feature is the curve, not any chosen point. Each modeled queue wait at 95% utilization is approximately 2.11 times its 90% value. Higher service-time variability raises the whole curve. The calculation demonstrates sensitivity under its assumptions. It does not establish that 80% is safe, 90% is reckless, or a team should reserve a fixed percentage of its time.

Real software flow is more complex. Skills are routed rather than interchangeable. A security reviewer cannot necessarily substitute for a database specialist. Work can be blocked outside the system boundary. Failed work returns. Teams collaborate rather than serve items independently. Priority and preemption alter the order. Arrival and completion rates change after incidents, reorganizations, product launches, or policy shifts. These facts weaken literal prediction, but they strengthen the managerial question: where can variation be absorbed, and what happens when it cannot?

Capacity margin is one answer. It may take the form of uncommitted time in a team, reserved capability in a Work Center, a flexible environment, cross-skilled colleagues, automation that shortens recovery, or a buffer before a hard deadline. Margin is not necessarily idle capacity. It is the ability to respond without displacing every existing commitment.

The right amount depends on consequence and economics. A scarce specialist may reasonably operate near full utilization if demand is predictable, waiting is cheap, and viable alternatives exist. The same utilization may be dangerous when the specialist controls a high-consequence release, incidents arrive unpredictably, or every delay blocks several Production Lines. Leaders should compare the cost of margin with the cost of waiting, fragility, preemption, and recovery. Chapter 17 will own the wider allocation economics; here the point is narrower: utilization cannot be interpreted apart from variability and the consequence of delay.

Open figure

Under this single-server reference model, queue wait steepens as utilization approaches one, and service-time variability raises the curve. Values are multiples of mean service time. The figure is a conditional model, not observed software-team data and not a target.

Work in progress is a policy choice

Work in progress often grows one reasonable decision at a time. A team starts a second item while the first waits for feedback. A leader authorizes another initiative to avoid leaving people unoccupied. A specialist accepts parallel requests because rejecting demand is politically difficult. An expedite interrupts both. Each local choice can make sense while the combined system becomes slower and harder to predict.

Limiting work in progress changes this dynamic by making an admission decision explicit. When the limit is reached, the question changes from “What else can we start?” to “What must finish, unblock, split, stop, or leave the boundary before something enters?” The limit can expose hidden dependencies, overlarge items, missing authority, or a Work Center that has become a shared queue.

But a limit is not a law of nature. A four-year study of more than 8,000 work items across five Kanban teams found lower work in progress associated with shorter lead time. It also found an association between lower work in progress and lower measured productivity, contrary to a common claim that reducing work in progress improves every outcome. Quality could not be evaluated, the productivity measure had limitations, and the observational design did not establish causality.C09-A01

That countercase changes the recommendation. Leaders should not search for the universal correct limit. They should state what harm the current work in progress appears to create, choose a bounded intervention, and observe several outcomes. A lower limit may reduce waiting and context switching while starving a specialist, delaying useful discovery, or reducing measured throughput. A higher limit may improve access to ready work while allowing old items and coordination load to accumulate.

The evidence base itself demands restraint. A systematic mapping study screened 382 Kanban records from 2006 through 2016 and identified 23 relevant primary studies. The authors characterized much of the literature as descriptive, context-heavy, anecdotal, or influenced by consultancy reporting. The count describes the maturity of the research base; it is not an effect estimate.C09-A02

A work-in-progress policy should therefore contain more than a number. It needs a system boundary, included work classes, a reason for the chosen threshold, an owner, an observation window, a treatment for blocked work, and a rule for emergencies. It also needs a reversal condition. If aged work improves but reliability declines, or throughput collapses because a scarce capability is starved, the policy should be changed rather than defended as doctrine.

Work visibility is part of the intervention. An invisible queue cannot be limited coherently. Work waiting in personal messages, approval inboxes, supplier systems, spreadsheets, and informal commitments belongs in the flow if it consumes capacity or delays the outcome. Making it visible may initially make performance look worse. That is not deterioration; it may be the first honest description of the system.

Different work classes may need different admission rules. A production incident, a regulatory deadline, routine maintenance, product discovery, and a planned capability change do not carry the same consequence or tolerate the same wait. Placing them in one undifferentiated queue can cause urgent work to wait behind ordinary demand. Giving each an unrestricted priority path creates the opposite problem: every sponsor has an incentive to call work exceptional.

Explicit service classes make the trade-off inspectable. A class states why work may receive different treatment, who authorizes that treatment, which capacity is reserved, and what happens to displaced work. The class should not become a hidden portfolio ranking. It is a flow policy for already authorized work, bounded by operational or temporal need. A fixed-date obligation may require protection without being more valuable in every other sense; an incident may require immediate response while producing no new product capability.

The policy also needs an expiry. Work that entered under urgent conditions should return to normal handling when those conditions pass. Otherwise, exceptional work accumulates as a permanent privileged queue. Reviewing the share, recurrence, and recovery load of each class can reveal upstream failure: preventable incidents, late decisions, unstable priorities, or demand that repeatedly bypasses normal authorization.

This is one reason a single average is insufficient for a local flow experiment. An improved mean can hide a deteriorating tail or a class that receives better service by transferring delay to another. Leaders do not need a large enterprise scorecard to see this. They need distributions or age views that preserve the work classes relevant to the intervention and a record of who bore the displacement.

Open figure

Exceptional treatment is a displacement decision with an owner, expiry, and recovery cost.

Smaller batches shorten some feedback loops

A batch is a set of changes moved or decided together. Batches appear in analysis, implementation, integration, testing, authorization, migration, and release. They are not inherently wasteful. Grouping can reduce transaction cost, preserve conceptual coherence, create enough statistical power for an experiment, or satisfy a coordinated safety or certification obligation.

Large batches become dangerous when they delay evidence and couple unrelated uncertainty. If several changes must be completed before any can be tested in a representative environment, the earliest change waits for the last. If the batch fails, diagnosis must search across a wider change surface. If user feedback arrives only after the whole release, incorrect assumptions survive longer. Smaller independently testable increments can shorten those loops.

The BBC Worldwide case illustrates the possible mechanism, not a single-lever effect. Visual management, smaller batches, team problem-solving, and statistical process control changed together. The public record reports improved flow and quality measures over twelve months, but the design cannot isolate smaller batches as the cause.C09-A03 An Ericsson case similarly reported perceived changes in bottlenecks, unnecessary work, and rework after a broad move from plan-driven to incremental practices. Its 33 interviews and company measures provide useful triangulation, while the single-site, retrospective, bundled intervention limits transfer.C09-A04

Facebook and OANDA provide a sharper boundary. A comparative case described two independently developed continuous-deployment environments over seven and five years. Small deployable increments depended on automated testing and deployment, release discipline, monitoring, and sustained engineering investment. The same record described adverse conditions: premature release, local optimization, cumulative resource use, duplicate solutions, variable quality, and pressure on developers. The authors could not establish root causes, and the two firms are not representative of safety-critical or high-ceremony settings.C09-A05

The lesson is not “deploy continuously.” It is that reducing batch size moves work. It can move effort into automation, interface design, environment management, observability, review, and operational response. If those capabilities are missing, smaller releases may merely create more frequent uncertainty. A Production Line should count that enabling work as part of the intervention rather than treating it as overhead outside the calculation.

Some work should remain coordinated. A data migration may need a coherent cutover and recovery plan. A change to a tightly coupled protocol may require simultaneous updates. A regulated submission may need a complete evidence package. An experiment may need sufficient exposure before interpretation. The decision is not small versus large in the abstract. It is whether the batch preserves necessary coherence or merely postpones feedback.

A constraint is a system property

Work tends to accumulate before the capability that currently limits completion. That constraint may be a scarce skill, a physical test environment, a policy decision, a supplier response, an integration surface, or incomplete evidence. It may also be an artifact of bad state data: work appears to wait at testing when the real delay is an upstream decision that prevented a valid test from beginning.

Treating the busiest team as the constraint can therefore be misleading. A highly utilized Work Center may produce faster than the downstream line can absorb. A quiet approval role may create a long queue because it works in irregular windows. A shared environment may look available while configuration and access delays consume most of the elapsed time. The constraint is the condition limiting the relevant outcome, not the place with the most visible activity.

Once a plausible constraint is identified, upstream release should be subordinated to what the whole line can use. This does not mean centralizing every decision or forcing all work through one sequence. It means avoiding the production of inventory that cannot advance. Leaders can then test whether to change policy, pool or cross-skill scarce capability, reserve capacity by service class, simplify the interface, improve the environment, or add capacity.

Each response has a transfer cost. Pooling may improve flexibility but weaken domain continuity. Cross-skilling takes time and may not be viable for deeply specialized or independently assured work. Additional capacity may shift the constraint without improving total flow. Removing a control may reduce waiting while violating a lifecycle or risk obligation. ISO/IEC/IEEE lifecycle and risk-management standards support preserving those obligations; they do not prove that any particular control design improves flow.S01S17

Buffers help when they are designed for a named uncertainty. A capacity buffer absorbs variable demand. A time buffer protects a consequential date. A work buffer keeps a costly capability supplied. An inventory buffer in software may be partially completed or ready work, but it can become stale, hide demand, and create integration risk. The purpose and depletion rule matter more than the label.

An expedite is a special buffer decision. It consumes reserved capacity or displaces ordinary work. The request may be justified by safety, legal obligation, operational failure, or expiring opportunity. It is never free speed. A viable expedite policy names who can authorize displacement, which work is displaced, when the class expires, and how normal capacity recovers. If everything can become urgent, the expedite class is simply the ungoverned intake system under another name.

Feedback has a latency and a cost

Software work advances through feedback: a test reveals behavior, a reviewer exposes a risk, an environment reveals an integration assumption, an operator detects failure, or a user response changes the interpretation of value. Faster feedback can reduce the amount of work built on a wrong assumption. It can also create noise, interruption, surveillance, false alarms, or premature decisions.

Feedback latency begins when the relevant uncertainty is created and ends when evidence reaches an actor who can respond. A test that runs immediately but is ignored for a week has long decision latency. Monitoring that produces thousands of unactionable alerts may shorten detection while lengthening interpretation. A user experiment can return quickly but still lack the sample or context needed for a consequential decision.

The appropriate loop depends on consequence. A formatting defect may justify an automated check near creation. A safety claim may require independent review and representative evidence even when that takes longer. A staged exposure can shorten operational learning while limiting harm. A high-consequence migration may deliberately slow the decision until recovery evidence is credible. Faster is useful only when the evidence remains fit for the decision.

This is where human burden belongs in the flow model. On-call interruption, review overload, alert fatigue, repeated context switching, and pressure to release can improve a local timing measure while degrading the capability that produces future work. The current DORA research framework separates delivery throughput from instability and publishes its instrument and errata, reinforcing the need to keep outcomes distinct. Its cross-sectional self-report design does not prove a queueing mechanism or an intervention effect.R02

The same separation applies to value. Shorter flow time can make learning and response possible; it does not establish that the work should have been done. A Production Line can efficiently produce low-value capability. Chapter 17 will address portfolio choice. Chapter 9 asks only whether authorized work moves with enough visibility and response capacity for leaders to learn and intervene.

Diagnose, test, and retain—or reverse

The interacting levers can be organized as a decision framework. Figure F09.2 begins with an observed pattern, requires a mechanism test, proposes a candidate intervention, names balanced measures, and ends with a retain, reverse, or reframe decision. It is a diagnostic framework, not an automated prescription.

Before choosing a branch, define five things: the outcome, the system boundary, the work classes, the observation window, and the completeness of the data. Without them, the intervention cannot be interpreted.

Figure F09.2 — Flow-control decisions begin with a mechanism hypothesis and end with a reversal decision. Aging work, large batches, persistent accumulation, slow feedback, and repeated expedites point to different tests. Every intervention is paired with balanced outcomes and a condition for retaining, reversing, or reframing it.

Source: author synthesis constrained by A03, A04, C09-A01–A05, R02, B12, S01, and S17. No row supplies a fixed target.

The framework makes three disciplines explicit. First, an observed pattern is not yet a cause. Aging work may indicate excessive intake, but it may also reveal hidden blocked work or a boundary change. Second, a lever affects several outcomes. Lower work in progress can improve one timing measure while harming another outcome. Third, the intervention must be reversible or escalatable. A policy without a review point becomes dogma.

The observation window must match the mechanism. A change to intake policy may show queue effects within several work cycles. Cross-skilling may require a longer horizon. Reliability and human burden may lag an apparent flow improvement. Leaders should not freeze a policy after the first favorable signal, nor keep an experiment running when a consequential harm has appeared.

This framework also protects local judgment. Teams closest to the work often know why an item is blocked, why a batch cannot be decomposed, or why a review cannot safely be accelerated. Leaders still own system conditions: conflicting priorities, excessive intake, underfunded shared capability, or incentives that reward starting. A useful flow intervention combines local knowledge with authority to change the surrounding system.

Open figure

Flow interventions begin with a mechanism hypothesis, track balanced outcomes, and end with an explicit decision. No branch supplies a fixed WIP limit, batch size, utilization target, or priority rule.

Return to the BBC team

The BBC Worldwide case looks different after the framework. Its value is not a headline percentage or a claim that a particular board, limit, or batch size works everywhere. It shows a team changing several connected conditions: visibility, batch handling, statistical understanding, and collective response. The public record makes a feasible operating pattern visible while leaving causality and transfer unresolved.C09-A03

The five-team WIP study prevents the story from becoming doctrine. Lower work in progress was associated with shorter lead time and with a contrary productivity result; quality was missing.C09-A01 The Facebook and OANDA case adds another boundary: short increments and fast feedback required substantial enabling capability and brought adverse effects as well as operating advantages.C09-A05

Together, the cases support a more demanding form of management. Name the flow symptom. Declare the boundary and work classes. Identify the suspected queue, batch, constraint, capacity, or feedback mechanism. Change one lever where feasible. Observe timing alongside quality, reliability, value, risk, learning, and burden. Record displaced work. Then retain, reverse, or reframe the intervention.

This is slower than copying a benchmark and faster than repeatedly treating systemic waiting as individual underperformance. It accepts uncertainty while refusing opacity.

Open figure

The cases support visibility, experimentation, and enabling investment while rejecting a universal single-lever effect.