This is the second part of a two-part series where we apply the concepts of stability, equilibrium, and coherence in flow processes to analyze common software development paradigms.

Together, these two posts show how Little’s Law lets us design enabling constraints with mathematically provable guarantees of convergence and stability in software flow processes.

The discussion builds on our earlier series on Little’s Law, especially the concepts in “Little’s Law in Complex Adaptive Systems.”

In the first part, “How Flows Stabilize,” we examined how the combination of hard WIP limits and response-time SLAs function as enabling constraints, and how Little’s Law guarantees that these will stabilize a flow process over a sufficiently long observation window.

This is typical of teams working with Kanban and its variants, but this work has usually rested on informal appeals to Little’s Law to argue that they stabilize a process rather than with disciplined, measurement-driven analysis of actual processes.

The sample-path analysis technique we used in the first part provides this missing link between theory and practice.

• It gives us an algorithm to define and measure flow characteristics, derived directly from the proof of Little’s Law.

• It allows us to characterize stability and the mechanisms by which processes become stable mathematically.

• It lets us evaluate stability, equilibrium, and coherence for any flow process with precision.

When combined with the mathematical guarantees provided by Little’s Law, sample-path analysis gives us a powerful foundation for operational analysis—one that allows us to reason about cause and effect in process dynamics, and to engineer stability in flow processes through the systematic use of enabling constraints.

Let’s recap how this worked in our previous example.

Team Kanban

We saw the general mechanism of how hard WIP Limits and Response Time SLAs work to stabilize flow in the process for a Kanban team.

The stabilization mechanism works as follows

• Because the flow process adheres to a hard WIP limit and a hard response-time SLA, the quantities L(T), Λ(T), and w(T) are bounded and, under mild rate-stability assumptions that can be empirically verified, converge to finite limits as T grows.

• In Fig 1, the two input parameters Λ(T) and w(T) converge independently to finite limits. Since all three quantities are linked by the finite version of Little’s Law, L(T) = Λ(T)·w(T) at all times, this guarantees that L(T) also converges to a stable limit.

• Little’s Law then asserts that the corresponding limit values L, λ, and W satisfy L=λ·W exactly. The latter two — λ and W — can therefore be used reliably as the process’s long-run throughput and average sojourn time.

If you have not read the first part of this series yet, it is highly recommended that you do so to clearly understand the definitions of the terms and the arguments we use above.

We now repeat this analysis for very different type of flow process and see how the concepts translate.

Team XP

This team works very differently from Team Kanban: they collaborate closely with an internal customer, delivering working software increment every single week. Their cadence alternates: one week they ship a meaningful enhancement, the next week they iterate quickly—making smaller improvements, responding to feedback, and fixing any bugs. They respect their iteration timebox strictly, cutting scope if needed to keep commitments within the box.

The working style of Team XP is not one that is typically associated with a “flow process.”

• There are no WIP limits.

• Work starts and stops at iteration boundaries.

• Teams focus on batches of work rather than flow of individual work items.

• There are rigid timeboxes.

While timeboxes are considered antithetical to “flow” in some circles, in this post, we will show that in fact, they are very effective at guaranteeing stable flow processes. In a precisely measurable sense, they are more effective stabilizers than WIP limits and SLAs while offering significantly more flexibility in certain contexts.

Sample Path Analysis for Team XP

Let’s start with the sample path flow metrics for Team XP. We have measured the process for 12 weeks so we can compare side by side with the results for Team Kanban.

Recall that we observe the process over a single expanding observation window [0,T] where T extends from the earliest recorded arrival event to the latest recorded departure event.

For each T:

• The top chart shows the sample path N(t), which is the instantaneous number of items present in the process (the instantaneous WIP) computed by taking the difference between the cumulative arrivals and departures to the process up to T. We can see the characteristic work cadence of the team XP process here - the alternating patterns where the team works on fewer large items vs more small items.

• The next chart show L(T) the time average of N(T) over [0,T]. We can see this time average appears to converge to a finite value L=1.375

• The next chart shows Λ(T) the cumulative arrival rate up to T, and this too shows the arrival rate appearing to converge towards the finite value λ = 0.171.

• The bottom chart shows the average residence time w(T) and this value appears to converge towards the finite value W=8.

We can verify that L = λW as expected by Little’s Law and thus we can report these three values as the coherent sample path flow metrics for this process.

The timebox as an enabling constraint

If you compare the way the XP process converges vs the way the Kanban process stabilized, you’ll note that there are distinct differences in the underlying mechanisms.

In the team Kanban process, the two parameters Λ(T) and w(T) stabilized independently in time, and once both had converged to a limit, L(T) also converged to a finite limit - the product of those two limits. By the end of the observation window, we could see all values had stabilized to finite values and we could declare the process as stable over the last third of sample path.

In the case of the XP process, both Λ(T) and w(T) converge in parallel to their limiting values and the L(T) appears to converge to its limiting value even before the other two values have fully stabilized.

In fact, the values of Λ(T) and w(T) have still not fully converged to a finite limit by the end of the observation window.

And yet, Little’s Law still holds!

Let’s see why this is happening.

Little’s Law for Timeboxes

In the XP process, N(T) resets to 0 at the end of each iteration, and for many points in between. In understanding how this process stabilizes, we rely on a different mechanism that is embedded in proofs of Little’s Law.

For any flow process measured over an interval where starting and ending values of N(T) are zero, Little’s Law holds exactly1.

This is a very powerful constraint and it impacts the dynamics of the process as a whole in a profound way.

Let’s see how this works.

In the figure 3, each iteration represents a timebox.

Provided the sample path N(t) starts at and ends at 0 within the timebox, two conditions hold2.

1. At any instant inside the iteration, the finite version of Little’s Law holds exactly:

   L(T)=Λ(T). w(T) where T is the portion of the sample path from the start of the timebox to some point t within the timebox. Here, Λ(T) is the cumulative arrival rate and w(T) is average residence time within the iteration.

2. For the iteration as a whole, L = λW holds. Here L is the time average of the number of items, λ is the arrival rate (which equals throughput) and W is the average sojourn time (which equals the average residence time) for the iteration.

Thus at the start and end of each iteration, the process is at equilibrium and the flow metrics for the iteration are coherent.

Now we can see this property holds when we concatenate sequences of timeboxes: since N(T) starts and end at zero for each timebox. So we can claim that for and observation window that starts and ends with any consecutive sequence of iterations, the process is at equilibrium and the flow metrics are coherent.

In Fig 4 - even though there may be significant variation of the sample path within each iteration, the process is at equilibrium and the flow metrics are coherent when measured over any observation window that starts and ends at an iteration boundary. This applies to all sequences of length 1, 2, 3 etc.. as shown in Fig 43.

So Little’s Law holds over the entire sample path simply a consequence of the fact the entire sample path is simply composed of a sequence of iterations where the N(t) starts and ends at 0.

So providing you can adhere to a timebox, it serves as a powerful constraint, guaranteeing equilibrium and coherence for sample path flow metrics measured over every observation window that starts and ends at an iteration boundary.

Equilibrium and Coherence

Let’s validate that these claims are true for our data for Team XP.

Fig 5 shows that the arrivals and departures are in balance for much of the sample path — a direct consequence of the iterations beginning and ending with zero N(t). Further the arrival and departure rates converge relatively quickly and mostly stay together along the sample path - which means the process is at equilibrium for most of the sample path.

Fig 6 shows that residence time and sojourn time track each other for most of the sample path, drifting apart only during the iterations where items stay in progress for relatively longer period of time.

We can also see that actual sojourn times are evenly distributed around average residence time - making average residence time a good proxy for average sojourn time.

In other words, the process is at equilibrium and coherent for much of the sample path even as the averages along the sample path are not stationary.

So this is a clear demonstration Little’s Law can apply even to processes that are not stationary and this XP process is very good illustration of that fact.

We can summarize all these properties by looking at the sample path coherence plot for the process.

Beginning from a cold start, the process remains coherent and at equilibrium within a 5% tolerance for 92.7% of the points on the sample path!

Contrast this with the chart for the Kanban process where only 75.6% of the points on the sample path meet this criteria.

In the team XP case, we can directly establish equilibrium and coherence along the sample path, but we are relying on a different argument from the Team Kanban case to explain why.

In that case we argued that these properties held because the process was stable. We have not argued that here - we showed equilibrium and coherence even without invoking stability.

Which brings up the logical follow-up question4.

Is this process stable?

We have seen for individual iterations, the values of L, λ, and W for the process may change a lot depending upon the workload in the iteration, even if each iteration satisfies Little’s Law.

We still need to determine separately whether or not the process is stable. That is, as we measure over more iterations, we need to prove the values of L, λ, and W converge to stable finite values.

In Fig 8, we see how these averages behave as we take them over longer and longer observation windows. If we look at two consecutive iterations consisting of a week with many small items followed by a week with a few large item, some patterns start to emerge.

• Unlike in the Team Kanban case, Λ(T) and w(T) converge in parallel - each getting smaller as we measure over longer intervals, but both exhibit oscillatory behavior.

• The alternating patterns of workload across weeks cause Λ(T) and w(T) to move in opposite directions within a 2 iteration window: when the process takes in more items, they complete faster, and when fewer items arrive, they take longer to finish. This inverse relationship creates a natural stabilizing effect—because L(T) is the product of the two, it “settles down” faster than either parameter on its own.

• In Fig 8 this manifests as the apparent convergence of L(T) even before the Λ(T) or w(T) have fully stabilized.

But while Λ(T) and w(T) are convergent over the whole sample path, we cannot technically call this process stable yet, since their values never quite stabilize over the whole path.

But timeboxes do provide a guarantee: it can be shown mathematically that a timebox constraint will cause a flow process to converge to stable limits, provided we observe it over a sufficient number of iterations and under mild rate-stability assumptions.

Here’s the reason

• The timebox bounds the possible values of w(T): since every work item must start and finish within the iteration, each sojourn time is limited by the length of the timebox.

• The timebox also bounds the number of work items Λ(T) that can be accepted and completed within the iteration, given the team’s finite service capacity. Together, these bounds ensure that both the cumulative arrivals and the total residence time within each iteration remain finite.

• Because the sample path N(t) starts and ends at zero in each iteration, the area under the curve—representing the total accumulated residence time—is necessarily bounded.

• As we integrate this area over larger and larger observation windows composed of many iterations, these bounded contributions yield empirical averages L(T), Λ(T), and w(T) that converge to finite limits.

Even so, for practical purposes we can see that the values we have reported here are stable enough and the fact that Little’s Law applies exactly over the sample path means that these metrics are coherent. So they can still be used reliably as operational flow metrics for the process.

For all practical purposes we have an operationally useful set of sample path flow metrics given this 12 week observation window — the same as in the Team Kanban case.

What does all this mean?

Our main claim is that there are many ways to achieve stable flows. Once we have the machinery to describe and measure what “flow” means independently of the underlying process mechanisms, we can start thinking of flow as a measurable technical property of a process that we can systematically engineer using enabling constraints while designing the process itself to match the context of the complex adaptive system within which it operates.

The two types of enabling constraints - the combination of hard WIP limits and response time SLAs, and timeboxes constitute a complete set of stabilizers for any flow process.

The argument for this is as follows:

• If we adopt a policy where we use timeboxes to stabilize flow we can rely on the mechanisms described here to guarantee that the process will stabilize over long enough sample paths. This requires designing processes that periodically reset N(t) to zero by policy.

• If on the other hand, our policy the policy is to not require this, then we have to assume N(t) never resets to zero, and in this case - the more general mechanism of hard WIP limits and response time SLAs guarantees stability.

We can use either one independently or in combination.

For example, goal driven processes at the team level can stabilize task level execution using timeboxes. Simultaneously, they can ensure convergence across multiple goals using WIP limits and sojourn time SLAs for goals — the latter facilitating better decision making on how many goals to pursue in parallel when feedback cycles are longer than ideal, and how long to keep individual goals in play if the payoff is smaller than expected.

There is much more to be said about how these enabling constraints can be used to stabilize any given flow process, particularly once you add costs and payoffs to the model, but these are topics for later posts.

The key takeaway from these two posts is this:

Sample path analysis and Little’s Law together provide a rigorous, systematic foundation for reasoning about flow process dynamics and stability.

They give us both the language to define what a stable process looks like, the means to measure whether we’ve actually achieved it, and understand what needs to be done if we have not.

But what about the real world?

There are some obvious objections to all these abstract claims we have made so far, so let’s just put them out there.

In the real world,

• Teams don’t stick to timeboxes.

• They don’t hold WIP limits or SLAs perfectly.

• Work spills over, priorities shift, interrupts happen, work is paused and resumed.

Real flow processes operate in complex adaptive systems, so all these are expected behaviors: by and large, they operate far from equilibrium and stability.

But this is where sample path analysis really shines: by default, sample path analysis assumes a flow process is not stable. It models the dynamics of flow processes that are far from equilibrium using the finite version of Little’s Law as the governing relation on process behavior. Equilibrium, coherence, and stability are measurable states of a process that is expected to operate far from them at most times. It allows us to rigorously study how the process moves between these states.

The stabilization mechanisms we’ve discussed so far—WIP limits, SLAs, and timeboxes—represent idealized process models. They’re the abstract mathematical anchors that real world processes oscillate around. Understanding how these idealized models work through simulations — as we have done here — is a key part of building our intuitions about how flow processes behave.

Depending upon the context, perfectly stable processes may never be possible, nor desirable. The point isn’t that we should expect perfect adherence to an idealized process. It’s that we now have the reasoning tools to understand what happens when we don’t, and these mathematical models give us clear guidance on what is possible.

Flow and stability are not meaningful end goals to be achieved regardless of context. Stabilizing a particular flow process in a larger complex adaptive system might be necessary in order to achieve a particular business outcome, and in this case, the machinery we have shown so far in the series become vital to understanding how to proceed.

For instance if a team works in an iterative process, it is normal for work to spill over across timeboxes. If that team is a critical dependency on multiple teams, and we need the ability to co-ordinate their work with the work of other teams, stabilizing their delivery process is a necessary first step to being able to communicate reliably across teams that depend on this team.

Introducing these enabling constraints — WIP limits, SLAs and timeboxes — as needed, and analyzing their impact on the delivery process for that team using precise measurable definitions brings clarity, rigor and visibility to that process of stabilization.

There are a wide variety of strategies one can adopt to stabilize any given flow process. They are all very highly context specific, and need much more information than is available purely from sample path analysis or the techniques we have shown here.

Having that reference point—knowing what “stable flow” looks like and being able to measure how far away we are from it—is a huge step forward from the informal heuristics and methodology-centric approaches we’ve had until now.

The techniques we have shown here can and should be considered methodology-agnostic tools in a toolkit to manage and improve flow processes in the complex adaptive systems that real world software teams operate in.

We will look at many more of these real-world scenarios in upcoming posts. There’s still a lot to learn about how and where these techniques can be applied, where their limits lie, and how we overlay them on existing ways of working.

What is flow?

When most people think of flow, they picture the ideal from Lean manufacturing: small batches of work moving smoothly and continuously through some process.

Work starts and finishes at roughly the same rate. Once something begins, the goal is to carry it through to completion with minimal delay or interruption. Pausing, waiting, pre-empting, and rework are treated as waste. In the idealized state of continuous flow, those frictions are minimized or eliminated.

Operationally, teams enable this with well-known techniques:

• Limiting work-in-process (WIP)

• Setting SLAs on completion times and managing work-item age

• Reducing batch size and right-sizing units of work.

• Managing flow at throughput constraints

In this context, Little’s Law and queueing theory principles are often invoked as the theoretical justification for why these techniques work to stabilize flow.

But the analytical machinery behind Little’s Law is much broader. It gives us a uniform way to measure and analyze any flow process—regardless of the underlying mechanics—and it applies across the full spectrum of behaviors we see in software development including unstable processes and the teams that don’t necessarily adopt all these practices.

This raises some basic questions:

• What precisely, does “flow” mean, and can we define it in a process-agnostic manner?

• Can we measure “flow” even if we have no idea how the underlying processes operate?

• Can we characterize what desirable and undesirable “flow” means in any given context?

• Can we use data and measurements to navigate directionally from an undesirable flow state to a more desirable one?

That in turn, lets us ask more productive questions:

• What kind of flow does your process exhibit?

• Is it right for your objectives?

• Given the flow you have, what changes will yield measurable improvements?

• How do we measure these improvements?

The goal is to understand the fundamental primitives that drive flow in complex adaptive systems—where teams may use a mix of processes—and to build a rigorous theory of how these primitives can be combined and adjusted to incrementally change process behavior, validated through process-agnostic, measurement-based evidence.

Despite substantial investment in flow measurements and tooling, we are still quite far away from this goal in software development operations management.

Instead, we default to prescribing practices —typically imported from Lean manufacturing—such as limiting WIP or right-sizing work, and rely on an indirect appeal to theory to claim they will “stabilize flow,” even though we can’t define or quantify what flow means or to measure it unambiguously1.

This approach conflates an abstract result (better flow) with the method (specific practices) and leaves the core concept undefined and unmeasured. More importantly, it gives little insight into why these techniques work to “improve flow” however you choose to define it.

As we have been discussing in our series, Little’s Law, combined with sample-path analysis, provides much of the rigorous machinery needed to bridge this gap. It makes the process model explicit, give us a vocabulary to measure conditions like convergence, equilibrium, and coherence, and gives us causal inference rules to reason about process dynamics and behavior.

In short, we already have a mathematically rigorous, process-agnostic theory to measure, catalog, and compare how flow processes actually behave in complex adaptive systems.

This post is the first in a series that will build on this foundation to systematically operationalize the concepts in practical software development settings.

If you have not been following the series so far, I highly recommend that you at least read our overview post before you dive into this material to orient yourself with the concepts and terminology we use in these and subsequent posts.

Two Flow Processes

In this two-part series we will look at two team-level software development processes that on the surface look very different, but under careful analysis using Little’s Law exhibit two key characteristics of “good” flow: stability and coherence.

We have defined these concepts precisely in earlier posts, and we will see how we can measure these in a process agnostic fashion.

Team Kanban

The first is a classic Kanban team. They operate under a clear SLA: 80% of the work they accept will complete in 4 days or less, with the remainder will finish within 2 weeks.

Internally, they enforce a WIP limit of 5 items at any given time, often working on fewer. When it makes sense, multiple developers collaborate on the same item to push it from start to finish without pause. The principle is simple: minimize waiting, pre-empting, and handoffs. Once an item is started, the priority is to carry it through to completion as directly as possible.

We already know from 20+ years of experience in the industry that these techniques lead to a stable process. In this post we will show why it does.

We will precisely define what “stable process” means, analyze this process using sample path flow metrics and clearly show through measurements how the Kanban method leads to a stable process.

Team XP

The second is a classic XP team. They work in close collaboration with an internal customer, delivering working software increment every single week. Their cadence alternates: one week they ship a meaningful enhancement, the next week they iterate quickly—making smaller improvements, responding to feedback, and fixing any bugs. They respect their iteration timebox strictly, cutting scope if needed to keep commitments within the box.

The working style of Team XP is not one that is typically associated with a “flow process.”

• There are no WIP limits.

• Work starts and stops at iteration boundaries.

• Teams focus on batches of work rather than flow of individual work items.

• There are rigid timeboxes.

In part 2 of this series next week, we’ll analyze this process using exactly the same machinery of sample path analysis and Little’s Law and show that this too leads to stable coherent flow - even though the underlying mechanics are very different.

The Assumptions

Both teams have autonomy to decide what work to accept in consultation with their customers. Both follow modern software engineering practices, including continuous delivery of working software to production. Where they differ is in how they scope and schedule work and manage their delivery process: one through explicit WIP limits and flow-based SLAs, the other through strict iteration timeboxes and customer-collaboration.

To measure the two processes, we assume only that that the start and end events for the flow process model are available and compatible: the measurement of flow starts when the team accepts a unit of work and it ends when the team delivers that unit of work. We leave the definitions of acceptance, delivery etc are undefined and focus purely on the internal dynamics of the flow process that results under those assumptions.

To keep things grounded, in this discussion we can assume sojourn time corresponds to cycle time as conventionally understood in software Kanban processes, and arrival rate λ is the rate at which the team accepts work.

Let’s observe both teams for 12 weeks2 and analyze the flow of work with the help of Little’s Law and compare their sample path flow metrics. In doing this the goal is not to judge if one method is superior to the other, but whether we can can measure and reason about the characteristics of process flows within and across processes in a process-agnostic manner.

Sample Path Flow Metrics

Recall that the sample path for L = λW is given by N(T) - the instantaneous number of items that are in progress at any point in the observation window.

Here is the sample path for Team Kanban

Key characteristics

• Limit of 5 items in progress.

• WIP rarely resets to zero

• Variable size items means we can see longer stretches where items are in progress even when most items start and finish quickly.

Here is the sample path for Team XP

Key Characteristics:

• Alternating patterns of long and short pieces of work between weeks.

• WIP resets to zero at the end of each iteration.

• There is no theoretical limit on the number of items in an iteration.

• The time spent on any item is limited by the timebox to be at most one week.

• The constraint is that every iteration delivers a meaningful increment to users (across all items).

On the surface, the two teams have very different policies and processes, and traditionally Team Kanban would the considered the team that optimizes for flow of work.

Let’s see how that plays out with data.

The Flow Metrics

Recall that sample path flow metrics measure the parameters of the finite version of Little’s Law.

This invariant is expressed as an equation involving three functions of time, derived from a finite sample path N(t) over an interval [0,T]:

Given

• L(T): the time average of N(t) over [0,T]

• Λ(T): the cumulative arrival rate over [0,T]

• w(T): the average residence time over [0,T]

The invariant states:

for each point in the observation window, where the quantities L(T) and w(T) are derived from calculations over the cumulative area under the sample path at each T.

Please see our post “Little’s Law in a Complex Adaptive System” for formal definitions and details on how these quantities are defined.

The sample path and finite window metrics for Team Kanban are shown below. We can see Little’s Law at work in the evolution of this sample path. Overall the process is convergent since L(T), Λ(T) and w(T) all stay bounded.

We can also make the stronger claim that the process is stable because Λ(T) and w(T) converge to a single finite value and stay there over the latter third of the observation window: as a result, L(T) also converges to a limit that is the product of the two limit values.

We see this below.

In this case:

• The limit value of cumulative arrival rate λ = 0.05 items/hour or 1.2 items/day

• The limit value of average residence time W = 60 hours or 2.5 days

• L = 3 items is the time average if the number of items in progress

And L = λ.W, which is precisely the result that is predicted by Little’s Law.

Why does this process stabilize?

The key fact to remember about the three sample path flow metrics is that the three values are locked together by the finite version of Little’s Law at every point in time on the sample path- this is the key invariant that governs the physics of flow.

If L(T) changes it is because either Λ(T) or w(T) or both changed, and the new value of L(T) is the product of those two values.

Knowing Λ(T) and w(T) completely determines L(T)

These are deterministic causal rules: the invariant relationship between the three parameters means we can analyze “how” the process stabilizes over time using these rules embedded in the finite version of Little’s Law.

As we observe the process over a single long observation window we can see four major periods.

• An initial “mixing” period of about 2 weeks where the observation window is still too small to capture the true dynamics of the process, and we are mostly measuring transient noise while averages stabilize3.

• Period A - where the averages Λ(T) and w(T) have both moved into narrower ranges of values, but clear patterns of the dynamics still have not yet emerged, Here L(T) is changing as the product of Λ(T) and w(T) - so the relationships here are not linear - small changes in either parameter still lead to large changes in L(T).

• Period B - where w(T) starts to stabilize. In this zone there is a nearly linear cause-effect relationship between Λ(T) and L(T).

• Period C - where Λ(T) also stabilizes - and at this point L(T) also stabilizes to a product of the stable limits of Λ(T) and w(T).

Here’s why the process behaves this way.

The Kanban process constraints: the WIP limit and the response-time SLA, respectively keep Λ(T) and w(T) bounded. Mathematically, these bounds ensure4 that the each of the values independently converges to finite, stable values when averages are taken over sufficiently long observation windows.

Little’s Law then says that L(T) also converges to a limit L and that L = λ.W at the limits.

To understand what “convergence” means intuitively - consider the convergence of Λ(T):

You can see from the plot of N(t) that the arrival patterns in period A are distinctly different from those in period B. The process behavior shifts — arrivals and completions mix in new ways — but by period C, the new arrivals no longer change the overall cumulative arrival rate Λ(T) in a meaningful way.

In other words, the process has converged: we’ve observed enough of its history that adding more data (extending the observation window) no longer alters the long-run averages of the flow parameters. The empirical averages have stabilized, and the process now behaves as though it were stationary over this window.

Note that there is no guarantee that this wont change in the future - this is where processes in complex adaptive systems differ from simpler processes in repetitive manufacturing.

But this also means that shifts in these averages imply significant changes in the internal workings of the process or the external environment in which the process is operating, or both - we are seeing “new history”. Sample path flow metrics capture all these precisely.

So this is the stabilization mechanism in Kanban: WIP limits and response-time SLAs act as enabling constraints. If you can adhere to them—and let the mathematics do its work—the process is guaranteed to become stable over time.

Convergence or stability is not guaranteed purely because we have adopted WIP limits or SLAs - you have to adhere to those limits, measuring this on a case by case basis for each process at every point in its history, and figure out if your process is actually converging and/or stabilizing or shifting between behavior regimes - the concept we call meta-stability5.

The key takeaway is that Little’s Law ensures WIP limits and SLA’s that place firm upper bounds on the time to complete all work are sufficient enabling constraints to stabilize a flow process.

How long does it take?

It’s equally important to note how long it took the process to stabilize: nearly 8 weeks of observation - even though 80% items complete in 4 days or less and the rest complete in 2 weeks or less.

This is a normal pattern. When we are working in a complex adaptive system with high variability in sojourn times, meaningful patterns of process behavior only become apparent over longer observation windows relative to sojourn times in the process. Over shorter timescales, we see a lot of transient noise in the system vs the true flow characteristics of the process6.

In general, the time to stabilize in a process is directly related to amount of variability in the residence time and the arrival rate. The lower the variability in each parameter, the faster the averages converge to a stable value - we see all the relevant history in a shorter period of time.

In our example, the residence time converged faster than the arrival rate, but in general it could also happen the other way around as well.

Here the fact that we have a two-tiered SLA: a soft limit of 4 days on 80% of items and the hard limit of 2 weeks on all items - are necessary both to bound variability and ensure convergence. We can play around with these limits in any given context to see what is achievable given capacity constraints etc, but it is the combination of hard and soft limits on the response time constraints that drives how fast the process as a whole converges.

Sample path flow metrics reveal the true “Voice of the Process.”

The particulars of any given flow process will vary and small changes to the WIP limits, the SLA, the ability of the teams to meet the SLA etc. might have drastic impacts on how the process stabilizes, how long it takes to stabilize, and even whether it stabilizes.

Reporting Flow Metrics

Sample-path analysis is a powerful tool for systems analysts and process engineers who want to understand and improve how a system behaves. But what use are these numbers to day-to-day management of processes? Isn’t this all just theoretical?

This is the core tension when relying on technical quantities like cumulative arrival rate or average residence time. It’s not at all unreasonable to ask:

• Will customers care about these metrics?

• Who cares if some mathematical averages converge over the long run?

This is where Little’s Law earns its keep once again.

Even though sample path metrics seem highly technical and non-intuitive, we can also claim something practical: if a process is stable, these same metrics are exactly the right operational metrics to report.

Under stable conditions, the internal process metrics converge to the business-facing operational metrics —throughput, cycle time, WIP etc.

These long-run metrics have several advantages over the industry-standard flow metrics used today. They are stable, interpretable, and slow to fluctuate from day to day. When they do change, it usually reflects a genuine shift in the underlying process dynamics. That makes them far more useful for decision-making and for reasoning about system behavior, and more importantly for communicating with external stakeholders when things change7.

Short-window flow metrics still have their place: they provide tactical visibility into ongoing work. But they are volatile and offer little insight into the deeper dynamics driving the process. The two perspectives complement each other—short window metrics help you manage flow in the present, while sample-path metrics help you reliably communicate about what a process does free of measurement bias8.

The concepts of equlilbrium and coherence and their associated metrics provide the operational bridge between these technical metrics and business facing ones.

Equilibrium and Coherence

Sample path analysis says that when sample path flow metrics converge to stable limit then λ is also the long run arrival rate of the process, and this always equals the departure rate, λ is also a stable measure of process throughput. Similarly W, the limit of the average residence time is also the limit of the average sojourn time, which is the customer facing average response time for the process. The process is in equilibrium when measured over these long observation windows.

To complete the analysis let’s look at our sample path metrics and verify that they converge to the relevant business facing metrics when the process is stable.

Arrival Rate converges to Throughput

The upper chart in Fig 6 is the standard cumulative flow diagram for the flow process. It shows that purely viewed from the standpoint of point in time arrivals and departures the process looks stable9 through most of the sample path. The difference between these point in time arrivals and departures is precisely what we call the sample path.

But our definition of stability is much stronger: it requires the long run arrival rate to converge to a finite value, and this is not apparent simply by looking at the CFD. We have to compute the sample path flow metrics for this10.

The bottom chart shows the convergence plot of arrival rate from Fig 3, overlaid with long run departure rate, which is the throughput from the process. We can clearly see that as the arrival rate converges to the limit, so does the throughput, and that the limit value of arrival rate can be substituted for process throughput over these observation windows.

Residence Time converges to Sojourn Time

The top chart in Fig 7 shows the convergence of average residence time w(T) and average sojourn time W*(T). At the stable limit, these values track each other letting us say that the average residence time is also the customer facing average sojourn time.

We discussed this convergence process in detail in our post “How long does it take?” The reader is encouraged to review that post for more details on this convergence mechanism.

The bottom chart tracks the relationship between the average residence times and sojourn times of items.

Since residence time over long observation windows encodes both the cycle time of all items that have completed up to that point as well as the age of the in progress items up to that point, this chart captures the dynamics of both work item aging and sojourns in one view.

Since in a stable process residence time average is very close to the average sojourn time, the element sojourn times will be distributed around the residence time average, showing that internal aging remains under control across the sample path11.

Sample Path Coherence

Finally let’s put all the material above together into a simpler, easier to use top level metric that we can use to characterize flow in a process.

To recap, measuring and tracking the three sample path flow metrics:

• L(T): the time average of N(t) over [0,T]

• Λ(T): the cumulative arrival rate over [0,T]

• w(T): the average residence time over [0,T]

give us a complete set of metrics to describe and reason about flow at all points where a process can be observed.

We’ve also see that when these values converge to finite limits, these limit values are also the same as the externally facing operational metrics of interest - sojourn time and throughput.

At any point where this happens we say that the sample path flow metrics are coherent.

In general, it is not necessary for the process to converge to a limiting value for the flow metrics to be coherent. So equilibrium and coherence are related but independent concepts.

In fact, there are many points along the sample path where the sample path flow metrics are coherent even if the process itself is not stable. In a convergent process, there are usually even more points along the way where these metrics are close enough to each other that in practice the sample path flow metrics serve as useful proxies for the externally facing metrics.

In Little’s Law in Complex Adaptive Systems we showed how to measure the empirical sojourn times W*(T) and arrival rate λ*(T) that lets us assess how often a process is coherent along its sample path by measuring how far away the product λ*(T).W*(T) from the value L(T) at each point in the observation window.

We can visualize this using a pair of scatter plots

The plot on the left hand side plots t L(T) vs Λ(T).w(T) and since these are always equal per the finite version of Little’s Law, all points will lie on the x=y line. The plot on the right show L(T) vs λ*(T).W*(T) and these will points will lie on the x=y only when the process is coherent.

The right hand plot shows how often the difference L(T) - λ*(T).W*(T) remain within a fixed tolerance ε. The plot shows that for our process, Little’s Law “applies” within a 5% tolerance for 75.6% of the points on the sample path.

This sample path coherence metric is very useful global process metric to assess how far away the process is from stability over the entire sample path at any point in time.

The number shown in figure. X includes all the transients and instabilities at the beginning of the measurement, and it is helpful to suppress those by only looking at a suffix of the sample path where these numbers have started to stabilize.

For our sample path, removing the first 20 days of observations, we get the following sample path coherence chart - which indicates that the sample path flow metrics remain within 5% of externally facing business metrics for 96.1% of the sample path excluding the initial mixing period.

When comparing across processes, the first metric is the one to use, but when comparing the same process across time, it is much better to use the metric after the mixing period has been stripped out.

This truly shows that the combination of WIP limits and SLAs has given us a stable, coherent process!

Now we can quantify and precisely measure:

• What it means for a process to be stable.

• When it is safe to use sample path flow metrics for business facing decisions.

• How far away a process is from being stable at any given point in time.

• And do all this with nothing more than start and end timestamps - ie none of this relies on our knowing how the process behaves internally.

In the next post we will highlight this last point by using the exact same techniques to analyze the process for Team XP. We’ll see that even though that is also a very stable and coherent process, the mechanisms by which stability is achieved are quite different from the ones for Team Kanban.

What about the flow metrics we use today?

Despite being rhetorically adjacent to Little’s Law and queueing theory, our industry-standard flow metrics: cycle time, throughput, WIP, work item age, flow efficiency, and so on, that are widely used and implemented in various tools are not very effective for reasoning rigorously about flow in real-world software development processes.

These metrics provide descriptive statistics that capture process behavior at points in time or over short reporting windows. What they do not reveal are the underlying mechanics of flow. They do not model or expose the cause-and-effect relationships between what happens inside a process and how the process behaves as a result.

With the current generation of tools and techniques, our measurement practices still depend on people observing processes over short time windows, trying to interpret transient noise in the data, and drawing conclusions based on intuition rather than on the first principles that govern flow and its dynamics.

Having built measurement systems using the conventional definitions and studied reams of operational flow data from production software processes in this space for nearly a decade, I firmly believe that the techniques I’ve described here are necessary to bridge the measurement gaps in reasoning about flow in the industry.

The shortcomings in current industry practices are both conceptual and practical. They arise from how metrics are implemented in tools and how foundational ideas like Little’s Law are taught and applied by practitioners: we are not measuring the right things in the right way to reflect the true physics of flow in software development processes.

Sample path analysis is a foundational technique in building the next generation of operational measurement systems for software development.

Coming up next: Team XP

In the next post, we will do the same analysis for team XP. As a teaser, here are the sample path flow metrics for that process.

The reader is encouraged to run the analysis in Fig 3, 4 and 5 with this chart and ask the following questions:

• Is this process convergent, if so why?

• If so, why does it converge?

We will discuss the answers in detail and contrast with the Team Kanban flow process in part 2.

Stay tuned or subscribe if you want to get the update when it drops.

In “How long does it take?” the previous post in my series on Little’s Law, I focus on the importance of a metric called residence time. It’s a fundamental concept you need to know about in order to understand how Little’s Law and flow metrics really work under the hood.

Also, it has huge value as a day-to-day operational metric in it’s own right.

But the concept is probably unfamiliar to most people — even those well-versed in the principles of flow and flow metrics. Recently, a number of people have asked me if residence time is just another name for concepts they already know: cycle time, lead time, flow time, and so on.

Yet another common question has been whether this term refers to the time a process a spends in a specific work flow state like development or QA - this is also called cycle time or flow time in various parts of our community1.

It isn’t.

Residence time is a fundamentally different concept, and it is worth understanding what it is. In this post, I’ll explain the relationship between residence time and the flow metrics we already know very well.

The standard flow metrics

Let’s look at the familiar metrics we use today—lead time, cycle time, flow time etc. All are elapsed-time metrics. Each measures the time between two events that mark the beginning and end of some process in a system:

• Project approval → delivery to customers

• Customer request → fulfillment

• Feature is available for acceptance testing → Feature is accepted

• Defect is logged → fix deployed to production

• PR is opened → PR is merged

Practitioners use different name like lead time, flow time, cycle time etc for these metrics, and also the same terms with different meanings: there is a fair amount of inconsistency in the way we use these terms today in the industry.

But whether we call it a lead time, cycle time or flow time, the important thing is not the specific name: it’s the definition of the start and end events and their domain semantics.

Also, what matters is that they are measuring different underlying processes. For a given process it is useful to have a generic term that refers to the time it takes to complete that process from start to finish - we will use the term sojourn time for this.

Sojourn time

In classical queueing theory, a queue serves as an abstraction for such processes2. The events are arrivals and departures at a queue, and the elapsed time between arrival and departure is generically called sojourn time.

“Sojourn” is a neutral term: it simply means time for an item to “travel across” the queue, or to be processed. All the elapsed time metrics we see in practice are all just different flavors of sojourn time. So we’ll adopt sojourn time as our generic term for such metrics. In this sense, lead time, cycle time, flow time as defined by various practitioners are all sojourn times for some underlying process.

The average sojourn time for a process is an important operational metric because is the W in Little’s Law3:

But residence time is not a sojourn time. It’s a completely different concept.

Here’s why we need it.

Average sojourn time is tricky to measure when variability is high

Sojourn time is always item-relative. You measure the elapsed time for a given item from start event to end event.

You can compute an average of sojourn times of a set of items easily if you have a set of start and end events for those items. But this implies you can observe the whole journey of all the items and know when they start and finish.

In reality, we often observe processes mid-stream. Some items are already in progress when we start observing, or haven’t yet finished by the time we stop. Their start or end times might be unknown. Other items start or finish during the window. Other start and finish during the window.

This matters because when we measure the three quantities L, λ and W in Little’s Law they have to be measured over the same observation window before you can even consider applying any of the machinery of the law.

What kind of average sojourn do you get if you can’t observe the whole journey and are simply observing the process over some arbitrary finite window of time?

The standard approach is to measure average sojourn time for the items that end in the observation window. Pretty much all the standard definitions of lead time, cycle time, flow time etc in use today assume this. In Fig 2 these would the average of the green bars, but these averages are not being measured across W2 - you need to expand the observation window to capture all the events involved.

We discussed the problems this creates in our post last week

The problems raised here are not theoretical problems. The reason that the three flow metrics as we measure them today don’t obey Little’s Law is because they are not being measured across a consistent observation window4.

Enter residence time

Residence time is a new kind of elapsed time metric that can be applied to any finite observation window. Residence time is not item-relative but observer-window-relative. If I observe a process over the window [0,T] residence time measures the portion of each item’s elapsed time that overlaps with that window.

In Fig 3 these are the durations shown in green. Because residence time is “clipped” by the observation window, it’s always less than or equal to the full sojourn time for any given item5.

We can define two different kinds of elapsed time averages for given a set of items.

• Their average sojourn time across some set of items (over some large unknown horizon) that includes all their start and end points: W​,

• Their average residence time in a finite observation window [0,T] as w(T).

Now we have two averages which are both well-defined but are potentially defined over different observation windows.

Given any sojourn time, we can define a related observation-window relative residence time.

Now the question becomes are there any observation windows where you get the same average value when you measure both quantities simultaneously6.

Residence time is a key measurement in sample path proofs of Little’s Law, so measuring processes using residence time mirrors how those mathematical proofs show how and when Little’s Law holds.

The relationship between residence time and sojourn time.

As we discussed in The Many Faces of Little’s Law, average residence time, w(T) plugs directly into Little’s Law at any finite observation window.

This holds unconditionally, for any observation window, as long as L(T), Λ(T), and w(T) are also measured over the same window. This means that residence time is always well defined over any finite window, and we can also define a corresponding well-defined version of arrival rate and number in the system such that the finite version of the law holds for any finite observation window.

This is one big difference between residence time and sojourn time - the identity in Little’s Law holds for sojourn times only under equilibrium conditions.

The relationship between sojourn times at equilibrium and residence times becomes clear when we measure them over long observation windows: windows much longer than the sojourns themselves, as in Figure 4.

Little’s Law says that if w(T) converges to a finite limit over sufficiently long observation window T, then that limit value W is also the average sojourn time of the items over those sufficiently long windows.

In these long windows, total residence time of items in the window can be decomposed into two parts: the sum of the completed items’ sojourn times plus the accumulated ages of the incomplete items.

This is the key property of residence time. Over short window, it looks like we are adding up bits and pieces of time. Over long observation windows, those bits and pieces become sojourn time and work item age, and it unifies the time accumulated by completed items and items in progress into a single number.

As the window grows, if the unknown future sojourns of incomplete items become negligible relative to the total sojourn time of completed items, then the average residence time and average sojourn time converge toward the same value. But this convergence is not guaranteed. Whether or not it happens provides a powerful way to distinguish two fundamental modes of process behavior: convergence versus divergence.

• If a process is convergent, the average residence time w(T) approaches a finite limit as T grows. Over that window, average sojourn time W also converges to the same limit. ie in a convergent process, the average residence time equals the average sojourn time over a sufficient large observation window. That’s when we can replace w(T) with W in the Little’s Law formula say Little’s Law “applies.” to the process.

  

  If the two values converge to a single value and stay there forever, then the process is stationary and we can simply use that limit value as the average sojourn time W in Little’s Law. This is also a good stable value to provide as your operating characteristic for process time and monitor it for changes.

  But more likely, you’ll get processes that behave like the one in Fig 5. These are convergent but the values of w(T) and W(T) come together and drift apart as the process evolves, but as long as they stay within a tolerance of each other, we can use residence time as a very accurate proxy for sojourn time.

  This kind of process is called metastable, and in a complex system this is what we should expect residence times and sojourn times to look like most of the time.

• If a process is divergent, the averages never converge no matter how long you observe the process. So you can never apply L= λW to that process. And measuring residence time and sojourn time together, makes this divergence visible early.

This is why residence time is by far, the operationally more useful metric. Sojourn time is useful to report metrics after the fact, but residence time is what lets you really understand the process dynamics from moment to moment.

Operator vs participant view

There is another way to look at the relationship between sojourn time and residence time.

• Sojourn time is the participant’s view—how long the customer experienced in the process.

• Residence time is the operator’s view—how much of that elapsed time was visible within an operational window.

When these two align on average, we say the flow metrics are coherent.

The bottom line

Residence time is more than another name for cycle time. It’s a complementary, but necessary lens to measure any given elapsed time metric reliably when processes sojourn times are much larger than the standard measurement window and/or the processes move continuously in and out equilibrium - as most software development processes do.

Sojourn time tells you how long an item spent from start to finish. Residence time tells you how long that item was “present” in your observation window whenever you observe it over any period of time.

So a good way to think about it is as shown in Fig 7:

For any sojourn time metric you can define for a flow process, there is a corresponding residence time metric. The relationship between average residence time and average sojourn time over sufficiently large observation window let us determine how close or how far away the process is from a equilibrium state per Little’s Law.

This applies to lead times, cycle times, flow times etc - any sojourn time metric you can define.

It is also important to remember that convergence/divergence is not a system property but a process property. In applying sample path analysis, we think of lead time, cycle time etc as representing different processes at different granularities (potentially nested within each other).

Each of these processes may be convergent or divergent independently, and it is possible that the they impact each other’s convergence/divergence. Sample path analysis will not all explain these interactions but will show the impact of those interactions via convergence/divergence of each process as measured over a common observation window.

Thus the first step to understanding the dynamics of these processes is to understand whether each of them converges or diverges.

Then we can start asking why they behave the way they do.

We discussed how this type of causal reasoning might work in

The Causal Arrow in Little’s Law.

Check that post out for more on how we can use these metrics to reason about systems.

Let me know in the comments if this is still confusing or whether I can help make this clearer.

This is the first in a series of posts exploring specific applications of sample path analysis in complex adaptive systems. We introduced this topic in broad strokes in Little’s Law in Complex Adaptive Systems.

In this series of follow-up posts we will dive into specific applications, pointing back to parts of that larger document for more detail and context.

In this post, we’ll look at the problem of measuring process time in a complex adaptive system (CAS) accurately. The conceptual challenge here arriving at a defensible definition of “process time” and a method to measure it, in situations where you cannot always place a firm bound on how long individual instances of a process might take to complete.

This is not a problem unique to a CAS specifically, but it arises commonly when analyzing the dynamics of flow processes in a CAS.

It usually begins with the age-old question..

How long will it take?

The answer is a key input to help guide where we invest time and money in “it”. Even when we have a view of expected payoffs for doing “it”, perceived time and resource commitments heavily shape what gets prioritized.

We know answering this is hard in general because it is hard to predict the future, especially when working in a complex system.

But to even answer the question, we need to answer what might seem like an easier question, but is not always straightforward as it might seem: “how long does it take?”

Examples could be “how long do deals take to close?”, “how long does a feature take to be adopted by 10% of customers?”, or “how long do customer implementations take?”

Given some operational process, all we are asking for here, is a measure of historical process time. Presumably, this should be more straightforward to answer, since it involves no prediction.

This is how we would answer it today:

1. Identify the operational process of interest.

2. Observe the process for some period of time (or look at historical data if available) and take measurements for how long instances take complete. Typically this period is aligned to a business reporting window, like weeks, months, quarters etc.

3. Report some statistical measures on the empirical distribution of process times: averages, percentiles, whatever you prefer.

4. Continue to repeat the process periodically, and report these measures for the updated reporting period.

This would reported as the answer to “how long does it take?”.

To answer “how long will it take?” you might make some assumptions like: the process time in the future will be comparable to the past, or try and fit a probabilistic model and make forecasts for how long future instances of the process will take to complete.

This is how we do it today: measure the recent past, report the observed process time statistics for a standard reporting period, perhaps create a forecast. Almost all our operational dashboards work this way, no matter what process time we are measuring.

But does this actually answer “how long does it take,” when there is significant variability and uncertainty in process time, or when we cannot reasonably bound process times up front?

Not quite. Not even in theory.

Complex systems are messier

The fundamental problem is that processes in complex systems don’t always have well-behaved statistical distributions. Statistical measures such as averages and variances are not stable, but vary over time. In other words the underlying distributions are not stationary.

Sometimes process times can be consistently bounded, and in such cases, direct measurement over a few weeks is often enough to build a stationary distribution of process time. Such processes do exist even in software development - for example, a software build process, or cycle times in a small disciplined engineering team, delivering changes to production in small batches, with continuous integration and deployment of code.

But they are the exception. Non-stationary distributions, and uncertain process times are the norm for flow processes once we move past the smallest units in an organization, or if the processes involve collaboration across businesses of functional silos within a business.

We are in a non-stationary regime by default in a complex system and here, the measurement window and the thing being measured get tangled when we measure process time.

An example: a sales process

“How long do deals take to close?” seems like a straightforward question. The standard way of answering the question would be to measure and report this on a quarterly cadence.

But some deals close after one demo; others drag on for months. Some begin in one quarter and finish in another. Others span multiple quarters. It really depends on market dynamics, customer demand, specific sales motions in play etc.

No single quarterly “average time-to-close” metric is objectively correct if the question is “how long do deals take to close?”.

Quarter-by-quarter averaging answers the question “how long did the deals that we closed this quarter take to close?”

Its a very different question and as shown in Fig 1, it produces a noisy, volatile number that suffers from memory loss, recency bias, lagging effects from deals that take a long time to close, and most importantly, ignores the biggest risk items at the time of measurement: the time spent on pending deals that aren’t being counted in the average in the quarter being measured. We are all familiar with the end-of-quarter gymnastics to make the sales “numbers” that results from this strategy1.

“How long do deals take to close?” is a fundamentally different question, and that is the question we need to answer, because it helps us answer follow-ons like:

• That’s too long. What can we do to close deals faster?

• Are deals taking longer to close over the last six months?

• Did implementing the new AI sales tool help us close deals faster?

• Is our new sales motion letting us close deals faster?

You can try and answer these questions with the quarter-by-quarter average as your starting point, but it’ll be hard to tell signal from noise. Those numbers are often so volatile that you cant tell how much of it is the true voice of the process 2 vs measurement noise.

Sales is not unique in this.

• Delivering a complex software feature touching multiple teams to production,

• Contract negotiation or project scope definition between multiple parties,

• Measuring adoption cycle time after a new product feature is introduced,

almost any collaborative, process involving independent agents that involves feedback loops and execution risk, shows the same pattern. In other words, most processes in complex adaptive systems.

Reporting process time on a rigid business reporting cadence in such an environment produces plausible sounding statistics, but they are often noisy, and not a robust basis for sound decision making.

Revealing the Voice of The Process

When we working with non-stationary processes Little’s Law becomes very useful.

Contrary to widespread and popular belief even among experts, Little’s Law holds even in processes where the distribution of process times is non-stationary! It is one of the few analytical tools we have that we can reason about the relationship between how averages of distributions change over time without explicitly reasoning about the distributions themselves. And we can do so, entirely deterministically without appealing to any stochastic assumptions at all! This makes it a powerful tool to reason about process time in complex adaptive systems.

Sample-path analysis, which we examined as the core technique behind deterministic proofs of Little’s Law, gives a precise and defensible answer in such situations. It makes some subtle adjustments how we define and measure process time, and in so doing fundamentally solves the problems with finite window sampling we outlined above.

Here’s how it works:

You start observing the process from some fixed starting point in time. This could be a date in the past if you have historical data. Some items may already be in flight; that’s fine, note it and keep going3. The key with sample path analysis is to continuously measure the system for a long time from this starting point4. So rather than observing on fixed width windows, you observe along a continuously expanding window fixed at one end.

As you observe:

1. Track completed instances and their full durations. These are called sojourn times5.

2. Track in-flight instances and the time they’ve accumulated so far - this is their current age.

3. Add them up: this total is the residence time: the time each observed instance has “spent alive” in your window.

4. Calculate the average residence time: total residence time across all instances ÷ number of instances observed. In the figure this is sum of all green durations.

To recap there are two possible lenses on process time:

• Residence time: total time accumulated by an instance in a finite observation window (all green durations in figure)

• Sojourn time: the true start-to-finish time of an instance, only known once it completes. Equals residence time if instance also started in the observation window (instance B in the figure).

Sojourn time is instance-relative and residence time is observation-window relative. The difference between residence time and sojourn time are the end-effects for the window - the blue bits in the figure 2.

You can think of average residence time as a current estimate of the average sojourn times for those instances that are you have observed so far. But you cannot know the true sojourn time for this window until some point in the future.

This difference between residence and sojourn times is a measure of the epistemic uncertainty6 in your estimate of sojourn times at the moment of measurement.

Where this uncertainty is bounded, we’ll call the process convergent, and divergent otherwise.

In convergent processes, if you observe long enough, the average residence time and the average sojourn time converge. Intuitively, the “blue bits” you haven’t yet seen - the remaining tails of in-flight items - become negligible compared to the total observed sojourn times across all instances in a long enough observation window.

Note that convergence is neither good nor bad. It depends on the interpretation of process time. If the process time you are measuring has a cost it is good for the process to be convergent because we are keeping that cost bounded. If the process time you are measuring creates benefits, economic gains etc. then it is good for the process to be divergent - for example, customer lifetime and the revenues generated over that lifetime.

Ultimately measuring process time matters only as interpreted as a carrier for time-value, whether that is cost, risk, benefit, economic gains etc determines whether we seek convergence or divergence in that measurement.

When does process time converge?

In Fig 5 below we distinguish between the two components of residence time at any moment in time.

• The residence time of the completed instances (shown in grey) which are their true sojourn times

• The age of the in-flight instances (shown in green) which are only our currently known estimate of a the true sojourn time.

There are precise mathematical conditions for when this happens, and we can monitor for them in real-time. Let R(T) be the total age of the in-flight instances in the observation window.

Convergence is guaranteed if the total age of in-flight items grows sub-linearly with the length of your observation window, ie R(T)/T < 1 for all T.

If total age grows linearly with the window length, the average residence time grows faster than the average sojourn time and two wont converge (see Fig 6). This typically means that you have long running instances that never complete so they keep adding residence time to the observation window, the longer you observe it and eventually total age swamps the sojourn times in total residence time.

So we have a few distinct possibilities each of which can be monitored for.

• Convergent: Age contribution to the total shrinks over longer windows; the two averages move closer together. If they come together and stay there, we call the process stable.

• Divergent: Total age dominates; the averages drift apart and sojourn time is no longer representative of true process time. Residence time still reflects true process time in this scenario.

• Metastable: The process is convergent. The averages hover near each other but drift in and out of equality, even as the averages themselves change over time. Most real processes in a complex adaptive system live in this zone.

Metastable behavior represents a process operating in a dynamic equilibrium state, even though the average process time is changing. When average residence time and average sojourn times are equal we say that the process time measurement is coherent.

For more details on these concepts with precise mathematical definitions and detailed worked example please see Little’s Law in a Complex Adaptive System.

When process time is coherent, residence time is an accurate representation of sojourn time and both are accurate representations of process time. In particular, when process time is coherent, the process satisfies Little’s Law L=λW exactly.

In metastable regimes, process time drifts in and out of coherence, but as Fig 8 shows, we can measure this precisely at any point in time.

If the difference between observed residence time and sojourn time at any point in time remains bounded, we also can place finite bounds on how well residence time serves as an estimate for sojourn time. If these bounds can be managed operationally through policies, this give us tools to manage the amount of epistemic uncertainty we tolerate for process time.

If it is impossible to bound this epistemic uncertainty through policy — say our process involves customers whose actions we cannot control — then we are operating in a fundamentally divergent process, and we should expect unbounded variation in process time and monitor and react to convergence or divergence as best as we can, rather than expecting we can control it.

This is a common situation in real-world complex adaptive systems.

Residence time as canonical process time

Regardless of whether the process is convergent or divergent, residence time remains the canonical measurement of process time for operational purposes. For any observation window [0,T] residence time w(T) is well defined, and it satisfies the finite version of Little’s Law:

and this holds whether the process is convergent, metastable or divergent.

Convergence or divergence concerns how this internally consistent measure relates to the externally reported sojourn time metric once you factor in epistemic uncertainty into the process. In this case, the difference between residence time and sojourn time represents the quantity we need to manage to.

How we mange it depends on the interpretation of process time. If we seek convergence, for example7, we can set tolerances for acceptable drift and growth rate for total age, and when they trigger investigate specific in-flight item(s) (and it is always in-flight items driving divergence) pulling the averages apart.

In our sales example deals could be aging for a variety of reasons:

• Things are taking too long because of the nature of the deal or unexpected complications that arose in-flight,

• They are stalled waiting for decisions, or

• Because we have too many deals in flight and only a few are actually moving, the rest are waiting for attention.

A full causal analysis requires us to measure the other two parameters of Little’s Law and bring in additional domain context 8to help us understand why the process is diverging. We discussed this at a high level in The Causal Arrow in Little’s Law and show examples of the type of reasoning involved in Little’s Law in Complex Adaptive Systems.

If we seek divergence, then the strategies are usually flipped. For example if process time represents customer lifetime, then our strategies are going to conditioned on reducing customer churn and increasing process time.

In fig 9, we show an example of a process that we are managing for convergence, that has nevertheless slipped into a divergent state. We dont want to see this pattern if our goal is convergence, but the example does show that the growth rate of total age remains the lever that moves the process from convergence to divergence.

To Recap

For flow processes in a complex adaptive system, naïve elapsed time reports become polluted when the reporting window is much smaller than typical sojourn, and what is “typical” can’t be neatly quantified.

What you are seeing include significant distortions introduced by the measurement technique.

Instead, use sample path analysis to reveal the true, evolving, voice of the process:

• Track residence time for both completed and in-flight items.

• Watch whether unfinished age grows sub-linearly. If it does, average residence time ≈ average sojourn time, and you have a defensible, real-time answer to “how long does it take?” whether that is closing a deal, shipping a feature, or negotiating a contract.

• If not, monitor whether residence times and sojourn times begin to diverge beyond your defined tolerance. When they do, investigate and intervene where possible. Where no interventions are possible, look for larger. systemic improvements that might be needed.

Now compared to the way process time is measured today we have

• A sound metric, residence time, for “how long does it take?” that is not entangled with an observation window.

• It works even with high variability and highly uncertain process times and is updated in real-time.

• A live coherence check: are residence and sojourn averages agreeing within tolerance?

• Action triggers: Any divergence beyond a set tolerance identifies that some action needs to be taken and the causal analysis using Little’s Law gives us a systematic way to track down potential sources of divergence. .

At each instant you have the best possible answer you can give for “how long does it take” and the tools to shape that answer to your needs.

The one thing to keep in mind here is that this entire analysis is entirely deterministic. We are in essence constructing a single, continuously updated sample of the process - a sample path, collecting cumulative process averages as we go along.

Any insights we get from this are specific to the process we study and for that process alone.

With complex adaptive systems this is the best we can do. What you are seeing when you observe over long enough periods, is the true voice of the specific process you are observing, free of measurement noise.

For most processes in complex adaptive systems there is no end date for how long you measure - the process itself is continuously evolving and the only thing you can compare the process with is its past self to understand how and where it is changing, and whether it needs to be nudged in a different direction.

This is what sample path analysis enables us to do - reveal the true, ongoing evolution of the voice of a flow process in a complex adaptive system.

But how long will it take?

Once you have a solid handle on answering “how long does it take”, we can turn to “how long will it take”. We’ll note that whether or not we can answer this depends on whether we can bound epistemic uncertainty.

In divergent processes, epistemic uncertainty grows without bound, so the only honest forecasts are distributions that acknowledge extreme tail risks. In convergent processes, epistemic uncertainty is bounded relative to the observation window, which opens the door to forecasting.

Residence time and convergence tests give us the foundation: they tell us when we are in a regime where forecasting is even meaningful.

Hint: Having a long run probability distribution over a convergent process and tools to detect when these probabilities change are key differentiators for forecasting driven by sample path analysis.

But that’s a subject for another post. We only promised to answer “how long does it take?” in this post!

In the next post in this series we will dive deeper to get more intuition about how residence time and sojourn time behave when the underlying processes are convergent or divergent. With lots of examples using real data!

Stay tuned or subscribe below if this is something are interested in learning more about.

For more details on how to calculate all these quantities precisely, and how the math works, see my post Little’s Law in a Complex Adaptive System.

Introduction

A central thread in our series on Little’s Law is this: when Dr. John Little first proved Little’s Law, he did so using the mathematical machinery of stationary stochastic processes. Rooted in probabilistic arguments, his proof showed that the relationship L=λW held for stochastic processes under two strong assumptions: that the underlying probability distributions were strictly stationary (not just the mean, but every statistical moment, variance, skew, and so on, remains invariant under time shifts) and that the arrival process was ergodic1.

Those are very restrictive conditions, but they are only sufficient conditions. If they were necessary, the law’s domain of application would be quite narrow—limited mostly to highly automated, low variance machine-centric environments like industrial production. Even there, strict stationarity rarely holds. Once humans enter the loop, the assumptions collapse very quickly.

Process-control techniques—pull policies, WIP limits, and the like—are often deployed both in industrial production environments and lean software development: to approximate stationarity and create localized approximations of stability. But under Dr. Little’s strict framing, even these approximations would not suffice for the law to hold.

Industrial production processes may succeed in forcing quasi-stationarity. But with humans involved at every level, most software product development processes are inherently non-stationary. At the team level, and especially across teams, customer domains, and market boundaries, there are too many exogeneous and adaptive influences to expect stationarity or even well defined probability distributions to govern their behavior.

The question is does Little’s Law apply in such domains? The answer is an unqualified yes. We’ll make the case in this post.

We showed in The Causal Arrow in Little’s Law that if Little’s Law can be applied in a domain, this fact enables powerful analyses of process dynamics from rough-cut estimation to rigorous cause-effect reasoning. We saw in The Many Faces of Little’s Law that this opens up ways to reason about time-value and the economics of processes. So there are real-world benefits to establishing the validity of Little’s Law in given domain.

Fortunately, as we saw in A Brief History of Little’s Law, the power of the law does not hinge on the strong assumptions in Dr. Little’s original proof. In 1972, Dr. Shaler Stidham’s deterministic sample-path proof showed that the validity of the law does not need stationarity or ergodicity, or even that the underlying process has a knowable probability distribution. This opens the door to applying Little’s Law in many more domains and in complex adaptive systems in particular.

The key insight is that we can use a purely deterministic approach to analyze processes through direct observation and reason about long run behavior of sample paths. Rather than speaking about the stationarity or ergodicity of theoretical distributions, we can analyze behavior in terms of convergence and divergence of empirically observed averages which satisfy provable mathematical invariants. For operations management, this is far more practical and directly actionable.

This post digs into the technical details of sample path analysis in some detail.

1. We’ll flesh out the high level concepts we outlined in the The Many Faces of Little’s Law 2.

2. While doing so, we’ll work through a concrete case study, showing how to apply Little’s Law to a product development process for a team seeking product-market-fit. Using production data, we’ll show how to measure parameters in Little’s Law using sample path techniques, interpret what they mean in the context they are derived from, and show what meaningful inferences we can make with them.

3. We’ll provide rigorous but accessible explanations of the underlying mathematics so that you can see how the law works and why it holds and build an intuition of how to apply Little’s Law beyond plugging in numbers into a formula.

We hope to put to rest once and for all the widespread misconception that this is a law that only applies to simple, linear, or ordered systems, or that real-world complex adaptive systems are not amenable to rigorous mathematical or causal analysis.

About this post

This is a long post even by the standards of the Polaris Flow Dispatch. The ideas here are not too difficult to follow, but they do require some patience to read through carefully and understand the subtleties involved.

To quote Dr. Shaler Stidham from his original sample path proof of Little’s Law:

...there are many who feel that 𝐿 = λ𝑊 is such an 𝑜𝑏𝑣𝑖𝑜𝑢𝑠 relation that a rigorous proof is superfluous: at most a heuristic argument is required...𝘏𝘦𝘶𝘳𝘪𝘴𝘵𝘪𝘤 𝘢𝘳𝘨𝘶𝘮𝘦𝘯𝘵𝘴 𝘤𝘢𝘯 𝘣𝘦 𝘥𝘦𝘤𝘦𝘱𝘵𝘪𝘷𝘦. 𝘐𝘯 𝘢𝘯𝘺 𝘤𝘢𝘴𝘦, 𝘵𝘩𝘦𝘺 𝘢𝘳𝘦 𝘯𝘰𝘵 𝘱𝘢𝘳𝘵𝘪𝘤𝘶𝘭𝘢𝘳𝘭𝘺 𝘪𝘯𝘴𝘵𝘳𝘶𝘤𝘵𝘪𝘷𝘦 𝘸𝘩𝘦𝘯 𝘵𝘩𝘦𝘺 𝘢𝘴𝘤𝘳𝘪𝘣𝘦 𝘵𝘩𝘦 𝘷𝘢𝘭𝘪𝘥𝘪𝘵𝘺 𝘰𝘧 𝘵𝘩𝘦 𝘳𝘦𝘴𝘶𝘭𝘵 𝘵𝘰 𝘱𝘳𝘰𝘱𝘦𝘳𝘵𝘪𝘦𝘴 𝘵𝘩𝘢𝘵 𝘵𝘶𝘳𝘯 𝘰𝘶𝘵, 𝘶𝘱𝘰𝘯 𝘳𝘪𝘨𝘰𝘳𝘰𝘶𝘴 𝘦𝘹𝘢𝘮𝘪𝘯𝘢𝘵𝘪𝘰𝘯, 𝘵𝘰 𝘣𝘦 𝘴𝘶𝘱𝘦𝘳𝘧𝘭𝘶𝘰𝘶𝘴, 𝘸𝘩𝘪𝘭𝘦 𝘧𝘢𝘪𝘭𝘪𝘯𝘨 𝘵𝘰 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵 𝘵𝘩𝘦 𝘪𝘯𝘧𝘭𝘶𝘦𝘯𝘤𝘦 𝘰𝘧 𝘱𝘳𝘰𝘱𝘦𝘳𝘵𝘪𝘦𝘴 𝘵𝘩𝘢𝘵 𝘵𝘶𝘳𝘯 𝘰𝘶𝘵 𝘵𝘰 𝘣𝘦 𝘦𝘴𝘴𝘦𝘯𝘵𝘪𝘢𝘭.

I wanted this post to be a comprehensive starting point for all the essential ideas of sample path analysis in one place. In coming weeks I plan to write shorter posts that focus on specific topics in this post in greater detail and with a wider range of examples.

This material is based upon the treatment of Little’s Law in the textbook Sample Path Analysis of Queueing Systems by El-Taha and Stidham. It is the definitive mathematical treatise on sample path analysis, co-authored by one of the originators of the technique. It contains the detailed mathematical definitions and proofs of the results we use here. The treatment there is terse and my goal here is to make the mathematics more accessible to practitioners without losing rigor. Any errors in translation that appear in the post are mine and mine alone. If you find any, please let me know and I will be happy to correct if necessary.

This article may be cut off in some email clients. Read the full article uninterrupted online.

Read the full article online

The Polaris Case Study

We’ll begin with a case study to motivate why I first got interested in this topic.

It is a story about the development of a new SaaS product. I know the story well because, Polaris, the software platform from which this publication originally took its name, was incubated to support my advisory practice. I wrote much of its technical measurement infrastructure and the initial version had powered my advisory business for several years before the period we examine in the case study.

The data we’ll examine comes from a period when we were building a SaaS version of Polaris: one that could reduce onboarding times for data collection and customer modeling, and provide configurable versions of analytics workflows and dashboards I had found useful with clients over the years.

In working with clients my practice leaned on industry-standard paradigms—flow metrics, code review metrics, work allocation breakdowns, DORA metrics etc—the same ones found in most other commercial engineering management platforms. We had our own proprietary takes on how we used these and they were reflected in the our advisory program, but they were refinements rather than a broad re-thinking of the core premises prevalent in the industry.

However, I found that Polaris was not all that effective at measuring our own product development process, even though we were a tiny team. I’ll explain why in a moment, but I found I had to go back to the drawing board and rethink core ideas behind the relationship between the flow of work and the flow of value to understand why.

Our Story

We were in the early GTM phase: a working product, a handful of customers, and rapid iteration to focusing on product-market-fit3. We balanced reactive work for customer implementations and work needed to close and onboard new clients, with filling out missing features and ongoing platform work.

Our product team was small: three engineers (myself included, doubling as product manager, tech lead, and consultant) and two senior engineers. The tech stack was modern, the codebase maintainable and well-tested, though some early assumptions from the consulting days had become technical debt as we discovered more customer use cases. We integrated frequently, and anything merged to main was automatically tested and deployed.

The data in this case shows our core product development process. Units of work were normalized to tangible customer, product, or infrastructure goals. We tracked them through single Jira stories4 across multiple deployments and customer feedback cycles. Each “story” might involve several production deployment and feedback cycles and run from a few days to a few weeks. We deployed continuously, so at any given time, we could be pursuing many outcomes in parallel with our customers. Lead times were intrinsically variable, and variability was not a focus for optimization since much of it was in the hands of the customer. We lacked a formal success metric so were not measuring “outcomes” or “value” formally even though work cadences were aligned to customer outcomes.

We avoided a large backlog. Outside of customer-reported bugs, we only tracked work we actively intended to pursue or were in process; the rest lived in documents, notes and my head and pulled in for detailing shortly before we decided to work on it. We had an efficient software delivery process (after all we were advising our clients on how to build these) and our process was more about staying responsive to customer signals and sales cycles, which were more or less unpredictable.

In our process much of the “cycle time” was often outside our control. We had a formal stream of interruptible internal work - things we would work on when there was nothing of higher priority from the customer end to work on5. Overall, we wanted visibility into the all threads in play, internal and client-facing, even if many sat idle a lot of the time6. Our way of working was to keep as many threads of customer facing work moving towards an outcome with our limited team, rather than minimizing multi-tasking and maximizing throughput7.

This workflow was quite different from what we recommended for our clients, who tended to be larger, more mature organizations with slower software delivery processes. Polaris itself had been optimized for their context. For our own workflows, traditional flow engineering paradigms were less useful: we already had efficient software delivery pipelines, and a focused intake process, so metrics like PR cycle time and aging internal tasks gave little insight. What we needed were metrics that reflected the full value delivery cycle.

But our tool, designed for clients still working on optimizing core software delivery, wasn’t well-suited for that. Many conventionally undesirable conditions like aging or idle work were simply our way of working, artifacts of representing the entire value creation cycle in our units of work.

I realized early on that like most tools on the market, our own tool was not a great fit for the companies still working this way, but that was not the market we were chasing at the time so it wasn’t a priority for us to try and solve it.

But in retrospect, I’ve come to think that the problem we were facing is the real problem to solve if we want to tackle the concept of measuring value creation at all. If you strip away all the internal inefficiency in delivering software - the upstream decision making to prioritize what to build, and the downstream product and engineering processes - you are still left with this cycle where where you are working across the customer and market boundaries to make and validate decisions on what to build under uncertain outcomes. Decisions that are partially out of your control and can take widely varying amounts of time to converge to a measurable outcome. Time to value and value are largely uncorrelated.

In retrospect, I found the idea of Value Exchanges in a Value Network a much better model for thinking about this problem. Value networks naturally span organizational and company boundaries, and the value exchanges in the network are (potentially long running) transactions between parties who then mutually assess whether each exchange was valuable over time. Our units of work were structured as value exchanges even if we were not formally measuring value. I was convinced that how we measure the “flow of value” had to focus on modeling these exchanges at the value network layer.

Even though I didn’t have the theory or terminology (and certainly not the math) to explain it at the time, our team had stumbled upon value exchanges as our unit of work by necessity, but our traditional flow metrics were not very good at capturing how “flow” at this level worked.

Why This Matters

By the standards of Dr. Little’s original framing of stationary stochastic process, our product development process would be ruled out of scope to reason about with the machinery of Little’s Law: too messy, too variable, too non-stationary to model as a “flow process” where everything, including “value” is supposed to flow smoothly and predictably, and continuously from left to right in highly stable processes.

We would be trying to stabilize the process through divide and conquer - breaking up internal work and customer validation to separate phases, and internal units of work into smaller “right-sized” pieces so they would “flow” on shorter timescales. As a result we would get great internal “flow”, but lose focus and analytical insights on the longer timescale value exchanges where value creation actually happens.

Current approaches to flow never really address the larger problem that the flow of value in the network is discontinuous, unpredictable and often not correlated to the time and resources invested in development. Smaller teams like ours have less internal cruft slowing down the internal cycle and the “flow of value” problem emerges starkly and irreducibly at shorter timescales.

In this post show how we can model and measure the flow of value exchanges using sample path analysis, focusing on time to value, and show that the long run process dynamics still satisfies Little’s Law in spite of highly variable, non-stationary behavior8.

Time to value and value are not often correlated in new product development, but typically we incur opportunity costs proportional to the former so it is still an important operational metric, and sample path analysis gives us a good way to measure this robustly.

The fact that we are dealing with a complex adaptive system does not change the applicability of these techniques. In fact they thrive under the conditions, because complex adaptive systems are inherently open and non-stationary and sample path analysis works out of the box in these types of domains.

The core techniques we demonstrate in this case study show not only that Little’s Law can be fruitfully applied at any timescale, but that it can be applied regardless of the internal structure of the processes and organizations involved.

This approach to modeling and measuring value creation cycles is now a core pillar and focus area for my practice, under active development and refinement9.

Sample Path Analysis - A Worked Example

Sample path analysis requires very little by way of data.

The minimal input is a data set with start dates and end dates (either or both of which may be unknown). Each data point represents some identifiable element from the domain under analysis. These elements need not be tangible objects in the real world: as long as each has an identifier for context, we can apply the analysis. What matters are the timestamps attached to these elements.

In the Polaris data set, an element represents a product goal or outcome whose success or failure can be assessed somehow. This could be a customer requested enhancement, a product feature an experiment or an internal technical enhancement.

The start date denotes the decision to pursue an outcome, and the end date marks the decision that the outcome was either achieved or deemed no longer worth pursuing.

Conceptually, this means we do not have to think of elements as discrete items arriving and departing from a “system.”

A complex collaborative process like product development, for example, may be treated as a black box whose behavior we can observe: a sequence of timestamps with some metadata describing what was pursued, how much time things took, what measurable outcomes they created etc. In theory, these can be sourced from transaction logs in operational environments provided the necessary book-keeping exists.

We are not concerned with how the underlying process produces that behavior or what its internal structure may be: sample path analysis allows us to make useful, general claims about the black box. More importantly, we can measure and reason about this long run behavior rigorously from just this minimal description, and with no additional information.

Flow Processes

Mathematically, the general category of input structures to the analysis are called marked point processes (MPPs) which are simply a sequence of timestamps with some attached marks (metadata). We will assume that element identifiers are available as marks.

In a sample path analysis, we start with an appropriate MPP to analyze. If necessary, we do some pre-processing on raw domain data from operational logs to extract and transform the needed timestamps and metadata to construct the MPP.

Little’s Law and its generalizations apply to MPPs where the marks themselves are functions of time, ie element behaviors and their effects have temporal extent. We will call these flow processes. We analyze the accumulation of those effects over shared intervals of time.10.

The characteristic feature of flow processes is that each point event has a measurable effect that persists in time after that event. That effect can described as a function of time.

To make this less abstract, consider the following figure. Domain elements create time-varying effects within an observation window.

Using Little’s Law and its generalizations, we analyze the cumulative impact of the superposition of the effects over time.

• The classical form, L=λW, concerns elements whose effects are recorded as simple binary presence/absence (e.g. Element 3 in figure 2) in the environment. The marks are boxcar functions which have unit values over a finite interval and are zero elsewhere. In a queueing system the timestamps denote arrivals and departures of items from the queue. L=λW is useful for answering questions like “how many” and “how long” and surfacing the precise relationship between the two.

• The generalized form, H=λG allows marks that are arbitrary functions of time, not just binary indicators. In the MPP representation, these presence density functions are simply additional marks attached to timestamps. These are used to model the time-value (not time-to-value) of the elements. We will use these to quantify costs, risks and rewards associated with the elements, and connect it back to the “how many” and “how long” questions we can simultaneously ask with L=λW.

  In this post we will focus on L=λW and build the foundations to talk about the more abstract concept of the flow of value via H=λG. From the standpoint of analytical mechanics, the two versions will not be very different: in all respects L=λW is just a special case of H=λG, but L=λW is significant on its own for operations management, and it is easier to build the intuition for how and why these laws work by looking at the special case.

Sample Path Construction for L=λW

It is useful to have a dedicated mental picture of domain of L=λW: an MPP with boxcar functions as marks.

This special case is shown in the figure below and it is intuitively very easy to understand because it a direct representation of the traditional queueing theory model of arrivals and departures from queues (even though queueing is not the focus of the analysis).

Each element i has a start time 𝑠ᵢ​ and an end time 𝑒ᵢ (possibly -∞ or + -∞ if start or end times are unknown). An element is called open if its end time is unknown and it is called closed if both start and end times are known.

An element is active at time t if it’s start time is at or before t and its end time is strictly after t. Elements whose end time lies at or before time t are called inactive at time t. Additionally, an open elements is considered active at all t after its start time.

We can extend these definitions to finite observation windows [0,T], where T is implicitly taken as the reference time for determining which elements are active or inactive 11.

Processes and Sample Paths

Sample path analysis focuses on processes defined over an MPP.

• A process12 is any time-varying function that we can evaluate over an MPP.

• A sample path is the sequence of values we observe when we apply that function to the MPP 13.

For L=λW, the process of interest is the counting process over the set of active elements at a point in time.

N(t) is the count of active elements at time t 14. The trace of values of N(t) over time, is the sample path of the process N(t).

For the Polaris case the process N(t) counts how many product or customer outcomes are active at time t: elements for which work that has started but has not yet reached a resolved outcome.

In the examples below we will focus on the closed elements in the process - ones for which both start and end dates exist in the data set. It is easier to demonstrate core concepts with this subset first and see how things change when we add open elements into the mix. This is precisely the difference between analyzing the history of the process vs real-time analysis.

The figure below shows this sample path for closed elements15. You can see the characteristic rhythms of our work from moment to moment: bursts of parallel activity, quieter lulls, and variability that reflects customer feedback cycles and the adaptive nature of our small-team process.

The Finite Version of Little’s Law

Any sample path that we observe is finite. One of the most powerful tools that sample path analysis gives us is a version of Little’s Law that applies to any such path at any point in time. Unlike the steady-state, asymptotic version of Little’s Law that gets the headlines, this version is a universal invariant that holds unconditionally16 .

The invariant is expressed as an equation involving three functions of time, derived from the process N(t). Given a sample path over the interval [0,T] these are

• L(T): the time average of N(t) over [0,T]

• Λ(T): the cumulative arrival rate over [0,T]

• w(T): the average residence time over [0,T]

We will define these terms formally and show how to measure each one shortly.

The key point to note here, is that finite version of Little’s Law says that these three functions are always locked together at every point in time by the invariant

Stidham’s sample path proof defines the three quantities in the equation L= λW as asymptotic limits of these three functions,

He showed that if the limits λ and W are well-defined and exist then the limit L is well-defined and exists, which allows us to establish that L= λW holds at those limits.

In this section we will show how to measure the key terms in the finite invariant given the sample path and validate that this invariant holds for our data set. Later, in the section on convergence, we will look at the question of establishing limits and consider the question of how we can verify whether L= λW for a given process.

Measuring L(T)

We begin by measuring a quantity L(T) which is the time average of the area under the sample path. L(T) is the quantity from which we derive the left hand side of Little’s Law.

This area is given by

represents total accumulation in units of element-time, over the interval [0,T].

Since each element contributes one unit of time for every unit of time it is active, H(T) is also the total time accumulated in the observation window [0,T] across all elements. This includes contributions from elements that are still active as well as those that are inactive.

To turn this into a time-average, we divide this quantity by the length of the interval T.

This value, in units of elements, is the time-average of N(t) over any finite length sample path up to the time T.

Here is what this looks like for our data.

There are several points to note about this chart:

1. The “WIP” in Little’s Law.
   N(t) tells us how many elements are active at a given moment. L(T) is the time-average of those values measured over the sample path. It is L(T) the time average, that corresponds to “WIP” in Little’s Law, not the instantaneous value N(t)17. Mathematically L(T) is a very different quantity from N(t) and much of the confusion about Little’s Law arises because the two are treated interchangeably in many popular treatments of the law.

2. Stability
   The time-average L(T) is bounded but drifts and fluctuates as the process evolves. This is what defines a convergent convergent process that has not stabilized over the entire observation window : the average never settles to a single stable value but stays bounded. By contrast, in a stable process, L(T) may wiggle early on but eventually stabilizes around a fixed long-run average - the limiting value. In a divergent process, the average grows without bound, and no such limit exists18.

   For flow processes in complex adaptive systems, this behavior is quite common. In this case we are observing the interactions between the product team and the customers developing a new product, and across this boundary the future often does not resemble the past. Instead, the sample-path average keeps absorbing new information from process states that were absent from prior history. The process remains in flux as it responds to a changing environment, and internal adaption19.

   In general, its future trajectory is unpredictable though we can get a clear sense of movement and direction from the sample path observed so far. This is the principal benefit that sample path analysis provides in this setting.

3. Smoothing effect of averaging.
   The variation in L(T) is much smaller than the variation in N(t). This is expected: averaging the area under N(t) over larger and larger time windows smooths out fluctuations. But precisely because of this smoothing, even small changes in L(T) over long sample paths are significant. They indicate that new behaviors have appeared in the underlying MPP, altering the long-run average relative to the history observed so far. You can see this visually in the shape of N(t) early in the history vs later in the history, but L(T) captures this quantitatively 20.

L(T) is the lynchpin around which Little’s Law revolves. Given a sample path, we can always measure L(T) exactly: it is simply the time average of the number of active elements over [0,T] as computed above.

But on the right-hand side, the situation is different.

Measuring Λ(T) 

In our MPP, if we focus on the just the sequence of start dates that gives us another point process, which we will call the arrival process. It has an associated counting process21.

Here A(t) gives the cumulative arrivals up to time t 22.

Analogous to L(t), let’s define the cumulative arrival rate over a finite window [0,T].

This is the average rate of arrivals in units of elements per unit time up to T. Here is what that looks like for our data set.

1. Stabilization behavior.
   Λ(T), the cumulative arrival rate, fluctuates sharply early in the sample path as averages stabilize and gradually smooths out as the observation window grows. This is expected: short horizons are dominated by a few arrivals, while longer horizons average out the noise.

2. Stability
   Even as Λ(T) smooths with time, it does not settle on a single constant value. Instead, it drifts: high arrival intensity early on, a gradual decline through the middle portion as the average converges, and a modest upward trend in the late portion.

   Nevertheless, there is a period in the early part of 2023 where the arrival rates converge to values and stays relatively flat before resuming a new trend. This is an example of meta-stable behavior in this parameter.

   This is exactly what we should expect from a complex adaptive system. The goals we pursue are neither purely exogenous nor purely internally generated: they are shaped by signals from the market, by customer needs, and by internal adaption from feedback and learning. The arrival process adapts continuously to these forces, and that adaptation leaves its imprint on the observed arrival rate.

3. Operational implication.
   Because Λ(T) still changes slowly over long horizons, even small shifts carry meaning. They indicate sustained changes in the pace at which work is arriving—whether due to customer demand, or the decision to start things internally and pursue more goals in parallel.

Measuring w(T)

The final quantity in Little’s Law is W: the long-run average of the time between start and end timestamps across all elements. In classical queuing theory, this duration is called the sojourn time, a term we will adopt as well23.

In our case study, sojourn time is the critical time to value metric that we are interesting in optimizing our processes for.

When constructing the sample path over a finite observation window, some end times may fall outside the window. In that case, we only observe part of the sojourn in that window. We define the residence time of an element in [0,T] as the portion of its sojourn time that lies within the window [0,T]. In figure 7, the green shaded areas represent residence times.

It represents the portion of the sojourn that we have observed at a point in time in the sample path, with the remainder representing a (potentially unknown) future evolution of the path at that point in time. In a real-time measurement, residence time represent what we know about the time accumulation in the process up to the point of measurement 24.

Formally we can define the residence time of element i for the window [0,T] as

where 𝑠ᵢ and 𝑒ᵢ are the start and end time stamps for element i.

If both the start and end timestamps for an element fall within [0,T], then residence time equals sojourn time. In general residence time for any element is at most as large as it’s sojourn time.

The average residence time over arrivals up to time T, in units of time units per element, is

This is simply the sum of the durations of the green areas in the figure divided by the number of elements that overlap the window [0,T].

For a deeper dive into the significance of residence time in flow processes, please see our in-depth post:

Let’s see what residence time looks like for the Polaris data set.

A few points to note about this chart:

1. We see the same non-stationary behavior as with the other two parameters: early volatility due to transient effects followed by gradual stabilization, though the overall average drifts upward over time.

2. The overall trend is a significant increase in average residence time across the history. Even small increases are meaningful when we are dealing with sample path averages, and here we see roughly a 50% increase: from about 6 days in the early portion to about 9–9.5 days in the later portion.

3. If Little’s Law applies (as we will see it does in this case) these average residence times are the same as the average sojourn times, so we can treat these residence times as our operational metric for time to value.

In absolute terms, these are still relatively moderate numbers for a measure of time-to-value reflecting our generally reactive mode of operation. Interpreted as the average time to realize customer or business-facing outcomes, 6–10 days was an acceptable number for us. But relatively speaking our process “slowed down” significantly over the period we examine.

Residence time reflects the accumulated time of both inactive and active (aging) elements.

• Inactive elements contribute to residence time in [0,T] only until its end date, after which their contributions stop.

• Active elements continues to accumulate residence time linearly until their end date is reached. The accumulated residence time up for an active element to a given T is the age of the element. If the end date is unknown, these elements accumulate residence time indefinitely.

This clearly shows that convergence of the average residence time w(T) to a finite limit is entirely driven by the balance between active (aging) and inactive (completed) work—precisely in line with well understood flow management principles.

The difference is that the average residence time captures the effect of this balance in a single number, measured consistently over the same window as L(T) and Λ(T) and derived from the same underlying quantity H(T): the total time accumulation in the window.

This is why measuring w(T) is superior to tracking the average sojourn time of inactive elements and the age of active elements separately, as is common industry practice today25 . As we shall soon see, in software environments, where non-stationarity is the rule, residence time provides a superior metric for reasoning about time accumulations in the long run.

The impact of variability

In figure 9 we show the scatter plot of sojourn times overlaid on the average residence time on the sample path. We can see the average residence time conceals a very high variation in sojourn times. In our case it was because we had goals that took significantly smaller, and significantly larger amounts of time to complete. This variability reflects the increasing mix of customer dependent delays vs things that were under our control the more we tested the market.

For now, it’s important to keep in mind that variability in sojourns is itself a key operational metric. Even if it’s not always under our control, it determines how long it takes for w(T) to converge in the long run (assuming it converges at all).

Little’s Law doesn’t speak to this convergence speed—it only requires the limit, not how quickly you approach it. But operationally, variability is what governs the “patience” you need before the the data stabilizes in meaningful ways so you can analyze patterns.

In practice this means that we might need to experiment with raw data to remove extreme outliers to get a sense of this convergence - this process requires a bit of judgement and nuance, but it also gives us a good way to operationally distinguish routine variation from exceptional variation26.

We’ll have much more to say about how to reason about this variation for non-stationary sojourn times in later posts.

Value vs Time to Value

This data set includes both internal and customer facing goals (we were not tracking these separately at the time) but while it is the case that many of the low sojourn values in the distribution were internal because we had fewer constraints, and the high value ones were customer facing, this was by no means universally true.

There were high value outcomes that were achieved in a cycles that lasted less than a day and low value outcomes that took us weeks to identify as low value 27. There are many situations in product development where value and time-to-value are correlated. But in general, we should look at value and time to value as independent quantities and be able to reason about both on the same timeline. This is what lets us reason about the relationship between work and value, investment and value etc in a rigorous fashion. This is the motivation for the H=λG form, which we will examine in more detail in later posts.

Putting it together

With all the core machinery for measuring L(T), Λ(T) and w(T) over a finite sample path in place, the finite version of Little’s Law says

for every value T in the observation window [0, T]. This requires no additional conditions, so this is a universal invariant for any sample path N(t).

Let’s prove this. Though the proof is a simple exercise, this finite version is the heart of why Little’s Law is true and it is the most useful operational tool that sample path analysis gives us and it really helps to internalize why it is true.

After we present the proof we will verify that the finite version holds for our sample data set28.

The proof - why the finite version is true

Recall that H(T) the area under the sample path from [0,T] was the time accumulated by the elements that are observed within the window.

We can get the same number by adding up the residence times.

So we can write the average residence time as

From the definition of L(T) we have

Lets rewrite 1/T

So now we have the finite version of Little’s Law.

The proof itself is straightforward, but the deeper question is: what does it mean?

The intuition goes back to the simple conservation principle we discussed in The Many Faces of Little’s Law:

The total time accumulated in an input–output system by a set of discrete items, when averaged per item, is proportional to the time-average of the number of items present in the system. The proportionality factor is the rate at which the items arrive.

The finite version is just this principle expressed in technically precise terms in the language of sample paths and MPPs. It works because both L(T) and w(T) are different kinds of averages of the same underlying quantity H(T): the total time accumulated by all elements in the window [0,T].

• Each unit of time an element spends in the system contributes simultaneously to H(T) and to the count N(t).

• Once this conservation is recognized, the rest is algebra: the finite identity is simply an accounting relationship about time accumulation.

This also explains why the general version H=λG holds: the argument is identical if, instead of unit contributions, each element accumulates arbitrary real values over time at every instant it accumulates time (ie it is active).

It is important to note once again that the finite version of Little’s Law in a mathematical invariant representing a physical conservation principle. It always holds at all points for any sample path provided the above measurements are made correctly.

We can visualize this fact using a simple scatter plot of L(T) vs the product Λ(T)·w(T).

The points on this scatter plot will always lie on the x=y line. If they don’t your calculations are wrong.

In addition to validating the consistency of the measurements, this plot also gives some sense about the distribution of the values of L(T) over the sample path: denser clusters of values represent states that the process returns to very often and represent dominant modes of operation: here we see the numbers largely range between 2 and 3 29.

What is clear is that these numbers move in lockstep and when viewed across the time line these relationships provide rich insights into the long run behavior of the process. The most powerful of these is the ability to reason about cause and effect when we see a change in L(T).

Reasoning about cause and effect

The most fruitful way to look at the finite sample-path parameters L(T), Λ(T), and w(T) is to see how they move together in lockstep when any of the averages change.

This is how Little’s Law should always be read: not as three independent numbers, but as three values derived from the same sample path, bound together by the finite identity.

There is a well-defined causal mechanism embedded in the invariant. Even though the law is written as an equation, the relationship is unambiguously causal.

• L(T) cannot change independently.

• Any change in L(T) is entirely attributable to a change in Λ(T), w(T), or both, and the magnitude of the change in L(T) is exactly accounted for by the magnitude of the change in the product Λ(T).w(T).

As discussed in The Causal Arrow in Little’s Law, this is also the only kind of cause-and-effect reasoning we can do with these quantities.

This is a direct consequence of the deterministic proof of the finite version of Little’s Law we derived above. Its clarity comes from the fact that the finite version is an accounting identity involving averages, not a statistical correlation or a probabilistic inference.

Let’s take a look at how this type of cause and effect reasoning can be applied in practice. In figure 11 we’ve laid all of the key sample path parameters along the same timeline and we can now look at how changes in values impact each other and how cause and effect can be inferred.

As we look at the sample path and the parameters derived from it over a two year history, we can see distinct shifts in behavior regimes.

Region A (early 2022 – mid 2022):

• What we see: L(T) rises steeply, Λ(T) is initially very high but falls quickly, while w(T) rises. In N(t) we see bursts of overlapping work.

• Interpretation: Much of the behavior in this early phase are due to transient effects while the averages are still stabilizing. While the finite identity holds as each point in the time, the variation in each value is typically due the fact that we are seeing new states of the system constantly at smaller timescales. Once we have seen “enough” of the history to be representative of the process, the averages settle down into a narrower range even as they continue drifting in lockstep over time. It is usually best to ignore these early segments of the sample path in any sort of cause-effect reasoning.

Region B (mid 2022–early 2023):

• What we see: L(T) drifts slightly down, Λ(T) declines further, and w(T) stabilizes. N(t) shows fewer simultaneous elements.

• Interpretation: Here Λ(T) and w(T) move in opposite directions: declining arrivals counterbalance stable residence times. The result is a lower, flatter L(T). This is the most balanced operating mode in the history.

Region C (early 2023 - mid summer 2023)

• What we see: L(T) starts to climb again, Λ(T) levels off, and w(T) rises steadily. N(t) shows more concurrency than in Region B.

• Interpretation: With arrivals steady, the increase in residence time drives the increase in L(T). There’s little counterbalance—w(T) dominates, so L(T) rises.

Region D (summer, fall 2023)

• What we see: L(T) reaches its peak, while Λ(T) and w(T) both rise modestly. Yet their simultaneous increases amplify each other, producing a sharp increase in L(T). N(t) shows frequent high-concurrency spikes.

• Interpretation: Even small, simultaneous increases in arrivals and residence time compound under Little’s Law. This amplification effect is what drives L(T) to its maximum here.

Region E (winter 2023 - early 2024)

• What we see: L(T) stabilizes at a higher plateau, Λ(T) continues a gentle upward drift, while w(T) eases slightly. N(t) shows consistent but elevated concurrency.

• Interpretation: Here we see counterbalancing: rising arrivals are offset by easing residence times. The product holds L(T) steady at a higher level, marking a new operating mode.

Overall, we can see that starting in mid to late 2023, the operating regimes started shifting. The main difference is that we had not landed any customers before then and afterwards these shifts were largely driven by new customers with newly discovered requirements, reworking our features after testing with customer workflows etc.. longer latency in response cycles with customers etc. Our internal process which was more or less held constant throughout this two year period. So the shifts here give a picture of the pressure the real world environment in which we were working was placing on us, and how our development process responded to that.

The value of this type of analysis is that we can see the effects of this quite clearly in the finite sample path flow metrics even if we know nothing about the process.

Key insights:
The three metrics are always locked together, but whether L(T) grows or stabilizes depends on how Λ(T) and w(T) interact.

• When they move in the same direction (Regions A and D), the effect is amplified in L(T).

• When they move in opposite directions (Regions B and E), the effect is moderated.

• When one dominates (Region C), L(T) follows that trend.

Either way, by continuously monitoring N(t) and L(T), we can detect shifts in operating regimes as they happen and trace them back to their proximate causes in Λ(T) and/or w(T).

Even though we are showing cause and effect at large timescales in this example, it is important to note that this type of reasoning is possible for changes between any two time points on the sample path, even ones at small scales.

The techniques to do this type of causal reasoning across and between timescales is one of the key contributions of The Presence Calculus. It requires additional machinery, but if you are curious, the details are here. We’ll have more to say about this topic here on the Polaris Flow Dispatch as well in coming weeks.

The impact of process changes

Viewing history consistently along a sample path also makes these measurements useful for validating the impact of larger process changes. For example, if we intervene to reducing process time in the underlying process, we should see meaningful decreases in w(T) and L(T) while Λ(T) remains relatively stable (assuming it holds constant).

In practice, however, shortening residence times often frees up capacity, creating slack which lets you accept more work. In that case, Λ(T) may drift upward, and the net effect on L(T) depends on whether the gains in residence time outweigh the increase in arrivals. Either way, the invariants ensure that the changes in L(T), Λ(T), and w(T) remain locked together by Little’s Law and we will have seen the impact of the change - more slack or greater arrivals at lower residence times.

For changes to show up clearly in these metrics, the interventions must have a lasting impact: incremental improvements that only nudge single metrics at short time scales will typically not register in long run averages 30.

Finally, while the finite version is extremely important for operational measurements, we should always keep in mind that this expresses L(T) as the product the cumulative arrival rate and the residence time over a finite window, while Littles Law as we commonly understand it expresses it as the product of the long run arrival rate and long run average sojourn time.

So we still have some work left after this to prove our case that Little’s Law as we know it applies to complex adaptive systems.

Share

Convergence,Equilibrium and Coherence

Let us now turn to the question of whether L=λW applies to a complex adaptive system such as the one we have just examined.

To review, Stidham’s sample path proof defines the three quantities in the equation L= λW as asymptotic limits of these three functions,

He showed that if the limits λ and W are well-defined and exist then the limit L is well-defined and exists, which allows us to establish that L= λW holds at those limits. Which raises a sticky question - how do we know the limits for limits λ and W are well-defined and exist?

Stidham’s theorem is stated for infinite sample paths, yet in practice we only ever observe finite ones. When proving theorems, stationarity and ergodicity are assumed to ensure the averages converge. But in operations management, we are not proving theorems, we need some direct evidence that limits exist even we cannot observe the sample path all the way to infinity.

In the Polaris data, two years of history showed no sign of divergence (which would have ruled out the limit entirely), but neither did it show clean convergence. Instead, the averages Λ(T) and w(T) wandered in metastable patterns—exactly what we should expect in a complex adaptive system.

So does that mean Little’s Law, L = λW, fails in such settings? The answer is no. The law still holds, but the argument for it requires more nuance than the textbook proofs.

If you examine the Stidhams proof of L= λW the reasoning is as follows: if the limits

are well-defined and exist, then Stidham showed that at those limits the end-effects due to the difference between the cumulative arrival rate and the true arrival rate, as well as the difference between average residence time and average sojourn time vanish. Thus at the limit the quantities in the finite version of the law are identical to those in L= λW, and so the law holds.

Sample path coherence

To quantify the impact of end effects, we define time varying versions of λ an W over an observation window [0, T]:

• λ*(T): the empirical arrival rate — the number of elements that became active (arrived) by time T, divided by T. Λ(T) also counts elements that were already active before time 0 (elements with unknown start dates). The difference between Λ(T) and λ*(T) are the end effects for arrival rate over [0,T].

• W*(T): the empirical average sojourn time — the total sojourn time of all elements that became inactive by T, divided by the number of deactivations. Sojourns are measured relative to each element’s own start and end, not the observation window. In the figure below the grey rectangles are counted in W*(T) but the green ones are not. w(T), the average residence time, counts both. The difference between w(T) and W*(T) are the end effects for sojourn time over [0,T].

In our case, we are assuming that there were no arrivals before time 0, so the cumulative arrival rate and true arrival rate are the same and there are no end effects on that term. In the example in figure 12 the blue bars represent the end effects for sojourn time vs residence time.

As we discussed in The Many Faces of Little’s Law over sufficiently long intervals, if the process is not divergent then the sojourn times of the inactive elements dominates the residence time of the active elements and the end effects vanish the longer the window we observe 31.

The idea is to check for empirical convergence between the values of L(T) and the product λ*(T).W*(T) over any [0,T]. Equivalently, we can check pairwise if w(T) converges to W*(T) and Λ(T) converges to λ*(T) at each point on the sample path.

The empirical approach bypasses the postulate of the existence of limits in Stidhams proof. Instead of assuming the limits exist, we measure differences

We can set some suitably small convergence threshold and say that the Little’s Law holds approximately at very point in time where the difference is below the threshold.

If they do, then we can assert that

where L(T) is the usual time-average of N(t) over [0,T].

Let’s plot L(T) against λ*(T).W*(T) the way we did for the finite version to see this empirical convergence in action.

We see that the values stay clustered around the x=y line for most of the sample path. This, in spite of the fact that the averages keep moving around almost all along the sample path!.

We can also directly verify the convergence between the two related quantities on the right hand side directly as well so that we can where this deviation occurs along the time line.

As expected, arrival rates are identical since there are no end-effects in play in our data set, and the average residence time tracks the empirical average sojourn time almost everywhere on the sample path!

So we can say that in this case, even though we are working with a complex adaptive system, the process remains in a quasi-equilibrium state all along the sample path even as the underlying averages move around. Little’s Law continues to hold almost everywhere on the sample path! This may be unexpected, but it is has a direct mathematical explanation.

Why managing age is the key to convergence

w(T) and W*(T) converge if the sojourn times of active elements dominates the residence time as the sample path grows. The gap between the two averages is proportional to the contribution of active elements to the average residence time. Intuitively, this contribution is the sum of the green bars in Fig 12, the total age of the active elements in the observation window.

If that total age grows more slowly than the length of the observation window, the end effects disappear and the two averages converge over longer and longer windows.

This gives us a clean operational check for convergence. The total age of active elements along the sample path must grow sub-linearly as the window is extended longer and longer. If it does, the process tends toward convergence; if it does not, the process tends towards divergence.

Typically, the gap between the curves grows when you have many open elements (with no end date), heavy-tailed sojourns, or long bursts of arrivals that lets the total age of active elements grow linearly with T rather than sub-linearly. Convergence will be slower or impossible in these cases and the cloud will spread farther from the x=y line. That’s a signal that L=λW does not hold.

Divergence

Its not hard to see divergent behaviors emerge even in the Polaris data set. All you have to do is to include open elements (with unknown end dates) into the calculation. We had explicitly ruled that out in our earlier analysis by only including closed elements in the data set - elements with known end dates.

In this case Λ(T)  remains bounded but w(T) grows unboundedly. This corresponds to the scenario where certain elements never become inactive once they become active and continue accumulating residence time proportional to the size of the observation window.

Operationally when residence time starts to diverge, it is a signal that there are aging elements in the process that we need to pay attention to - this is perfectly consistent with the principles we use today in managing flow.

But there are two keys things to note;

1. The finite identity L(T) = Λ(T). w(T) holds regardless of whether the process is convergent or divergent. You can see this in the scatter plot below for the divergent process above.

   

2. In the case of the divergent process not only is L != λW in the limit but the values in the finite version and empirical version do not converge. But there is still valuable signal in this fact. See the scatter plot for the empirical convergence below:

This chart is not just a random scatter of points around the x=y line as one might perhaps expect.

The shape of the distribution shows that L(T) and the product λ⁎(T)W⁎(T) diverge early and then follow largely independent trajectories. But there’s clear structure there: the left hand side L(T) continues to grow, while the right hand side stays bounded.

Why? The arrival rate behaves similarly in both formulations, so the difference is driven by the treatment of sojourn times:

• L(T) is a time average that includes the residence time of open elements.

• W∗(T) is a sample average that only includes the sojourn times of closed elements.

In a convergent process, these differences shrink as T grows: sojourn times and residence times reconcile, and the cloud collapses toward the diagonal.
In a divergent process, residence time grows unboundedly while sojourn times (and arrival rates) remain bounded. The result is exactly what we see here: the “cloud” drifts steadily away from the x=y line.

So even when the identity L=λW fails to hold, the behavior of the system follows the conservation laws of the finite identity and we can still reason about cause and effect in the behavior of arrival rates and sojourn times indirectly.

Equilibrium and Coherence

When W*(T) converges to w(T) it means that the sojourn time reported on average for elements matches the residence time in the system. The process is at or near equilibrium even if the underlying averages shift over time. This makes the finite version, which is simple to reason about an accurate proxy for the element-wise average sojourn time.

Operationally want to report and manage to average sojourn time because this is the externally facing metric, but when the process is convergent these outside-in and inside-out metrics are equivalent. We call this operational coherence. In a convergent process, we can confidently report finite window parameters for this.

This is a key difference between using sample path metrics and flow metrics defined over arbitrary finite windows as is common practice in the software industry. In operations management today, we typically measure flow metrics on finite time windows aligned to business processes and cadences. Sample path metric are aligned to the a single, sufficiently long sample path and reflect the real-time internal dynamics of the process over the long term - they represent the “voice of the process” so to speak32.

In fact the misalignment between the operator time windows used for internal reporting and the sample paths for the underlying processes are a key reason why many operational metrics seen on dashboards today feel noisy and hard to use for making meaningful operational decisions.

Once you start measuring along sample paths the long run sample path metrics don’t change drastically over short operational windows, and when they do, they give you actionable diagnostics on what you should be paying attention to33.

Much clarity ensues once start measuring flow this way.

Does Little’s Law Apply to Complex Systems?

Let’s finally put this question to rest.

All the behaviors we have shown are independent of whether or not the underlying “system” is a complex adaptive system. The same behaviors of transitioning from convergent to divergent behaviors and back can be observed with ordered and unordered systems, linear and non-linear systems, chaotic systems etc under the right conditions.

Little’s Law is not a contingent property of specific systems. It is a universal rate-conservation law, dictated by the mathematics of time accumulated by elements in a process, and it shows up in practice as clear, observable behaviors: convergence or divergence along the sample path in all situations - whether or not the formula in Little’s Law applies.

So yes, we can confidently say Little’s Law can be applied to complex adaptive systems.

The Complex System Advantage

Complex systems introduce more, well, complexity: of system behavior.

They don’t converge quickly to a single stable average value. The averages keep moving around. We cannot guarantee that the finite limits exist. This is why having a powerful piece of mathematics like sample path analysis to reason about how such systems behave over time is so valuable.

On the other hand, in a complex adaptive system we have an advantage: as humans who are part of the system we can closely monitor convergence and divergence trends in real time with this same machinery and adapt to change the trajectory of the sample path!

We don’t always need to limit ourselves to building fully convergent, stable processes, because we are part of the system and have the power to influence convergence and divergence from within the process!

• If a process is diverging and we want it to converge we know what we need to act on.

• If a process is converging and we want it to diverge (say N(t) represents active customers) we know what we need to act on.

What the machinery of sample path analysis gives us is a mathematically rigorous set of techniques for measuring the drivers of convergence and divergence, the ability to reason about cause-effect relationships between them, and the ability to act on that knowledge.

A rock-solid measurement substrate, which sample path analysis provides, is a pre-requisite for building sound decision-making systems.

As we all know, with humans in the loop, it’s making decisions and acting on the knowledge that is the hard part. But the job does not get any easier if your measurement system is built on weak foundations. Sample path analysis fixes this in many practical operational scenarios.

In my mind this is what we have been missing in operations management in software development since we started measuring and ironically, it looks like the humble formula that that used to tell us how many widgets an assembly line can produce remains a core part of the solution.

What’s Next?

We’ve only scratched the surface of what sample-path analysis can do in software product development and engineering. Here’s my rough roadmap of topics I’m working on and plan to write about in upcoming posts:

Operationalizing sample-path analysis
I’m working on a bare-bones open-source toolkit to generate basic sample-path results directly from CSV files. I plan to extract this from my proprietary platform so others can experiment with their own data in a lightweight way. If you’d like to help test and refine this with real-world use cases, let me know. I’ll move it up the priority list if there’s enough interest.

From raw data to analysis
A systematic guide to taking a raw dataset, constructing MPPs and producing a usable sample-path analysis like the one we showed in this post. In this case study I glossed over a few tricks that make the story much easier to tell. Without them, the picture can be much murkier when running the analysis on raw data. We’ll work through those caveats and what they mean.

Process–subprocess flow relationships
Extending sample-path analysis to study how processes and subprocesses interact. Sample path analysis is fractal and this linkage is critical to push cause–effect reasoning across processes and timescales.

Integration with Flow Engineering
I’ve been exploring how sample-path analysis connects with value stream mapping in my advisory work for some time now. I’m especially interested in collaborating with folks in this space on creating lightweight, bespoke data-backed measurement models that support rigorous constraint analysis and create a consistent measurement system to show the impacts of flow engineering initiatives on operational metrics. Formalizing value models and making them measurable is part of this thread.

Metastable processes and forecasting
Current forecasting techniques in software (e.g., Monte Carlo simulation on short empirical distributions) have well-known limitations. Sample-path analysis gives us tools to build more robust empirical distributions and to detect when they’re no longer representative. We can forecast without appealing to reference forecasts which don’t actually make sense in complex adaptive system. This opens the door to improving Monte Carlo approaches, and even layering bayesian or probabilistic graphical models on top of MPPs to reason about cause and effect across linked processes.

Use cases for L=λW in engineering metrics
Most standard engineering metrics (DORA, code review metrics, flow metrics, etc.) can be derived from a suitably defined MPP and the identity L=λW. Framing them this way brings unity, mathematical rigor, clarity, and systematic cause–effect reasoning to what is today an ad hoc, theory-free landscape of metrics dashboards.

Use cases for H=λG
We haven’t yet shown concrete examples here, beyond broad claims about the “economics of flow.” I plan to start with cost functions, which align most directly with the machinery we already have. Value functions are trickier: they flip the objective from convergence to divergence, and require working in the finite regime where H=λG no longer holds. My current approach leans on value networks and value exchange models integrated with sample-path analysis using H=λG, but there may be entirely different ways to tackle this. Still early days - if this sparks your interest, I’d love to chat.

Refining the Presence Calculus
The Presence Calculus is a unifying measurement substrate that connects these ideas. Built on the foundation of sample-path theory, it extends those concepts to reason and compute efficiently across timescales and across model boundaries. Conceptually, I view sample path analysis as a core analytical technique within the Presence Calculus.

The machinery for sample path analysis we’ve presented here can become unwieldy when applied beyond single processes or across timescales. We need higher-level abstractions to describe process topologies and the relationships between sample-path metrics and finite-window metrics measured over short operational windows.

The Presence Calculus provides exactly those constructs: abstractions with provable mathematical properties that make reasoning about process assemblies simpler and scalable, while maintaining rigor.

Across all of these threads, the opportunity is the same: to treat product development and engineering metrics not as ad hoc numbers justified through appeals to intuition or industry “best practices”, but as precisely defined, deterministic, repeatable measurements over processes emerging from complex collaborations, backed by provable mathematics.

By applying the machinery of sample-path analysis, we can analyze the metastable dynamics of most real-world software and product development processes in much richer detail. Compared to the ad-hoc measurements accompanied by vague hand-waving we use to reason about metrics today, it puts operational reasoning with engineering metrics on a much firmer foundation.

If you are interested in any of these topics and would like to either collaborate or contribute please reach out and connect with me on LinkedIn and let me know what you are working on and how we might work together.

Also please subscribe to The Polaris Flow Dispatch to support this work.

Most people think Little’s Law is about stability. But what it says about causality is even more important.

This is the third post in our series of essays on Little’s Law here at The Polaris Flow Dispatch.

The first post, The Many Faces of Littles Law was our high level introduction to the key generalizations to Little’s Law that were made in the 50+ years since the original proof of a queueing theory result by Dr. John Little. Dr. Little’s result is the de-facto definition of Little’s Law, but the generalizations made by researchers since that proof and are a much more relevant starting point for applications of Little’s Law in complex, dynamic, non-stationary environments like software product development.

The second post. A Brief History of Little’s Law was more in-depth examination of the history of the proofs and proof techniques that led to this modern understanding. Understanding the proof techniques gives us insights into why the law is true, which then helps us understand how to apply it in context.

All, this inevitably leads to the question - so what? Why should anyone in the “real world” care about any of this? Is this just abstract mathematical theory with no practical applications outside the lab?

The “real world” arguments, particularly in complex knowledge work domains like software development, is often tied to the popular conception of Little’s Law as a result that applies to stable, steady state systems - which “real world” systems often are not.

The first two posts were intended to broaden that framing so that it is clear that Little’s Law can be applied as-is to systems that are not stable, potentially expanding the scope of “real world” applications.

So the next question is how?

This post addresses that question conceptually before the rest of this series starts digging into more granular details of how to operationalize these ideas in software development in particular - where will need to deal with plenty of “real world” problems.

Little’s Law in the “real world”

The conventional story is that Little’s Law tells you when a system is stable. Since the law holds for stable systems, the thinking is that any system where it holds must be stable first. But if most “real world systems” are not stable, is the law even relevant?

There are three problems with this line of reasoning.

First, it ignores the fact that many systems that appear unstable when viewed on short timescales are in fact stable when viewed over sufficiently long timescales, and thus are directly amenable to analysis with Little’s Law.

In this scenario, we can often rely on the fact that knowing any two of the values in the identity 𝐋 = 𝛌𝐖 gives us the third to apply the law in useful ways. There are many useful “back-of-the-envelope” calculations that can be made where we can easily measure two of the variables and can estimate a third, harder to measure quantity.

As but one example, in software development, portfolio level average lead times can often be quite easily and accurately estimated by looking at how many things were planned and delivered over a sufficiently large number of quarters. This gives very reasonable estimates for strategic planning using available historical data without building expensive measurement infrastructure to track the granular details of projects and their detailed timelines.

There are many, many more applications in this vein and this is by far the most common use case for the law in general operations management1.

Second, many real world system that are unstable, can be brought into a “quasi-stable” state by adopting process controls that actively manage 𝐋, 𝛌 and 𝐖. Much of Lean process engineering disciplines focus on this. So this opens up another avenue of applications for the classical stationary forms of Little’s Law.

But as we have seen in the first two posts in this series, the law holds even in unstable and non-stationary systems. So the fact that a system might be unstable does not rule out useful applications of the law. The sample path proofs of Little’s Law give us tools to operationalize Little’s Law deterministically, and in complex, non-stationary environments.

So what are these applications?

This gets us to what, in my view, is the most important reason why the law matters in the “real world”: whenever Little’s Law holds, it lets you reason about cause and effect when 𝐋, 𝛌 and 𝐖 change.

So once we are in a position where we can measure 𝐋, 𝛌 and 𝐖 so that Little’s Law can be shown to hold, then we can also start reasoning about what causes these values to be the way they are and why they change.

The Causal Mechanism

The identity 𝐋 = 𝛌𝐖 does more than link three averages via an equation, it encodes a causal structure: 𝐋 (time average of the number of items in system) is an output, determined by 𝛌 (arrival rate) and 𝐖 (average time items spend in system)2.

This defines the mechanics of Little's Law :

1. You can change 𝛌 or 𝐖, and this changes 𝐋. You cannot change 𝐋 directly.

2. Conversely, if you see that 𝐋 has changed, it must be because either or both of 𝛌 or 𝐖 changed and the new value of 𝐋 will be exactly the product of the new values of 𝛌 and 𝐖.

This is a robust rule for causal inference but the causal relationship here is often misunderstood or misapplied.

You’ll hear statements like: “Reducing WIP (𝐋)3 reduces cycle time (𝐖).”

Not really. The causal arrow doesn’t point that way4.

The law only says the three values are constrained by the equation. It does not tell you how 𝐖 will change in response to changes in 𝛌 or 𝐋.

Similarly, consider 𝐓𝐡𝐫𝐨𝐮𝐠𝐡𝐩𝐮𝐭 = 𝐖𝐈𝐏 ÷ 𝐂𝐲𝐜𝐥𝐞 𝐓𝐢𝐦𝐞.

It’s tempting to read this as a causal mechanism (shorten cycle time to increase throughput). But you can’t use it that way.

Two things are at play here:

• The equality constraint: knowing any two values fixes the third and

• The causal mechanism: 𝐋 changes when and only when 𝛌 or 𝐖 change.

Both are often used together in applications, but the latter is the only inference rule we can use for reasoning about cause and effect using Little’s Law.

𝐋 = 𝛌𝐖 is unambiguous.

It tells us: change the inputs (𝛌, 𝐖), and the output (𝐋) is determined. That’s the causal structure the law gives, and it’s the only one we can rely on.

It’s hugely important, but it holds only when 𝐋, 𝛌, and 𝐖 satisfy Little’s Law.

How can we apply this?

At a high level, this means: observe “a system” as a black box and collect measurements for 𝐋, 𝛌, and 𝐖 over sufficiently long time intervals where the identity 𝐋 = 𝛌𝐖 holds.

• If we can do this, we don’t just have three disconnected numbers, we have a reliable mechanism for detecting changes in 𝐋 and analyzing its proximate causes (𝛌, 𝐖) without any additional internal info about the system.

• If we cant, then there is a whole set of diagnostics that one can derive for why it does not. The proof techniques behind the law show us how.

Either way, this first-pass analysis using Little’s Law is going to be the starting point for a deeper causal analysis of flow in “a system” however you choose to define it: we can measure and monitor changes in 𝐋 and trace it back to changes in 𝛌 and 𝐖.

Now when we see changes in 𝛌 and 𝐖, we can layer in additional info about the system into this black box view to explain these changes. This is a dynamic analysis enabled only when 𝐋 = 𝛌𝐖 holds over the measurements.

This is important because changing 𝛌 can change 𝐖 and vice versa, and these can jointly influence 𝐋 but that is not explainable by Little's Law alone. We need more details about the system.

Typically, this is where queueing theory comes in the classical operations management applications of Little’s Law. We gather information about probability distributions, service policies, capacity, concurrency, service rates, utilization etc. to the extent they are measurable to able to understand the dynamics of the relationship between 𝛌 and 𝐖.

Or we may forgo queueing theory altogether and use heuristic models like the Theory of Constraints if detailed measurements are not possible.

In complex domains free form narratives5, value stream maps, collaboration protocols, etc. all play a role in building a deeper understanding why the system behaves as it does. These provide the context to explain how 𝛌 and 𝐖 interact.

The key thing that Little’s Law enables is a clean separation between a “black box” view of a system where we can make meaningful causal inferences about changes in the system without knowing any of the details of the system other than the observable variables 𝐋, 𝛌, and 𝐖.

When modeling systems this way, the definition of the boundaries of the “black box” and even the “items” that are under analysis are up to the modeler. Little’s Law is agnostic to all this.

We can decompose “the system” from an outside-in view to whatever level of detail that makes sense for answering the questions that the analyst is interested in. There is no single defined way of decomposing a “system” up front - we choose the perspectives and granularity and timescales over which we are interested in performing the analysis.

In short, when they satisfy Little’s Law 𝐋, 𝛌 and 𝐖 are 𝐚𝐜𝐭𝐢𝐨𝐧𝐚𝐛𝐥𝐞. Not every combination of WIP, cycle time, or throughput numbers can claim that.

Up next

Starting with the next post in the series, we will start making all this concrete with more detailed descriptions of how to do this type of operationalization in practical software development contexts.

We’ll start with showing how to produce accurate and actionable 𝐋, 𝛌 and 𝐖 by observing systems of interest over sufficiently long intervals.

One of the remarkable things is that, given the generality of Little’s Law, this is almost always possible once you’ve focused on what problems you are trying to solve for and established a clear working context for the observations. Even understanding clearly why Little’s Law doesn’t apply gives useful insights that are actionable.

But you’ll need the background in the first two posts to fully make sense of the details in the rest of the series, so if you have not read those yet, this would be a great time to catch up before we dive into deeper waters.

If you are interested in receiving these updates in your inbox as they are published please subscribe for updates.

Subscribe now

In our last post, The Many Faces of Little’s Law, we showed that Little’s Law has undergone several upgrades since the original proof. by Dr. Little in 1961.

The original proof was ground-breaking and Dr. Little is rightfully associated with the law, but over the years, as this field has evolved, the association of the law with its original statement and proof has also resulted in several myths about what Little’s Law is and where and when it can be applied.

Even though Little’s Law is most often encountered in conjunction with queueing theory, modern proofs of the law are independent of queuing theory. While it is most often applied in analyzing the flow of work in an operational setting, the core principles underlying Little’s Law have allowed it to be extended naturally to analyzing the economics - costs, risks, and rewards arising from that flow of work.

The law applies to certain classes of stochastic processes, and deterministic systems are a special case. But it does not depend on the internal structure of these system, just their observable input-output behavior1. It applies equally well to linear or non-linear systems, simple or complex systems, and even certain types of chaotic systems.

However, in typical applications, this generality is not exploited mainly because the law is largely assumed to apply only under the stringent conditions that Dr. Little proved in 1961.

Sample path analysis2, a mathematical technique pioneered by Dr. Shaler Stidham in proving the first deterministic version of the law in 1972 is a core theoretical technique underpinning the evolution of the law.

It is of particular interest in software product development because Dr. Stidham showed that many of the perceived limitations that are typically associated with Little’s Law - requiring steady state equilibrium, stationary distributions, and low variability - are not intrinsically needed to apply Little’s Law in operational contexts.

This has practical implications. Our first post laid out the theory in broad strokes and our deep dive article3 goes into more details. We will discuss many more specific applications in this series.

But before we begin, this post establishes the historical context, exploring the evolution of Little’s Law through its mathematical proofs. These are powerful generalizations of Dr. Little’s result, developed over 30+ years by mathematicians and moved it from an empirically observed mathematical regularity in operational settings into a foundational law of systems analysis.

Examining this history gives us insights into the why is is a subtle result, and also why it was possible to loosen restrictions and generalize the law to what it is today. This will be crucial context as we dig deeper into the details of applying the law in its more general forms.

Empirical Origins

Little’s Law began its life in the mundane world of operations management—as an empirical regularity observed in retail stores, call centers, and other service operations. Observers noticed that when more customers came in and stayed longer, the stores got more crowded. That seems obvious. What was less obvious was that the relationship between the averages of arrivals, the time customers stayed, and the number of customers in the store at any given time were mathematically related.

The mathematical relationship observed was:

Where λ is the rate at which customers arrive, W is the average time a customer spends in the store, and L is the average number of customers in the store.

This relationship between averages was confirmed empirically time and again and widely assumed to be true —but no one knew why this relationship between these average values should hold.

As we will see in this series, that is anything but obvious. Behind it is a profound and general truth about the dynamics of any system where entities enter and leave over time - a truth we now know as Little’s Law.

Why this is important

Empirical observation often reveals correlations—associations where two quantities move in concert. These correlations can be a starting point for causal reasoning, prompting us to search for underlying mechanisms that might explain the linkage. However, correlations do not always indicate causation, as they may be influenced by confounding variables.

It is important to note that the empirical observations leading to Little’s Law are much stronger than statistical correlations. They describe an equation relating key variables. When variables are linked by an equation, the space of plausible explanations for change narrows dramatically.

For example, if the average number of customers in a system increases, there are only three possibilities: the arrival rate increased, the average time each item spent in the system increased, or both. No other explanation is consistent with the equality—there are no confounding variables.

Knowing that a relationship like Little’s Law holds gives us a robust framework for causal reasoning about observable system behavior. It doesn’t tell us what will happen in the future, but it constrains what can happen. Whenever the equation holds, these three quantities remain bound by the relationship between their averages.

We have a powerful causal reasoning tool if we can rigorously prove the conditions under which this equation holds for any system with inflows and outflows. That is why this result—and the man who proved it—are rightly honored with the name Little’s Law.

Dr. Little proves the law.

In 1961, Dr. John Little4, at the MIT Sloan School, gave the first mathematical proof of this empirical relationship. His proof method used the most popular tool for solving these problems: queueing theory, developed decades earlier to model congestion in telephone exchanges 5.

The precise result he proved was the following:

In a queuing process, let 1/λ be the mean time between the arrivals of two consecutive units, L be the mean number of units in the system, and W be the mean time spent by a unit in the system. It is shown that, if the three means are finite and the corresponding stochastic processes strictly stationary, and, if the arrival process is metrically transitive with nonzero mean, then L = λW.

Queueing theory typically uses probabilistic models of arrivals and departures, and most results here depend on specific assumptions about how stochastic processes behave.

What made his result so remarkable was how broadly it applied. He showed that it held under a broad set of conditions. Specifically, he showed that it held regardless of the types of the probability distributions. That was an unexpectedly general result for queueing theory.

It pointed to something deeper—something structural about input-output systems. No matter how arrivals and completions fluctuated, or whether they were regular, random, or correlated, the strict equality of Little’s Law still held.

This eliminates randomness as the underlying mechanism that governs why the law holds. It also removes variability as a driving force. While variability still affects the behavior of the systems—how large the values of these averages are and how much they fluctuate—it does not invalidate the relationship.

In fact, his proof showed that what happens inside the system doesn’t matter to the relationship at all!

From a queueing theory perspective Little's Law, it turns out, describes the dynamic behavior of arrival and departure processes when they interact in time. It says that no matter what these processes are, the dynamic behavior of the queue, expressed via the relationship between these averages, is constrained by the above equation requiring only stationarity of probability distribution as a non-trivial condition.

Little’s proof was a special case

Dr. Little's proof required a set of conditions on these averages—specifically, that they were well-defined and finite. These are relatively mild conditions. But his proof also required that the underlying processes were strictly stationary: that is, the long run statistical properties6 of the system did not drift over time, and the arrival process was ergodic (this is the metrically transitive part). These are significant caveats. They imply that, as proven initially, the formula in Little's Law applies only to systems operating in a very well-behaved and stable equilibrium.

However, since Dr. Little's original paper, newer proofs of the law have shown that his argument relies on stronger assumptions than necessary. Specifically, they show that the requirements of stationarity and ergodicity in Little’s proof are not fundamental to the law itself—they are consequences of the particular proof technique he used. As such, they are sufficient conditions for the law to hold, but not necessary.

There’s value in understanding why.

Little’s Law is fundamentally a statement about time averages—quantities that can be directly observed in real-world systems over time. Dr. Little, however, used probabilistic techniques to prove a relationship between the expected values of random variables, which are called ensemble averages. Unlike time averages, ensemble averages are computed across the entire probability distribution of a variable and cannot depend on how the system evolves over time.

Little’s proof established the equality between these ensemble averages. To apply this result to real-world systems, one must assume that the ensemble averages and the time averages of the corresponding processes converge to the same value. This convergence is guaranteed when the underlying stochastic processes are stationary and ergodic—hence the need for those assumptions in Little's original proof.

But this doesn’t mean that stationarity and ergodicity are required for the law itself. It is entirely possible to prove Little’s Law directly for time averages, bypassing probability theory altogether.

This is precisely what Dr. Shaler Stidham of Cornell did in 1972 7.

Stidham’s Proof of Little’s Law

Stidham demonstrated that Little's Law was even more general than previously believed. His proof was purely deterministic and did not rely on any probabilistic or queueing theory techniques. It was based on standard techniques from continuous analysis, using time averages on sample paths for queue length, calculated over finite intervals. It eliminated the requirements for stationarity, ergodicity, and related assumptions.

The specific statement he proved was the following :

Consider a system observed over a sufficiently long interval 0≤ T< ∞. If the time-average arrival rate and the average time each item spends in the system over this window each converge to finite limits—call them λ and W, respectively—then the time-average number of items in the system also converges to a finite limit L, and the relationship L = λW holds.

In contrast to Dr. Little’s original formulation, which relates the expected values of probability distributions, this version establishes a relationship between the limits of time averages observed along a sufficiently long sample path over which time averages are calculated.

This is a significant generalization, but it also needs to be read carefully to understand precisely what Little’s Law is asserting—and the specific conditions under which it holds.

Stidham’s proof did not require even queueing theory assumptions like a defined arrival or departure process. So, technically, he showed that Little's Law is much more than a result that applies only to queueing systems. He showed that Little's Law was a general statement about the long-run dynamics of any input-out system where entities arrive at and depart from the system over time.

The only requirements for the law to hold were that the three averages in the equation were well-defined and converged to a finite limit when measured over sufficiently long observation windows.

His proof reinforces the idea that the formula L = λW as originally proved by Dr. Little applies to systems in equilibrium—albeit under much weaker conditions than those in his original proof. But Stidham’s proof technique, sample path analysis, opened up ways of exploiting a key conservation principle behind the law that functions as a universal invariant governing the law.

As we’ll see in this series, this allows us to apply the law under both equilibrium and non-equilibrium conditions. This is what allows Little’s Law to bridge from equilibrium environments to dynamic, evolving, and complex systems like software development which often operate far from equilibrium.

Starting with our next post, we will examine Stidham's specific result more carefully, using his ideas to show how when measured appropriately, Little's Law can always be empirically validated and used in software development.

The General Form of the Law

Stidham’s extensions of sample path analysis led to a very general version of Little's Law where instead of indexing on items, we arbitrary time varying functions of items with some weak restrictions.

A version of this general form was independently proven much earlier in a somewhat different context by Brumelle8 but Heyman and Stidham9 showed that the result could be obtained by directly applying the sample path arguments used to prove L = λW and directly established the connection to Little’s Law.

The general form of the law is stated as H=λG where H and G are direct mathematical analogues of time average and sample averages L and W except defined over time varying functions over processes. This allows us to generalize Little’s Law to economic quantities tied to processes such as costs, risks, revenues, profits etc.

As we discuss in our deep dive on Little’s Law this generalization is substantially more complicated to even setup and describe compactly. However, this version of Little's Law, called the Generalized Little's Law, has critical applications to modeling the economics of flow and will be critical in understanding how to measure the relationship between the flow of work and the flow of value - something we have been exploring in some detail in this series.

But before we can fully appreciate that version and what it says, we have to understand the importance of sample path analysis as it underlies both Stidham’s proof and its generalizations. This is what we will explore further and apply specifically in a software development operations management context, in the next few posts.

At this point, Little's Law is considered to be much more than a result in queueing theory. It has earned something close to the ontological status of a natural equilibrium law that reveals a fundamental relationship that applies to very general forms of stochastic processes.

This is a powerful property that can be exploited in many different ways once you establish it, and this has been the real reason why Little's Law has been so useful in every domain that it has been successfully applied so far.

Post Script 1: The Throughput Formula

It’s worth pausing to explain why the version of Little’s Law commonly used in software today looks quite different from the one we’ve discussed so far.

Dr. Little’s original proof applied to stationary systems with finite averages—conditions that most manufacturing processes in steady state typically satisfy. In practice, this means that under equilibrium, arrival rates can be assumed equal to departure rates. This allows us to write:

L = 𝑋.W

where 𝑋 is the departure rate or throughput. Rearranging this and renaming the terms gives us the familiar throughput formula:

Throughput = WIP / Cycle Time

This is the formula for Little’s Law that was originally used in manufacturing contexts and its utility was highlighted in Hopp & Spearman’s seminal textbook 10. There it is a natural fit, where factory managers focus on optimizing WIP and cycle time to meet a fixed throughput goal derived from stable production orders. It was imported into Lean software development, originally by Tom and Mary Poppendieck11, and operationalized in the software Kanban community by David Anderson12 and Dan Vacanti13, and more recently in the enterprise contexts by Dr. Mik Kersten14.

But in software development, direct application of this formula for operational metrics is problematic. Much of software development happens in an environment where demand is constantly shifting, capacity cannot be accurately measured, and variability in the work is endemic and often irreducible. Much of the work happens at the boundary between two complex processes (the customers and a software provider) and involve long running concurrent processes involving humans and machines on both sides.

This introduces non-trivial features into the problem of measuring flow, that are hard to fully capture with the steady state throughput formula, but nonetheless are representable using the more general forms of Little’s Law.

In our treatment of Little's Law going forward, we’ll explore the more general forms of Little’s Law as the basis of measuring flow in software development, and minimally, this means starting with the arrival rate form and adopting Stidham’s sample path analysis to measure flow metrics.

For example, one of the key flow metrics that is now recognized as needing specific focus in software contexts is work item age. As we will see, under the more general framing of Little’s Law, this metric falls out quite naturally as a core component of residence time which is directly represented in the finite version of Little’s Law.

Many of the adaptations of flow management techniques derived from Lean will still apply in terms of day to day operations, but the way we measure the flow in general systems contexts and its impact will become significantly more streamlined and powerful. As a result we will also gain new insights into how we can use these measurement to further evolve and improve the techniques we use in day to day operations.

Post Script 2: Further reading

In 2011, Dr. Little published a survey15 of all the developments related to Little's Law since its original proof, on its 50th anniversary. Most of this series started from a close reading of that paper and its source references. I highly recommend it if you’re interested in a more technical, yet accessible, presentation of the material in this post with an excellent first person account from Dr. Little himself on his journey with the law and its proofs.

Interestingly, in this survey article Dr. Little starts with Dr. Stidham’s result as the canonical statement of Little’s Law, more or less ignoring the statement that he originally proved!

This is not to say that his result has somehow become less useful. It absolutely is in many operational contexts where stationarity is guaranteed. But the key lesson you will take away from this survey article is that it is not required, and that this frees us up to apply this law in vastly more general settings.

Our deep dive article is another reference to go deeper here, with a specific focus on the things we will find necessary in adapting this material to operational use in software development.

References and Footnotes

If you’ve worked in software delivery or followed any Lean or flow-based methodology, you’ve almost certainly seen this formula:

This is a formula that shows that there is an underlying “physics” to the flow of work in software, and that these key flow metrics are not simply isolated descriptive statistics.

The relationship between Throughput, WIP and Cycle Time show up in books and flow metrics dashboards, and the formula is almost always referenced in training materials to justify WIP limits, to reason about delivery times, to explain why queues form. It is part of the Lean software development canon.

The formula is usually introduced without much further qualification, as “Little’s Law.” This is directionally correct, but it’s not the full picture.

What we’ll call the throughput formula came to lean software from its applications in manufacturing. In that domain there are set of assumptions that can be made, that allow us to treat this formula as something that holds generally, in that context.

It is also well known that this formula is a rearrangement of a more fundamental identity:

This identity relates the long-run average number of items in the system (L), the average arrival rate (λ), and the average time each item spends in the system (W).

Under steady-state conditions, when arrivals and completions are balanced and the averages converge to finite values, you can simply replace λ with Throughput, and interpret L as WIP and W as Cycle Time and the throughput formula emerges.

But those steady state conditions often don’t hold—especially when measuring software development processes.

Observation windows are short, often shorter than the time span of work. Work starts, stops and arrives in batches. Work items may span reporting cycles. Under these conditions, if you just plug in the numbers for Throughput, WIP and Cycle Time from your flow metrics dashboards into the throughput formula, you’ll find that the equation fails to hold.

This is sometimes taken as evidence that Little’s Law “doesn’t apply to software,”

But this is demonstrably false. It reflects a fundamental misunderstanding of what Little’s Law is now understood to be.

If you’ve ever had folks give all sorts of esoteric or emotional arguments for why Little’s Law is irrelevant in software, this post will argue that perhaps it’s worth understanding the full power of Little’s Law before making that argument.

So let’s dig into what “Little’s Law” really says.

The Principle behind Little’s Law

There are many ways to state “Little’s Law”. But all versions follow from a single universal principle:

The total time accumulated in an input-output system by a set of discrete items, when averaged per item, is proportional to the time average of the number of items present in the system. The proportionality factor is the rate at which the items arrive at the system.

This is a conservation principle relating time averages and sample averages of time accumulation in an input–output system. It is general and universal.

More importantly, it is provable mathematically. We can clearly characterize how and when the principle holds. Unlike many “laws” that circulate in software and operations, this one leads to physical laws whose validity we can test directly knowing that it must hold.

Given the time average of the number of items, the arrival rate, and the average time each item accumulates in the system, the principle says these quantities are linked: if we know any two, the third is completely determined.

Knowing that Little’s Law holds reduces the number of degrees of freedom for change in the system. It gives us a strong model for reasoning about proximate causality in any context involving these three variables.

If I know that L changed, the only possibilities are that λ changed, or W changed or both. The product of their new values will always equal the new L. Any other explanation must ultimately be traced back to a change in one of these two other quantities.

Note that this does not let you predict how the values will change in the future, but it constrains how it can change.

Recognizing that this general principle exists makes it simpler to model and apply Little’s Law in contexts very different from the manufacturing setting implied by the throughput formula.

And this is the key - understanding that there are many different versions of a the law that we can derive contextually from the same underlying universal principle.

As 50+ years of research in academia and industry have shown, the list is larger than you might imagine and has many significant applications in software development as well.

The Finite Version of Little’s Law

The core conservation principle applies even if the system is in flux—so long as all measurements are taken over the same time window. In this sense, the most general version of the law is the one that applies to a fixed, finite time window:

The fact that the we use upper case Λ and lower case w is not a typo. These are not the same quantities as in the familiar steady state version of the law, but closely related to them.

If we look at a finite observation window T where the window is shorter than the time accumulated by items, we will see many different configurations in which items overlap that window: some start and end within the window, others start before and end inside, and still others span the entire window.

But if we focus on the observation window itself, we can consider the way in which items accumulate time strictly within the window.

This leads to a set of observer‑relative quantities that on their own obey the conservation principle relative to that observation window.

• Λ is the cumulative arrival rate over the window - like the arrival rate, but includes everything that was already present at the start of the window as an “arrival”. You can think of it as over-estimate of the true arrival rate.

• w is the average time accumulated by the items within the observation window - this is conventionally called the residence time of items in the window. You can think of this as the underestimate of the true time in the system.

• L is the time-average number of items observed over the window. This is the exact value of the time-average of the number of items.

Little’s Law for finite windows states that the identity 𝐿 = Λ × w always holds for any finite observation window. It holds at all times and at all timescales and it does not matter whether the system is at equilibrium or not.

In this sense, it is truly a physical law. Mathematically, it is a tautology.

But crucially, even though the two quantities in the right hand side are estimates in the finite version, the estimation errors cancel out over any finite window of time, yielding the true value of the time-average of the number of items in the system!

This is a remarkably powerful universal constraint governing time accumulation in any input-output system.

The problem of end-effects

So what’s the catch? Well - clearly the difference is that λ and W in the well known version of Little’s Law represent measures on the complete items and not partial ones. In classical queueing theory, λ is the long arrival rate (rather than the cumulative arrival rate) and W is the long run average sojourn time (rather than residence time).

When dealing with business processes we are ultimately interested in talking about arrival rate and sojourn time rather than cumulative arrival rate and residence time over finite operational window. If we take a customer facing view, they represent rate at which customer requests arrive in the long run, the time it takes to respond to those requests etc. So these are the numbers that are operationally significant to a business.

To understand the relationship between the two sets of measurements, we can consider zooming out and observing the system over a window that is much longer than the time accumulated by individual items in the system (sojourn times).

Over sufficiently long windows, the time and item averages measured over that finite window are dominated by the measurements on complete items rather than partials. The partials become “end-effects” that become less significant as we take measurements over larger and larger windows.

The identity L=λW holds in the long run, because as the end effects vanish, cumulative arrival rate and average residence time converge to the (true) arrival rate and average sojourn time respectively. This is the intuition behind the formal proof of what is now considered the definitive statement of Little’s Law.

Short Windows vs Long Sample Paths

Think about how data is gathered and used operationally.In software, flow metrics are almost always reported over windows - a week, two weeks, a sprint etc. that are determined by the business process being used Scrum, Kanban, SAFe etc, and not usually based on how long things actually take to move through the process.

But many meaningful “items”: features, defects, and epics often take longer than these reporting windows. That means the data in any reporting window includes partial work: some items started earlier, some are half done, some finished in a window, some won’t finish for weeks.

As a result, trying to apply the throughput formula or even L = λ × W to an operational window directly, produces inconsistent numbers. Arrival rates don’t match completions. Work appears and disappears midstream. The law “fails” not because the math is wrong, but because the quantities being plugged in are not measured over a consistent observation window. This is the real reason why Little’s Law “doesn’t hold” when you typically measure it in operational flow data.

This is also why the finite-window version, L = Λ × w, is critical. It relates measurements that are actually observable in a consistent interval. Even when the observations include partials or the system is shifting between operating modes, the relationship holds. There are many operational uses for this, but we wont go into that here - that will be a topic for future posts.

Sample Paths

Our example above suggests that if we observe it over a “long enough observation window” we will get an alternative, and perhaps more meaningful set of numbers for measuring flow.

But how we decide what is long enough?

This is where a powerful analytical technique called sample path analysis comes in. It is the foundation for the mathematical proof for L=λW and the concept can also be used quite directly in an operational setting.

The idea is that instead of measuring flow metrics over short, rolling observation windows, we observe the system from a fixed starting point in time and observe it continuously over a long enough window (weeks, months, years etc - as long as necessary). In the context of Little’s Law the sample path we observes is items in the system at any point in time - the instantaneous WIP. The observation window is the length of the sample path.

For a sample path a finite length T , if N(t) is the number of items in the system at time t, the time average of the number of items in the system over the interval T is given by the ratio of the area under the sample path to T.

Now the question becomes do the estimation errors in the finite observation windows always vanish and become negligible if we observe a sufficiently long sample path.

The answer is, not always: The classic proof of Little’s Law by Stidham shows that they vanish if L(T) converges to a finite limit over a sufficiently long T.

This leads us to the critical ideas of convergence and divergence.

Convergence and Divergence

If we observe a sufficiently long sample path we only have two possibilities to consider.

First possibility: the system settles down, after a finite window of time. Practically, this means that if we measure the quantities the finite version we’ll find that the quantities L(T), Λ(T) and w(T), in the finite version they will converge to finite limits L, Λ, w and these limits will correspond to the L, λ , and W of the steady state version of Little’s Law.

This, in fact, is the key result that was proven by Dr. Shaler Stidham in 1972 and is now considered the definitive statement of Little’s Law.

That is, if Λ → λ and w → W as T → ∞ then L = λ × W .

But what if these limits dont exist? Then work continues to accumulate indefinitely, arrivals outpace completions, residence times stretch out indefinitely—we get divergence.

This is the more useful distinction: not whether the “system is stable,” but whether or not long run averages on a sufficiently sample path converge to finite limiting values.

In practical terms Little’s Law says:

• If the cumulative arrival rate Λ(T) converges to a finite limit as T grows,

• and the average residence time w(T) converges to a finite limit as T grows,

• then the limit L = λ × W exists and holds.

If not, the system is divergent, and divergence tells us something real: the system is structurally unbalanced. Items are backing up, time in system is growing, arrival rate is overwhelming capacity.

This shift—from seeking “steady state” to detecting convergence or divergence—is critical in domains like software, where systems are rarely in equilibrium for long.

All of these parameters can be precisely measured on operational data.

In fact, the minimal length of the sample path over which a system achieves convergence is critical characteristic of its input-output behavior. One that Little’s Law shows us how to calculate quite precisely.

Thinking about convergence and divergence gives us a much richer vocabulary for reasoning about the relationship between micro behaviors of the system over short operational windows and macro behaviors of the system over long sample paths.

Convergence vs Stability

It is important to understand that convergence, as defined above, is more general than the concept of “stability” often discussed in the context of flow metrics.

Little’s Law states that the long‑run relationship L = λ × W holds as long as the limits L, λ, and W exist. It does not require these limits to remain constant over time. In convergent systems, these values can and do change, and when they do, they are still constrained to obey Little’s Law—just as in the finite‑window form.

We will reserve the stronger condition of stability to those systems where the finite limits of the long run averages themselves stay constant over time. Many repetitive and assembly line processes satisfy this condition, but software development processes often don’t, and they don’t need to for Little’s Law to apply.

In this sense, Little’s Law applies for equally to linear and non-linear system, complex adaptive systems, deterministic and stochastic systems, and even certain types of chaotic system.

Such systems may be convergent, and Little’s Law may apply with different parameters over different periods of time. but the system is not stable or predictable in the sense that we normally associate with stability.

Fig 4 shows some of the possibilities here (there are many more). Certain processes like CI/CD pipeline can be strictly stable like in the first example. The second example of meta-stability, where the system remains convergent, but the limits in Little’s Law shift over time is characteristic of most processes that involve humans and machines. Truly chaotic processes are rare in the SDLC, but not impossible. Every one of these behaviors is convergent.

And all these process can tip over into divergence if the system is structurally unbalanced (they can also usually be brought back into convergence). The power of the law is that it does not care about what kind of system it is internally. And every one of the different types of systems described above can exhibit both convergent and divergent behaviors depending upon the structural balance that the existence of the limits implies.

But we can use still reason about these systems with Little’s Law, both over any finite window of time, or over long sample paths, using the appropriate definition of the averages.

So far from being a tool that lets us look at simple, linear or deterministic systems, Little’s Law in its more general form is one of the most powerful general purpose analysis tools available to us for analyzing input-output system regardless of their internal structure or behavior.

This type of reliable “black-box” analysis of systems can provide very valuable first pass insights into how a system behaves, without having to know any of the internal details about the system or having to know what kind of system we are dealing with.

Equilibrium and Coherence

There is another, very useful way to think of the difference between observing an input-output system over short fixed observation windows vs observing it over a long, continuous sample path.

We can think of the fixed finite version as a point in time snapshot of an typical operator’s view of the system. In general, for real-time reasoning, it is reasonable to assume that we make decisions not over complete histories, but only the parts we can observe. We will need to estimate parts of the system history that it cannot observe. The fixed window version captures this very well.

The steady state version reflects what the items (or customers) themselves experience from the system over the long run - but their “experience windows” may not always align with the operators observation window.

“Equilibrium” can then be considered as a state where the operators view aligns with the customer’s view. It is a state of epistemic coherence across different observers in the system, where they each make their own measurements and end up agreeing on their values (within some error tolerance).

Both perspectives are hugely important, but the advantage of the finite version is that we can reason about the operators view locally using the finite version of Little’s Law from moment to moment with only partial information, and also get a sense of how far away from “equilibrium” the system is over a given finite observation window. The finite version is usually much more volatile. The equilibrium view provides a slower changing perspective of the macro behavior of the system.

Operationally, having both views in perspective is a big deal in software development, because we are typically operating far from equilibrium. Most operational tools that measure flow metrics don’t make this distinction, and there is a lot than can be improved on this front.

There is much more ground to cover on operationalizing all this. The references at the end of this post are a good starting point, and we will have more to say about this in future posts.

But let’s continue our exploration of Little’s Law by examining an even more general version - this is an economic interpretation of the law, and it is considered the most general form of Little’s Law.

𝐻 = λ × 𝐺: the economic version of Little’s Law

What is truly remarkable about Little’s Law and something that is rarely exploited is that the same conservation principles holds even when we’re not tracking time accumulated by items, but some other time varying quantity: costs, risks, revenues, profits etc that can be tied back to the items.

In this framing, suppose each item contributes some “value” to the system expressed as some at a time-varying function: call it fₖ(t), for item k. So instead of a set of items, we have a set of time varying functions of items.

Lets look at a single instant of time. Summing all contributions across the functions gives H(t), the total value accumulation rate in the system at time t. Similarly looking across all the items and computing the cumulative value of each function over time gives us G_k the total value contribution from item k.

Similar to L = λW can define:

• H = long-run average value of the accumulation rate H(t)

• G = average value contribution per item 𝐺 across functions = ∑𝐺ₖ ⁄𝑛

• λ = arrival rate of items

Then using the same approach of measuring these parameters along a sufficiently long sample path we can derive both finite and steady state version of Little’s Law the leads to the most general form of Little’s Law that states that if the long run values λ and G converge to finite limits, so does H and then

This general form opens up a much wider set of modeling possibilities. We can use it to model the time varying interaction of complex functions of items - for example how risk accumulates, how customer satisfaction scores rise, or how delay-related cost builds over time—all without relying on any specific process model for the underlying behavior: just observed input output behavior.

In short this is a mathematically rigorous, and operationally tractable way of modeling the physics of the “flow of value” and not just the flow of “work”.

When modeling the flow of value in value networks, this formalism and Little’s Law in this general form will prove to be a valuable analytical tool.

But there are many, many more useful ways in which this general form of Little’s Law can be exploited and we need much more machinery in place to make this easier to use and apply in practice settings.

We discuss this in the section on further reading at the end of the document.

Why Little’s Law matters

When applied correctly, Little’s Law gives us something rare: a strict constraint across quantities we can observe. If two change, the third must follow. It doesn’t tell us what will happen. It tells us what can’t happen. It works as a check on our measurements, as a signal for divergence, and as a very sensitive set of levers by which we can actively steer systems that operate far from equilibrium.

But for that to work, we need to stop treating Little’s Law as a formula that only applies to stable factories, and realize that treating it as a conservation law allows is to use it meaningfully for general input-output system including nonlinear and complex adaptive systems that are never in equilibrium for long.

For software teams, this means:

• Use the finite-window form (L = Λ × w) for real-time analysis across normal operational windows.

• Use the classical form (L = λ × W) once you’ve validated convergence using sample path analysis - report these as the system level flow metrics and use these to target system improvements.

• Think in terms of identifying sources of divergence and feedback mechanisms to move divergent systems into convergence.

• Use time-value generalizations (H = λ × G) to measure and manage accumulations of costs, risks, benefits and rewards that can be modeled as time-dependent functions of items.

There is a whole other parallel set of “flow systems” with mathematically precise semantics that we can build on top of our familiar flow system built on the flow of discrete work items.

Little’s Law is the foundation for building such models.

Further Reading

In this post we made a lot of general claims without too much by way of detailed explanations or proofs to back them up. What we have described above is a summary of nearly 50 years of research and development in both academia and industry in the field of operations research.

Much of this research, its history and its significance seem to be unrecognized in the software industry and this post was intended to provide a broad strokes introduction.

While Little’s Law started out as a simple empirical observation about waiting lines in operational settings, it has led to deep and lasting mathematical results that revealed that it is a much more fundamental law than the simple throughput formula we are all familiar with.

Of course, all this needs more than hand-waving to make real in an operational setting. If you are interested in understanding the underlying theories and arguments in more detail and how to start applying these ideas in practice here are a few follow up resources.

1. The best reference source for understanding the theory and history of the law is the survey paper, “Little’s Law on its 50th anniversary,” that Dr. Little wrote on the 50th anniversary of his original proof of the law.

2. For a much more detailed version of the current post, and one that builds upon this survey paper and introduces the ideas here in a form that is more meaningful to folks in the software development community - see my post “A Deep Dive into Little’s Law”. This has a detailed list of references that I feel are directly relevant for applications in our domain.

3. “Sample-path analysis of queueing systems” by El-Taha and Stidham is the definitive reference to the mathematics underlying all these ideas and much more. This is mathematically dense read and is not meant for practitioners. Its useful if you want to learn and understand why the results we will leverage in applications are true.

4. But if you are less concerned with theory and want to start applying these ideas directly, all this material is the foundation of The Presence Calculus, a reframing of the underlying techniques used in proving Little’s Law in all its forms, into a modeling and measurement substrate that is easier to apply and use in practice and also for us to build operational tooling around. I expect to be writing much more extensively on this topic in coming weeks, but a fairly comprehensive overview of the presence calculus can be found in our introductory document The Presence Calculus: A Gentle Introduction.

5. The Presence Calculus Project website has all the material that we will be publishing on this topic - including papers on the formal theory behind the calculus as well as the practical application use cases.

6. The Presence Calculus Toolkit is an open source library that we are building to operationalize the concepts in the presence calculus. It is not yet ready for production use, but we plan on using this as a reference implementation for the measurement and modeling primitives of the presence calculus.

Post script: For those of your familiar with the Little’s Law through Wikipedia and or queueing theory texts, you might be surprised that we have introduced Little’s Law without referring to queueing theory, stochastic processes, or probabilistic assumptions like ergodicity and stationarity, that are typically understood as being required for Little’s Law to hold, and as originally proven by Dr. Little.

In fact, Dr. Stidham’s proof of L = λ × W showed that all these were superfluous conditions and that the law was a completely deterministic result that could be applied to both deterministic and stochastic systems without knowing what kind of system it was.

We cover these proofs and their history in more detail in our deep dive into the history and proofs of Little’s Law.

Dr. Stidham’s sample path analysis technique, which yields a proof of Little’s Law as only one possible application, is a much more fundamental and powerful tool and we operationalize in the presence calculus.

In our last episode, we introduced the notion of value exchanges and collaboration protocols. We used the example of a neighborhood coffee shop to show how we could define value streams as collections of value exchanges in a value network.

This definition of value streams has the advantage of identifying value streams by the value proposition and the characteristics that define how providers and receivers collaborate and assess whether they receive value from a collaboration rather than operational details of how either one fulfills the value proposition. 

The value exchange represents the receiver and provider's mutual value assessment process. Each exchange that provides reciprocal benefits enhances the flow of value within the value stream.

The last episode focused mainly on the collaboration protocol and discussed how the two parties assessed value only in high-level terms. Further, the coffee shop was a relatively simple example of a value exchange: providing a repeatable service experience in return for money.

In this post, we will discuss a general structure for the value exchange and look at some more complex examples of value exchanges that we can model using that definition.

Value Exchange Models

This episode is part of a series on Value Networks. Verna Allee developed this modeling technique in the mid-seventies through the early 2000s. It provides a robust formal foundation for reasoning about value in a fundamentally novel way. 

The Value Network is a straightforward concept built from three simple primitives: roles, transactions, and deliverables. Roles represent (groups of) people and their roles in value-creating collaborations. Transactions represent interactions between roles, where one delivers something to the other. 

Our last episode has a detailed example of a value network and how collaborations are defined in this network.

The key idea behind value networks is that instead of modeling abstract processes, we model how interactions between people create value, and this concept scales from individual interactions to networked ecosystems of people and resources.

A collaboration is a coordinated effort between roles in a value network to achieve shared or complementary goals or desired outcomes. The structure describing the interactions between the roles in a collaboration is called a protocol.

In our last episode, we showed a few examples of collaboration protocols in a value network for the coffee shop, and how they gave rise to distinct value streams in the network.

With this as a preamble, let's formalize the definition of “value exchange.”

In a value exchange model, the deliverables are the tangible or intangible outputs exchanged, while the value model captures the value outcomes expected and derived by each party.

A value exchange model describes the value semantics of a collaboration. It provides a framework for assigning a multi-dimensional score to an instance of collaboration based on an independent assessment of the deliverables exchanged by two roles: the provider and receiver.

In a value exchange, the provider presents a value proposition to the receiver. The parties then evaluate the deliverables exchanged using a value model as a rubric. Both parties assess the collaboration using desired and undesired attributes from the value proposition, describing the value generated from the exchange.

The assessments may be subjective or objective and may or may not be directly observable or measurable1. The value model is an abstract representation of a decision process that measures value in a value exchange.

The dimensions, structure, units of measurement, and assessment criteria will depend on the context. However, we can identify the model's components.

1. A collaboration with a set of protocols and two identified roles, a provider and a receiver.

2. The value proposition2 states the desirable and undesirable outcomes regarding the attributes of the tangible and intangible deliverables exchanged in the collaboration.

3. Value-at-Exchange (VE): The shared value assessment between the provider and receiver catalyzes the exchange. It may be expressed as a monetary payment, barter, or as other intangibles, but it describes the exchange's underlying drivers and value expectations. The critical thing to note about value-at-exchange compared to the other two components is that it records the value perceived by both parties in engaging in the exchange at the time of the exchange.

4. Value-to-Receiver (VR): This is the totality of benefit or utility to the receiver from the exchange. It could be functional (e.g., a product's features meeting a need), emotional (e.g., satisfaction or trust), symbolic (e.g., status or affiliation), or some other combination of all the above. These are evaluated using the assessment criteria of the deliverables from the provider as assessed by the receiver. Value-at-exchanges includes components of the value-to-receiver.

5. Value-to-Provider (VP): This represents the totality of benefits the provider receives from the exchange. It could include revenue, profit, reputation, customer retention, or any other measurable gain that makes the exchange worthwhile for the provider. The value may also include long-term strategic outcomes like increased market share or customer lifetime value for the provider. These are evaluated using the assessment criteria of the deliverables from the receiver as assessed by the provider. Value-at-exchanges includes components of the value-to-receiver.

VE may also include assessments of the attributes of the collaboration experience that are valuable to either role, such as speed and efficiency in completing the collaboration. While value-at-exchange is typically known at the time of exchange, some components of value-to-receiver and value-to-provider may not be fully known until after the exchange.

Sometimes, the value received is realized over more extended time frames. In many other cases, the value obtained may not be attributable to a single value exchange but the cumulative result of many related and independent value exchanges between the provider, the receiver, and other parties.

A party may even enter into an exchange when they understand that they may not receive value directly from it, i.e., no value-at-exchange, provided they believe they will eventually receive value as a cumulative result of future value exchanges.

In the Zeptos example, there is no real difference between value-at-exchange and the other two components. Here, both parties can evaluate an entire collaboration at or close to the exchange time. All value exchanges happen instantaneously.

This is not generally true, so in those cases, we record the value assessment at the time of exchange using value-at-exchange and separately specify the other two components.

This is necessary to model complex scenarios, such as deferred value creation, value created through network effects, and interactions with other value exchanges.

As we will elaborate in later posts, the outputs VR, VE, and VP from the value exchange model are best viewed as inputs into a larger causal model for the network's value flow.

But first, let’s look at another example to illustrate a more complex value exchange.

An automobile

Durable goods or high-ticket items like automobiles surface more interesting questions about modeling value exchanges.

While the value-at-exchange is often shaped by straightforward factors like price, utility, and brand reputation, the value-to-receiver and value-to-provider incorporate longer-term considerations such as reliability, maintenance costs, and residual value. The protocol between the buyer and dealer to successfully buy an automobile is often complex, and this buying experience can significantly impact the buyer's perception of value.

Further, whether a transaction is a purchase or a lease significantly impacts the value exchange3. In a purchase, the buyer takes ownership of the vehicle and, in addition to its base utility, focuses on long-term considerations like reliability and residual value. In a lease, short-term affordability, flexibility, and terms take precedence.

For the provider, leasing offers recurring revenue and retention opportunities, whereas purchases deliver higher upfront profit. Since the provider retains ownership of the vehicle, leasing carries risks, such as uncertainty about depreciation and potential losses if the vehicle’s residual value falls short of projections.

Notably, the cumulative value to the customer or provider often remains unclear until a subsequent vehicle transaction, such as resale, trade-in, or lease return, reveals how well the car met value expectations over time. These are also subject to external factors like the state of the economy, interest rates, etc. Nevertheless, they may impact the sustainability of the value stream between the buyer and the dealer.

Therefore, the flow of value between dealer and buyer is multifaceted and evolves as immediate factors like price and contract terms interact with longer-term considerations such as reliability, residual value, and the outcomes of subsequent exchanges. Transactions such as selling, trading in, or returning a leased vehicle or service costs over time clarify the true value both parties realize.

For buyers, they highlight how well the vehicle met expectations, while for dealers, they involve managing residual value risks, reselling opportunities, and fostering customer loyalty for future business.

It is impossible to truly speak of this value network's “flow of value” without modeling these particulars in an explicit value model.

More Examples

While the examples above may have given a flavor of what is involved in creating a meaningful model for the flow of value in a value network, they are just the tip of the iceberg regarding the subtleties involved.

As an exercise, the interested reader can consider how they might model other value networks and value exchanges within them, such as

• Extending the Give Review transaction in the Zeptos example to include reviews given on a third-party site.

• Two-sided marketplaces, such as food delivery or rideshare platforms, involve an intermediary in the value exchanges between providers and receivers.

• Financial transactions, including buying, selling, or shorting stocks in the stock market.

• A social media platform as a value network.

• The relationships between a company and its employees as a value network.

Modeling the flow of value in these types of networks can provide fascinating insights into reasoning about “value.” We will continue to post occasional examples of such exchanges on this blog.

From Goods to Services

Both value exchange examples discussed so far involve tangible goods exchanged for money, a model that dominated economic discourse throughout the 20th century. In the 21st century, however, intangibles like software IP, information services, and technology-powered business networks have become the primary drivers of value creation.

Value exchanges and value models in these networks are far more nuanced, involving intangible exchanges, value creation through network effects, and delayed or deferred value realization for network participants. Most businesses today are service-oriented, with tangible goods, if any, subordinated to the services they provide to customers.

Services leverage the knowledge and skills of participants directly within the network, often augmenting and enhancing tangible goods that package other forms of expertise. Software products exemplify this shift, representing some of the most complex and dynamic forms of value creation that blend goods-dominant and service-dominant4 dynamics. These changes fundamentally transform how value is created and exchanged beyond the straightforward exchanges of tangible goods for money.

In a goods-dominant economy, value creation could be compartmentalized: product development, production, distribution, and marketing were distinct “activities,” with each “adding value” sequentially to a tangible deliverable until it reached the customer. The “added value” is reflected in the value-in-exchange, typically in the price.

In our next post, we’ll argue that much of the current thinking around Lean value streams is deeply rooted in this goods-dominant model. While effective for its time, this framework fails to address the complexities of value creation in a service-dominant economy. We propose that value networks and value exchanges are better suited for this purpose and specialize naturally for goods-dominant value streams.

Lean value stream concepts are still valuable for analyzing and improving the “flow of deliverables” within a value network, where much of the true focus of value stream management remains.

Still, the broader “flow of value” often remains obscured at that level of detail in service-dominant value networks, and it is worthwhile to examine the definition of value streams more critically in this light.

The key flaw in current value stream management practices is that they conflate the “flow of value” with the “flow of deliverables.” While this conflation works somewhat in a goods-dominant domain, it certainly does not work in general service-dominant domains.

So, in these domains, we need to start by clearly understanding the “flow of value” in the value network before focusing on improving the “flow of deliverables” within it. As we have seen in the Zeptos and automotive retail examples, this separation of concerns is appropriate even in nominally goods-dominant domains like automotive retail once you factor in all the services involved in value creation.

In the next episode, we will describe the differences between services-dominant and goods-dominant value streams and discuss what this means when identifying, modeling, and managing them.

Acknowledgments: Mark Smalley introduced me to the concepts of service-dominant logic, for which I will be forever grateful. Tom Gilb was kind enough to review an early draft of this post and gave me insightful feedback that I am still digesting. Marc Charron reviewed this post while it was still part of the previous post and encouraged me to break it up into two posts :)

Zeptos is your neighborhood coffee haven, serving top-notch single-origin coffee, locally sourced pastries, and a cozy vibe. It’s the go-to spot for walk-ins, dine-ins, and work-ins. Complete with blazing-fast Wi-Fi and a welcoming workspace. Sip, savor, or settle in—Zeptos has you covered.

In our last episode, Value Streams and Value Networks, we introduced the idea that a value stream can be viewed as an emergent flow of value within a value network, where the unit of "flow" is an abstraction called a "value exchange."

That discussion was rather abstract and theoretical. This episode will bring matters back to earth with a straightforward, worked-out example to illustrate key concepts.

Value Networks

This episode is part of a series on Value Networks, a modeling technique developed by Verna Allee in the mid-nineties that provides a robust formal foundation for reasoning about value in a fundamentally novel way.

The Value Network is a straightforward concept built from three simple primitives: roles, transactions, and deliverables. Roles represent (groups of) people and the parts they play in value-creating collaborations. Transactions represent interactions between two roles, where one delivers something to the other.

The deliverable may be tangible or intangible.

For our purposes here, this simple definition suffices to understand the material in this episode.

Previous episodes have explored this model and its applications to modeling complex systems for value delivery.

An Example

Let’s use a neighborhood coffee shop, Zeptos, as a running example of a business value network. Figure 1 shows the network.

We model only two roles: Zeptos represents the people who own and operate it, and Visitors represent those who use its services. In addition to providing coffee and pastries, Zeptos also provides a free workspace for visitors, who are not obliged (but encouraged!) to dine in when they visit.

Figure 1 shows the transactions in the value network, which are detailed in Figure 2. A transaction's deliverables may be tangible or intangible.

The tangible ones (shown in blue) are easy to understand. Still, the intangible ones, such as the ambiance Zeptos creates for its customers and the vibe the customers bring to the store, are equally important and, in some sense, more important to fulfilling the Zeptos value proposition.

Similarly, the deliverables in information exchanges between visitors and customers, such as the signage advertising the benefits or the process for taking orders, may be tangible or intangible but are crucial components of the value network.

The value network model highlights that “value,” even in this simple case, is a complex, multi-faceted affair involving complex exchanges of goods and services.

We will break down the process of analyzing value into simpler logical building blocks that we can use to reason about more complex scenarios consistently.

Collaborations and protocols

A collaboration is a coordinated effort between roles in a value network to achieve shared or complementary goals or desired outcomes. The structure describing the interactions between the roles in a collaboration is called a protocol.

Formally,

A protocol is a sequence of transactions between roles in a value network, defining the transfer or exchange of deliverables necessary to achieve the desired outcome of the collaboration.

The deliverables exchanged may be tangible goods or money, or intangibles like information or experiences

Structurally a protocol is a sequence of directed edges1 in the graph representing the network's roles and transactions, representing a temporal order in which the transactions occur in the collaboration.

It is typical for a collaboration to contain multiple protocols representing alternate sequences by which the collaboration may achieve its outcomes.

Here are some collaboration protocols in our coffee shop value network, each representing a collaboration between Visitors and Zeptos.

{Visit Shop}

{Visit Shop, Order Coffee, Serve Coffee, Pay Money}

{Workspace Available, Visit Shop, Provide WorkSpace, Provide Ambience}

We are particularly interested in collaborations that result in a reciprocal exchange of deliverables between key roles2.

We define a value exchange as a protcol that results in at least one reciprocal transfer of deliverables between two roles in the network.

The second and third protocols involve reciprocal exchanges of deliverables, which are thus value exchanges.

Let’s examine one in more detail.

{Visit Shop, Order Coffee, Pay Money, Serve Coffee, Give Review}

This protocol involves multiple reciprocal exchanges. Visualizing protocols as an interaction diagram between the roles involved is helpful.

In a value exchange, we expect arrows to go in both directions in the visualization and +/—signs to appear on both sides of the exchange. In this example, the protocol involves only two roles, but generally, a protocol representing a complex exchange may involve many intermediate or supporting roles.

In our model, a core principle is that sustainable collaborations are built on reciprocal value exchanges where each party can independently evaluate the collaboration’s value by assessing the deliverables exchanged over the course of the collaboration.

This ensures collaborations remain mutually beneficial and are grounded in contributions that can be objectively and independently assessed by all parties involved.

A value exchange is a construct with significant expressive power to model the flow of value.

Its use cases extend across a spectrum, including:

• Simple two-party commercial exchanges and complex interactions involving multiple participants in a value network.

• Exchanges that generate value over short periods and those that unfold over extended time frames.

• Exchanges that produce tangible, measurable value and that create intangible value, observable or quantifiable, only indirectly.

By modeling the structure and drivers of these value exchanges in detail, defining what 'value' means for each exchange, and analyzing the history of exchanges within the network over sufficiently long time frames, we develop a disciplined method for reasoning about the 'flow of value' in the network.

Protocols vs Processes

It is important to understand that a protocol differs from a process. In a protocol, the deliverables from one transaction do not necessarily serve as inputs to the next transaction. In complex multi-party protocols, sequential transactions may involve entirely different roles and function independently.

The relationship between protocols and processes can be viewed as complementary: protocols specify which roles produce which deliverables and map the overall flow of tangible and intangible deliverables required for a collaboration to succeed. Conversely, processes represent the internal activities or workflows within a role that produce those deliverables. These processes may be simple and repeatable or complex and collaborative, i.e., another collaboration.

For example, in the protocol above, the Serve Coffee transaction naturally corresponds to a key business process. However, the protocol situates this process within its broader human context, capturing tangible and intangible interactions between people that contribute value to the collaboration. At this level, we are less concerned with the operational details of serving coffee and more focused on modeling the factors that shape the customer’s experience at Zeptos. This approach allows us to evaluate how to create and maximize value from the overall experience.

Protocols emphasize how deliverables fulfill a value proposition by linking their attributes to the desirable and undesirable factors that define the value proposition, ensuring alignment with the collaboration's goals.

Let’s look at this by continuing our example.

Customer Collaborations at Zeptos

The owner of Zeptos has created a compelling value proposition.

Zeptos is your neighborhood coffee haven, serving top-notch single-origin coffee, locally sourced pastries, and a cozy vibe. It’s the go-to spot for walk-ins, dine-ins, and work-ins. Complete with blazing-fast Wi-Fi and a welcoming workspace. Sip, savor, or settle in—Zeptos has you covered.

It appeals to three types of visitors: walk-ins, dine-ins, and work-ins.

While the Zeptos brand stands for expertly prepared premium coffee and pastries and is a base expectation for every customer, each of these three types of visitors defines “value” from their Zeptos experience very differently.

The Walk-In

The walk-in customer is there primarily for the coffee and pastries, but they value fast service more than anything, impacting their perception of value every time they visit Zeptos.

In the walk-in protocol shown below, the visitor places less value on the ambiance and vibe and more on the time it takes to place an order and walk out with a high-quality order. When Zeptos executes this expectation flawlessly, the visitor may return and even give the coffee shop a glowing review.

For Zeptos, the walk-ins represent a customer value stream. They consider the money the customer pays a fair exchange for the value they provide, assuming they can satisfy customer expectations. If not, a negative review from a disgruntled customer may cause a negative net value from a walk-in.

The Dine-In

The dine-in customers value the ambiance at Zeptos and the collective vibe of the customers. They expect prompt service, but their expectations are less stringent than those of the walk-ins. Overall, they spend more time at the shop and are likely to spend more on each visit.

Dine-in customers assess Zeptos value proposition along different dimensions compared to walk-ins. They are much more likely to assess value based on their overall experience at the shop, and Zeptos needs to execute flawlessly on that count for them to feel they have received value.

For Zeptos, dine-in customers present a distinct logistical challenge. Attracting them requires more significant investment in higher-end facilities and staff, which lowers unit margins. However, in certain months, the profits generated from dine-in customers can significantly surpass those generated from walk-in customers.

Dine-in customers represent the second major value stream for Zeptos.

The Work-In

Work-in customers at Zeptos come for a work-friendly environment rather than coffee and pastries. They value comfortable seating, reliable Wi-Fi, and a productive atmosphere without service expectations. They represent visitors attracted by an entirely different aspect of the Zeptos value proposition.

However, these customers often spend extended periods at Zeptos, and 70% eventually order, transitioning into dine-in behavior. This dual role makes work-ins valuable for their workspace use and their contribution to sales during their stay.

Serving work-ins requires investment in workspace amenities, such as comfortable seating, charging points, and strong Wi-Fi, which adds to higher fixed costs. However, their high conversion rates make this a worthwhile investment.

The 30% of the work-ins that don’t convert to paying customers represent an unbalanced exchange for Zeptos. The visitors receive tangible benefits from Zeptos but only intangible benefits in return3.

The work-in customers are the third major value stream for Zeptos.

Customer Value Streams

Here’s why we call walk-in, dine-in, and work-in customer value streams:

1. Stable Value Flows: These represent enduring and consistent flows of value within Zeptos' value network, forming a core part of its business model.

2. Customer-Centric Value Propositions: Each value stream reflects Zeptos' tailored value proposition from the perspective of specific customer needs. The general proposition attracts diverse customers, but each value stream meets distinct customer expectations.

3. Distinct Service Types: While Zeptos operates as a single service entity, these categories signify three unique service types from the customer’s perspective. Each is defined by its specific collaboration protocols and definitions of value.

4. Operational Investments: Delivering these services involves different investments, resources, and processes, aligning with the classic definition of a value stream. These differences are represented in the collaboration protocols that govern each stream.

The “value” in these value streams is a contingent quantity, entirely shaped by mutual expectations and the satisfaction of both parties in each collaboration. Each one can exceed, meet, or fall short of expectations, resulting in a net positive or negative flow of value.

By consistently delivering on its value proposition for each customer value stream, Zeptos stabilizes and creates a coherent flow of value across its network. Customer reviews act as an adaptive feedback mechanism in the network, signaling Zeptos and others when this flow is disrupted.

Ultimately, as we discussed in Value Networks and Value Streams, the flow of value in the network is an emergent phenomenon, observable only when aggregated over many collaborations over time.

What is a value stream?

We’ll close this episode with a definition.

A value stream is a collection of value exchanges that describe value-creating collaborations between two roles in a value network.

In this definition, a value stream's identity is determined by its value proposition, the deliverables produced, and the criteria by which participants evaluate those deliverables against the value proposition. This perspective centers value streams around what is delivered and how value is perceived rather than how it is delivered.

A more formal explanation of this perspective requires additional conceptual tools, which we’ll explore in the next episode. However, it’s essential to note that value stream identity is established by defining the nature of value delivered, leaving the delivery mechanisms to the value stream model.

This marks a key departure from Lean value streams, which focus primarily on the delivery processes. Of course, we address these processes in the value stream model, but we explicitly model the “value” in “value streams” before doing so.

In a future episode, we will dissect the differences between these perspectives.

Key Takeaways

1. Value exchanges form the building blocks of value streams, representing reciprocal exchanges of deliverables between roles in a value network.

2. Collaboration protocols define the structured interactions between people required to achieve specific outcomes, emphasizing tangible and intangible deliverables.

3. Distinct customer value streams emerge when services are tailored to meet specific expectations and experiences through customized collaboration protocols.

4. The Zeptos example gave us three value streams: walk-ins, dine-ins, and work-ins. Each is shaped by tailored collaboration protocols and customer-centric value propositions. Customer reviews provide adaptive feedback to manage these value streams dynamically.

5. Stable and coherent value flows emerge when mutual expectations are consistently met for each value stream.

6. In contrast to the Lean perspective, value stream identity is determined by the value delivered and how it is perceived rather than the processes involved in delivery.

Looking Ahead

This episode focused on how value exchanges and collaboration protocols define customer value streams within a value network.

However, value networks are not static; they evolve through feedback, long-term dynamics, and internal interactions. In future posts, we’ll explore how feedback mechanisms like customer reviews guide the network’s adaptation, how sustained value exchanges shape its growth and stability, and how internal value streams, such as supplier relationships and staff workflows, interact with customer-facing streams to create a cohesive value network.

These deeper models will help us understand the full potential of value networks in modeling complex systems.

Acknowledgments: Marc Charon read this post's early drafts and provided valuable feedback, which improved it greatly. Thank you!

Quantifying Value

In the software product development world, we approach some big questions in an ad hoc manner, among these:

• What does our customer value?

• Are we building a valuable product?

• How does improving efficiency create value?

“Value” remains an abstract input into how we think about our product development systems.

• While we use “value” and “impact” to characterize our system's effectiveness, few generally accepted definitions of these terms or ways of reasoning about what “creating value” or “having an impact” means exist.

• We discuss the “flow of value” in almost all aspects of our process and system improvement efforts, but it has no formal or commonly accepted definition.

• There is a lot of focus on efficiency, and we have many structured methodologies and tools to make the processes in our value streams more efficient. Yet, fewer ways exist to explain the relationship between efficiency and value.

As a result, anyone can claim to “create value” or “improve value” without having to prove it.

Almost every framework or methodology used in the software industry today—for process improvements, organizational design, or capability improvements—is deficient in this sense.

This post proposes a solution, mainly to bring greater focus to this sizeable grey area and help spur more discussion and conversations about the concept of “value” and the related concepts of “flow of value” and “value impact.”

Value Networks and Value Exchanges

This post is part of a series on Value Networks, a modeling technique developed by Verna Allee in the mid-nineties that provides a robust formal foundation for reasoning about value in a fundamentally novel way.

The Value Network is a straightforward concept built from three simple primitives: roles, transactions, and deliverables. Roles represent (groups of) people and the parts they play in a value-creating collaboration. Transactions represent interactions between two roles, where one role, the provider, delivers something to the other, the recipient. The deliverable may be tangible, or intangible.

The semantics of “value” in this transfer are subtle.

Assuming it costs the provider something to have a deliverable in their possession, we can only say the deliverable has value to the provider.

In this sense, every transaction leaves the provider with a value deficit2.

We cannot truly understand the value the recipient places on what they receive until the provider gets something back from the recipient.

So reciprocity is crucial in defining the “flow of value.”

A “value exchange” is a reciprocal interaction between provider and recipient in which each party exchanges something they value with the other3.

Most economic transactions are value exchanges, where goods and services are exchanged for money. Still, the concept generalizes well beyond that when considering intangible deliverables as part of the exchange.

My favorite example of value exchange is the scene from The Blues Brothers, where Jake wonders what happened to their Cadillac.

Jake traded the Cadillac to Ray and received a microphone in return, and each party was satisfied that they had gotten the better deal in the value exchange.When Elwood tells Jake he traded away the Bluesmobile for a microphone, it takes only a brief second for Jake to respond, “I can see that.”

Because neither party experienced a value deficit in the exchange, and indeed, both considered that they gained “value,” the value exchange benefitted both parties, and there was a natural “flow of value” in the exchange.

Value exchanges are the fundamental building blocks of a sustainable value creation system. Parties exchange things of value with each other, and as long as the perceived value of the thing each party receives is greater than the thing they traded away, each party finds “value” in the exchange.

As long as parties continue to transact, the network has a sustained flow of value.

Reciprocity is essential to sustaining the network.

It is the foundation of the market economy.

The Flow of Value in a Business Value Network

Let’s develop this concept further by formally defining the “flow of value” in a business value network.

In a business value network, the roles represent economic entities such as companies, their customers, suppliers, partners, etc. Our earlier post on Value Network Mapping discussed the business value network. Figure 2 reproduces it from that post.

To model the “flow of value,” let's assume we identify all the relevant value exchanges in the network. For example4,

• The company provides the customer with access to the AssetManagerPro product, and the Customer pays subscription fees in return.

• A large Distribution Partner provides its customers with access to the company, and the company pays a portion of the revenues from those deals back to the partner.

If we augment the value network with state and transaction history5, we may define the “flow of value” as the history of those value exchanges.

It is important to note that with these definitions, the “flow of value” is a concrete, measurable construct that we can extract from the transaction history of a business value network.

At this level of detail, we are not concerned with the internal details of the value exchanges; we are just concerned with their history, the roles involved in transactions, and the types of value exchanges.

In practice, network transactions can be instrumented and traced back to customers, suppliers, etc., with specific demographic or business profiles, contracts with concrete terms, prices, costs, etc.

Sales, signed contracts, cancellations, product churn, returns, etc., delineate the boundaries of typical value exchanges of interest and give us high-level insights into the flow of value and value-creation dynamics within the network.

Using value exchanges as the unit of value ensures that measurements and improvements in the "flow of value" focus on actual value being delivered between parties. 

We can use this to define an associated definition of “value impact.”

A change in the value network will be defined as having a “value impact” if it produces an exceptional6 change in the flow of value in the network.

In later posts, we will have more to say about defining and measuring value impacts.

A Value Network as a Complex Adaptive System

As defined above, a value network models a complex adaptive system.

The flow of value in a value network is an emergent phenomenon resulting from the independent decisions of individual network participants to seek each other out and engage in value exchanges. A value exchange succeeds only when a recipient seeking a a benefit transacts with a provider offering that benefit on mutually acceptable terms.

The emergent nature of the flow of value means that it cannot be managed or controlled by any single party in the network; it can only be influenced through strategic actions by network participants that offer incentives for parties to participate in value exchanges.

Reciprocity and Stability

In a value network, reciprocity in value exchanges is the fundamental stabilizing mechanism for the complex adaptive system.

These exchanges, representing the mutual transfer of benefits between participants, provide the structure and feedback needed to maintain balance within individual interactions and move the system closer to equilibrium.

Balance occurs when the value exchanged is perceived as fair and mutually beneficial by both parties—recipients feel their needs and desires are met. At the same time, providers receive adequate compensation or strategic benefits in return.

This alignment ensures ongoing participation and satisfaction for both sides.

When such balance is consistently achieved across value exchanges, it maintains equilibrium, stabilizing the overall flow of value and preserving the coherence of the collaboration.

By contrast, if the value delivered by one party is not reciprocated, it ceases to function as an exchange and disrupts the balance within the value network.

This imbalance can erode trust, as the provider may feel exploited or undervalued, while the recipient might view the provider as unsustainable or unreliable if the imbalance continues. The provider incurs opportunity costs, expending resources on unrewarded efforts that could have been directed toward more sustainable exchanges.

Over time, the lack of reciprocity can lead to the breakdown of relationships, discouraging further engagement and disrupting the flow of value.

Participants may withdraw, and the flow of value fragments.

The collaborations become unstable and lose coherence.

Value Propositions as Signals

What enables two parties in a network to recognize the potential for value exchange?

This is the role of the value proposition.

The traditional view of a value proposition defines it as the provider articulating the unique benefits and value their offering delivers to the recipient, emphasizing how it addresses the recipient’s needs and differentiates the offering from alternatives.

A compelling value proposition distills the provider's understanding of the value dynamics within the network. It is rooted in a deep comprehension of three components in a value exchange: value to the recipient, value to the provider, and value in exchange.

• Value to Recipient: The recipient's benefit from the ownership, possession, or use of a good or service the provider offers. It expresses the provider’s ability to fulfill the recipient's desires, aspirations, needs, preferences, or goals. Value-to-recipient encompasses both tangible utility and intangible benefits, such as satisfaction or prestige of association with the products and services the provider offers.

• Value to Provider: The benefit the provider derives from offering a good or service, typically measured in revenue, profit, market share, or strategic advantage. It expresses the provider's ability to capture sufficient value-in-exchange to cover costs, generate returns, and support long-term growth. This includes tangible outcomes, such as financial gains, and intangible benefits, such as brand equity, market positioning, or customer loyalty.

• Value in Exchange: The agreed-upon worth of a good or service in a transaction, reflecting a balance between value-to-recipient and value-to-provider. While traditionally expressed as a monetary price, it may also incorporate intangibles such as brand perception, trust, reputation, and emotional or symbolic associations, which may significantly influence the recipient's motivation and terms for the exchange. Value-in-exchange captures the tangible and intangible drivers of value in a value exchange.

The value proposition distills the provider’s understanding of all three value components in an exchange to communicate the benefits offered to the recipient in language designed to incentivize the recipient to engage in a transaction.

Identifying and communicating value-to-recipient and leveraging it to guide the provider's strategic positioning in the network is crucial for a provider to create and sustain the flow of value in their value network.

In short, the value proposition catalyzes a value exchange. They should ultimately be understood as signaling mechanisms that help network participants maintain coherence within a value network.

• Value propositions communicate the potential for mutually beneficial value exchanges between providers and recipients, signaling opportunities for meaningful interactions and fostering network coherence.

• Clear and compelling value propositions reduce ambiguity and friction in value exchanges and support a consistent flow of value.

• As network needs and conditions evolve, value propositions act as dynamic signals, adapting to demand, competition, or resource shifts. This adaptability aligns participants' actions with the emergent flow of value, maintaining coherence.

• Value propositions capture feedback from past exchanges and incorporate it into their refinement, signaling updated expectations to participants. This continuous refinement helps stabilize and sustain coherence by ensuring that offerings remain relevant and aligned with the network’s needs.

• In a complex adaptive system, coherence arises from shared patterns and purposes. Value propositions contribute by signaling the shared understanding of what value means for providers and recipients.

Value Streams

Effective value propositions attract network participants to providers who can consistently fulfill them, creating coherent and sustained flows of value within the network—flows we call value streams.

Value streams emerge as the confluence of the three components of value in an exchange—value to the recipient, value to the provider, and value within the exchange.

Value stream management is the continuous process of comprehending value propositions, nurturing value streams, and sustaining them by creating and adapting the organizational capabilities required to harness the flow of value in those streams efficiently.

It requires a constant focus on aligning value propositions and internal operations that fulfill those value propositions to facilitate efficient value exchanges and maximize the flow of value.

Finally, it requires the capacity to detect weak signals in value stream flow and adapt value propositions and operations to grow these streams over time. Value exchanges with short feedback loops are essential for this.

Understanding and optimizing value to the provider while balancing it with value to the recipient is a central concern in a provider’s business strategy and operational efficiency and the main focus of value stream management.

Our definition and treatment of value streams as emergent flows of value within a value network might seem relatively unfamiliar compared to the much more familiar definitions of value streams. But, as we will discuss in our next post, these are simply two different ways to look at the same underlying reality.

Value Stream Models

A value stream model is an analytical construct that describes the relationship between the value propositions offered to the network and the provider's internal resources, capabilities, and processes needed to fulfill them.

The value stream model connects the flow of value in the value network to the flow of work within the provider organization needed to fulfill it.

The unifying construct across all these representations is the value proposition, which centers on the customer—the ultimate beneficiary of all the work undertaken.

The model connects the value proposition to the three core value components inherent in each value exchange, which must align to fulfill the value proposition.

In an industrial or repetitive service value stream, the value proposition is typically known beforehand and remains static throughout the value stream's life.

Consequently, the models and representations needed to maintain alignment with the value proposition are simple.

For software products, it is more the norm, rather than the exception, that the value proposition, and by extension the value stream, adapt and change to the flow of value in the value network. The system of processes, people, and capabilities fulfilling the value proposition is a complex adaptive system requiring richer representations.

The value stream model is this generalization. It contains all the representations a provider needs to reason about the relationships between the flow of value in the value stream and the internal systems within the provider organization that sustain it.

It consists of many different perspectives on the flow of work and value, including a model for the value proposition, value stream maps, value network maps, code promotion flow maps, etc. In our last post, we showed, for example, how a value stream map and a value network map represent two views of the same underlying set of activities supporting a sales transaction.

Many such synergies emerge from a value network model.

In the next episode “Value Exchanges and Collaboration Protocols,” we will look at a simple example of a value network and the various value streams that emerge from the value exchanges that occur within the network.

Summary

Here are the main takeaways from this post.

1. Value streams are made of interactions between people.

2. Reciprocal value exchanges between roles are essential building blocks for modeling and measuring sustainable value creation in a value network.

3. A value network is a complex adaptive system model in which effective value propositions attract coherent, sustainable flows of value.

4. Value streams emerge as the confluence of the three components of value to people involved in an exchange—value to the recipient, value to the provider, and value within the exchange.

5. A value stream model contains all the representations a provider needs to support value stream management, which involves reasoning about the relationships between the flow of value in the value stream and the internal systems within the provider organization that sustain it.

6. Adopting value exchanges as the unit of measurement for the “flow of value” ensures that value stream management stays focused on increasing value creation within the network.

Marc Charron and John Siegrist gave valuable feedback on drafts of this post, improving it significantly. Many thanks to both of you!

This is the third episode in our series of posts on Value Networks.

Verna Allee initially developed this mapping and modeling technique and elaborated on it in her book Value Networks and the True Nature of Collaboration.

While she developed these ideas in contexts other than software product development, I believe they help us express the collaborative nature of complex knowledge work in richer ways than many of the techniques we use today to model software development processes.

This post will discuss how Value Networks relate to Value Stream Management in software product development.

Value Stream Management

Peter Hines and colleagues introduced Value Stream Management (VSM) as “a strategic and operational approach to the data capture, analysis, planning, and implementation of effective change within the core cross-functional or cross-company processes required to achieve a lean enterprise1.

This remains an excellent general definition of Value Stream Management, even if the original concepts were developed in the context of industrial production processes and supply chains.

Let’s focus on a few key aspects:

• VSM is fundamentally about improving processes.

• It targets cross-functional and cross-company processes, those that require collaboration across organizational or inter-organizational boundaries.

• VSM has both strategic and operational components.

• It relies on data to analyze, model, plan, and implement system-wide changes.

• The primary goal is to ensure effective change—improving the enterprise's ability to create value more efficiently.

Under this definition, VSM is focused on changes beyond local, continuous improvement efforts (e.g., Kaizen); it emphasizes collaborations at the company and cross-company levels that require coordination among autonomous participants to identify system-level improvements and implement changes2.

While these changes are typically strategically important, they are among the hardest to operationalize. Therefore, a holistic approach to visualizing, modeling, and reasoning about them is critically important.

Value Networks are a powerful tool for tackling this challenge.

Value Networks: A Recap

The Value Network is a straightforward concept built from three simple primitives: roles, transactions, and deliverables. Roles represent (groups of) people and the parts they play in a value-creating collaboration. Transactions represent interactions between roles that exchange something of value. Deliverables represent these things of value and may be tangible or intangible.

Value network mapping aims to identify the roles, transactions, and deliverables in a network of value exchanges.

In our previous episode, Value Network Mapping: An Example, we illustrated how we might model a value network for an example software company, AssetManager PRO. We mapped the value network at three levels of detail and explored choices for modeling the flow of value.

Figure 2 from the last episode shows an example of these levels of detail.

By mapping roles, transactions, and deliverables, Value Networks enable us to capture tangible and intangible value exchanges between participants.

This helps us see the big picture, defining the ‘flow of value’ and revealing key areas where value is created or could be enhanced across the business network.

With these fundamentals, let’s dive into how these models represent the flow of value within an ecosystem.

Modeling the flow of value

At the top level, the business value network, roles represent business entities such as the company, its market, suppliers, partners, and competitors. These are the participants in the product ecosystem.

The business value network serves as the strategic canvas for Value Stream Management, where the goal is to harness and optimize value flows within the network to maximize value for both the company and its customers.

This network is a model of an open, complex adaptive system in which roles are evolving populations of participants, and transactions represent measurable value exchanges between these participants.

The “flow of value” is defined by the value exchanges in the business value network. Transactions between roles and their deliverables represent fundamental, measurable units of value exchanged between participants. These include tangible exchanges such as money and products and intangibles such as brand value, reputation, trust, customer satisfaction, etc. Only transactions that result in a concrete exchange of value, whether tangible or intangible, contribute to the flow of value.

Figure 3 shows the business value network for AssetManager PRO. I recommend reviewing our description of this network in the last episode.

The business value network is, first and foremost, a sensemaking and visualization tool that allows a broad range of stakeholders to come together and build a shared model of the value-creating ecosystem the company supports. This brings greater clarity to our questions about how the product ecosystem creates value.

Constructing a value network model should be collaborative, drawing on diverse stakeholder perspectives to represent the product ecosystem accurately. The choices made when modeling roles and transactions in the network will significantly impact the insights you can derive from them.

From Visualization to Analysis

When we augment the value network with notions of state and history, the visual models can also be extended to build powerful tools to analyze value creation dynamics in the network. 

We may, for instance, define the network's state as the value accumulated with participants based on their history of value exchanges. Transactions cause changes in the network state and may also change population distributions between roles; for example, a successful sales transaction may convert a consumer from Prospect to Customer.

By analyzing the system dynamics of the value network with these definitions: the value exchanges, the population movements between roles reflecting value-seeking behavior, and the analysis of transaction activity over time, we can identify causal relationships to understand value-creation mechanisms within the network.

Systems dynamics models help identify where we can intervene to improve the flow of value in the network and verify whether the changes we make to the system are effective—i.e., do they enhance the flow of value?

In an upcoming post, we will explore how to create these types of systems dynamics models for value networks.

Modeling the flow of work

Once we have modeled the flow of value and identified potential areas for improvement, we can focus on improving the processes needed to support this.

This is the core mission of Value Stream Management. Traditionally, operating model design, organizational design, and lean process engineering have all focused on this topic.

These disciplines focus on the organization’s internal structure, processes, and resources within its boundaries. They position customers, partners, and other external actors outside the system boundary and aim to optimize internal structures, capabilities, and processes to serve these external actors.

The value network offers fresh perspectives here. Since every value exchange in the business value network crosses an organization's boundary, it is helpful to have a way of representing these exchanges that cross the boundaries of the system being analyzed.

In our previous analysis of AssetManager PRO, we introduced the notion of refining a value network, which allows us to zoom in on a value exchange in this fashion.

Every such refinement of a business value network creates a new value network with roles and interactions that cross organizational boundaries. The refined network models the dynamics of these collaborations across organizational boundaries at increasing levels of detail for roles, transactions, and deliverables. We’ll find this technique helpful in analyzing both cross-functional and cross-company collaborations.

The refinement operation is somewhat different from a structural decomposition of the network. Rather than breaking the network into parts and studying how the parts behave, we focus on the interactions between the parts and examine how those interactions behave at greater levels of detail.

Since system behavior emerges from these detailed interactions, refinement is an essential technique for modeling and analyzing value exchanges in complex systems models like business value networks.

In Fig 2, we showed the business value network refined to two levels of detail. Let’s examine these more closely.

Organization Networks

At the first level of detail, we are primarily concerned with how the organization is structured to support the business value network activity effectively.

The refined value network is focused on interactions between teams, departments, etc., within the organizations and with their collaborators outside the organization in the value network.

Figure 4 shows an example of a refinement in which we zoom into the interactions between different AssetManager PRO departments and the market.

Note that we continue to model both “sides” of the value exchange in this network. Thus, there are cross-company transactions (which refine the business value network) and new cross-functional transactions between departments, which we will largely focus on in Value Stream Management.

This refinement can be used to model the impact of changes in the organizational topology on the flow of value in the business value network.

We could also have created refinements using other organizational perspectives, such as teams, or with other external collaborators, such as partners or suppliers.

Transaction Networks

The second level of refinement, the transaction level, zooms into the interactions for a specific transaction using even more detailed roles. Again, we are zooming into detailed collaborations within and between organizations that lead to a successful value exchange in the business value network.

Figure 5 shows the transaction network for a Buying Transaction in the business value network. Note that in our refinement, we have maintained roles for buyers and sellers and that the transactions in this network span organizational and functional boundaries in the asset manager PRO organization.

This is the domain of traditional processing engineering. Value network models are also applicable at this level. However, it is helpful to view them as augmenting the conventional process-oriented perspective focusing on the steps required to create the deliverable (the value stream view) with a collaborative perspective that captures the roles and interactions of internal participants involved in producing these deliverables (the value network view).

Combining value network representation with value stream maps and other related processing engineering tools is feasible and valuable here. Figure 6 below shows a traditional Value Stream Map for the Buying transaction alongside the value network map view from Figure 5 above.

Both maps provide helpful ways of examining the underlying collaborations in the network. The value stream map is much more convenient when reviewing a summary view of the process and where time is spent. It tells you what needs to happen to close a deal successfully and surfaces critical metrics that drive this success rate. In particular, it lets you focus on where time can be shaved off in the process.

The value network view is much more detailed and focuses on who must collaborate to close a deal successfully. Sequencing the map will often yield insights into poor information flows that lead to excessive delays in the value stream map.

In collaborative knowledge work, the real constraints to workflow are often people’s capacity to fulfill their collaboration roles due to incomplete knowledge and information flows and poor collaboration and communication structures.

Looking at these sequences of interactions in the value network reveals a temporal view of this map. These can be used to build causal models for the metrics in the value stream map. You may also drill deeper into each of these transactions with an additional value stream or value network map to model and optimize them in more detail.

Value networks are potent tools for explicitly visualizing, modeling, and reasoning about these collaboration constraints. The example above shows that they effectively complement process-oriented representations like value stream maps.

In her book, Verna Allee demonstrates many use cases for value network models in process improvement. She shows how to use value network maps to optimize complex internal operational delivery process workflows. Her applications often followed a lean process engineering approach to the problem!

We highly recommend reviewing more examples from her book to understand how these techniques can complement each other.

Beyond this level of detail, we can focus on the flow of work needed to produce specific deliverables for the transactions in this network. Since deliverables have a single source role, we are now zooming in within a single organization in a business value network to understand the processes that produce a single deliverable.

We are now squarely in the realm of process engineering, and as shown above, value network maps are one additional tool we can use here.

Summary

One of the most appealing aspects of Value Networks is their simplicity and flexibility. With carefully defined semantics, a single representation can capture and clarify the relationships between the flow of value and work across various levels of detail.

While Value Networks integrate seamlessly with other models, their unique strengths make them particularly effective for modeling complex, collaborative knowledge work.

Value Networks complement and extend existing VSM practices, helping to realize Peter Hines and his colleagues' vision of creating leaner, more collaborative enterprises.

In the next episode, we will study the Buying transaction in more detail to understand the relationship between the flow of work and the flow of value3.

See you next week!

In the last episode, “What is a Value Network? "We introduced Value Networks, a mapping and modeling technique that helps us understand the relationships between the flow of value and work in complex systems.

Value Networks were introduced and developed by Verna Allee, who described them as follows.

“Value networks are the natural way people organize to achieve outcomes. If you define a value network as any set of roles and their interactions that create a specific business outcome, then anything we do together is a value network.

Value networks put people at the heart and center of value creation.”

Her book Value Networks and the True Nature of Collaboration remains the definitive reference. I highly recommend it for a more detailed understanding of the modeling technique and its applications.

In this episode, we’ll work through a detailed example of value network mapping.

I based the treatment here on how I have applied the concepts in the software product development space. In doing so, I have extended some of the core concepts in Verna Allee’s formulation, in some cases, to serve my needs while, I believe, staying true to the original intent.

I welcome constructive feedback on this approach, as it is an evolving practice.

Definitions

We can construct a Value Network from three simple primitives: Roles, Transactions, and Deliverables.

Roles represent (groups of) people and their contributing roles in a collaboration that creates value for the participants. Arrows between roles represent transactions that exchange something of value between the roles.

Value network mapping aims to identify the roles, transactions, and deliverables in collaborations that create value. It places people and their interactions at the heart of the value-creation process.

From this seemingly simple set of primitives, rich contextual models can be created that illuminate the relationship between the flow of value and work in product development at different timescales and levels of detail.

A key feature of value networks is that the “deliverables” exchanged in this transaction may be tangible or intangible. In practice, intangibles constitute a significant component of the “flow of value.” By modeling them explicitly, value networks allow us to build much richer models for value creation.

Mapping a Value Network

The first thing to note about Value Network maps is that they are not unique.

The map you build depends entirely on the purpose of the mapping exercise, including the specific questions you want to answer and the context and boundaries of the system you are examining.

All value network maps share the common feature of focusing on the interactions between roles via transactions, with deliverables being the explicit representations of value exchanged, tangible or intangible.

Value Networks are expected to be highly context-specific and should focus on clarifying the collaboration structures that lead to value-creating outcomes. You should feel free to construct suitable value networks to answer your specific questions.

That said, seeing familiar contexts, granularities, and examples of value networks can help build intuition, and this post offers some examples of what’s possible. While the example we show here has a natural generalization, which we will describe and explore later, I believe there are many more ways to map and model value networks, starting from the basic definitions above.

Therefore, our example should not be considered a definitive way to map or model value networks; it is just an illustration of the concept's generality and the kinds of questions you can answer using these techniques.

If you find the approach intriguing, please explore and share any new insights you uncover by trying other methods to map value networks.

I believe this is an area ripe for exploration and experimentation.

The Example

AssetManagerPro is a SaaS product that helps commercial property owners manage small to mid-sized real estate portfolios. 

The value proposition:

“AssetManagerPro empowers small to mid-size commercial property owners and asset managers with an all-in-one platform that simplifies both financial management and operational logistics with a user-friendly, scalable solution tailored to your specific needs, providing real-time insights into rental income, property metrics, and maintenance workflows—all in one place, at a cost that fits your budget.”

The Value Network Mapping for Asset Manager Pro shows how the product generates value within its ecosystem and connects this to the flow of work needed to achieve the flow of value.

We will construct the map at three levels of detail.

The Business Value Network

At the top level of the value network map, we consider the business ecosystem in which Asset Manager Pro operates.

The business value network represents value-creating collaborations among the company, its customers, and partners. Competitors are also modeled at this level, though not included in this example.

The business value network models the flow of value. We orient our questions about value creation around the focal roles of the business, its customers, and its partners.

Figure 3 shows the business value network for Asset Manager Pro

There are three categories of roles.

• The first is the AssetManagerPro, the focal provider role in this network.

• The second key set of roles represents the consumers1 who might derive value from the product. We have chosen to model these as four separate roles roughly mapped to the product's customer journey.

  • Target Market: The set of all potential consumers of the product

  • Prospects: Consumers who have shown interest in the product.

  • Customers: Consumers who have purchased the product.

  • Former Customers: Consumers who no longer use the product.

  Segmenting a population (consumers, in this case) into multiple roles helps model the dynamics of value creation. Interactions between the AssetManagerPro role and the four consumer roles help uncover different value-creating transactions between providers, consumers, and other players in the ecosystem.

• The third set of roles includes partners, such as distribution partners, marketing channels, industry conferences, and product review sites. This ecosystem broadens the opportunities for consumer exposure to the product, driving more value exchanges between providers and consumers.

The business value network is the ecosystem in which AssetManagerPro exchanges tangible and intangible value with other network players.

For example:

1. Customers gain direct value from using the product (tangible) and, in return, pay subscription fees to the provider (tangible).

2. Large distribution partners offer market access to the provider (intangible) in exchange for a share of product revenue (tangible) and added value to the partner-customer relationship (intangible).

3. Providers gain referral value from satisfied customers promoting the product (intangible), and consumers receive insight from candid negative reviews left by dissatisfied former customers (intangible).

4. Marketing partners run campaigns on behalf of the provider (tangible) in exchange for marketing fees (tangible).

The value network above reveals many more such value exchanges.

The Flow of Value

Transactions in the business value network represent fundamental value exchanges that drive the flow of value within the network.

Metrics such as subscription fees, referral counts, and revenue share percentages provide quantifiable insights into the tangible and intangible exchanges between AssetManagerPro, its partners, customers, and prospects. These can be traced back directly to transactions in the value network.

We can also track the flow of value over time by analyzing population dynamics of roles—such as prospects converting to customers or customers becoming former customers. These population shifts reveal trends in consumer behavior, satisfaction, and brand loyalty, indicating value created or lost.

Combined, transactions, metrics, and population dynamics enable causal modeling of value movement within the network, identifying potential collaboration bottlenecks and uncovering opportunities to enhance value creation.

Consider sales-related transactions in the AssetManagerPro ecosystem as an example.

Standard sales metrics, like closing rate, revenue per customer, and customer acquisition cost, measure success rates and can be traced back to transactions within the business value network.

In the value network model, these metrics are also reflected in observable population shifts between the Prospect and Customer roles, serving as leading indicators of changes in sales performance. Each successful transaction converts a Prospect to a Customer, reflecting the tangible flow of value and showcasing the network’s sales effectiveness. Each failed transaction brings opportunities to reflect on the structural changes needed to improve the probability of success and increase the flow of value in the network.

Subsequent posts will focus on modeling and measuring the flow of value in much greater detail.

However, for now, let’s continue mapping the value network.

Refining Value Networks

Given a set of roles and transactions in the business value network, we can refine2 it to produce a new value network.

These refined value networks focus on modeling the collaborations needed to execute value-creating transactions within the original network and capture detailed interactions across roles in the parent network.

In a refinement operation, we replace some roles and transactions in the parent network with new ones to represent more detailed interactions between those roles and the relevant roles in the parent network.

This layered approach can extend to multiple levels, with each refined network representing more details about the flow of collaborations that drive successful outcomes and enhance the overall value flow in the top-level business value network.

In our first example refinement, we focus on the value exchanges between the AssetManagerPro and Customer roles in the original business value network.

We’ll refine the AssetManager Pro role to a set of departmental roles and add transactions to define the interactions of the new roles with the existing customer roles.

Figure 4 shows the refined value network.

It shows the collaborations between AssetManagerPro at a departmental granularity and each of the four customer segments focused on the customer journey in the business value network3.

We'll call it the “Consumer Value Network.”

Transactions in the network drive the flow of consumers between segments. It takes close collaboration between marketing, sales, and product development to move a consumer from the target market to the customer role. The value network above allows us to visualize and reason holistically about all these interrelated collaborations between departments and the transactions between the departments and consumers in various segments.

A critical difference between the value network perspective is that it is not necessarily limited to the boundary of a single company or organization within it. Instead, we look at the collaborations and deliverables needed to achieve specific outcomes even when they cross traditional functional and enterprise boundaries.

Let us consider one more refinement of the network: the “Buying” transaction in the consumer value network.

We will refine the portion of the consumer value network below anchored around the buying transaction, which moves consumers from Prospects to Customers. In the AssetManager Pro context, closing a sale involves both the Sales and Product Development departments and potential referrals from existing customers.

A successful Buying transaction provides tangible value to the company and the consumer. Even unsuccessful transactions can provide intangible value signals to both departments that help refine the ideal customer profile and the product capabilities that a consumer might find lacking in the current product.

Let us now refine this portion of the value network to detail the collaborations needed to facilitate successful buying transactions.

Figure 6 shows the resulting value network.

The refined network shows the collaborations needed to close a deal and convert a consumer from Prospect to Customer. We'll call this the Collaboration Network for the Buying transaction.

There are a few things to note about the refinement.

1. The Prospect role in the customer value network has been refined into four roles, with a single focal role called the Asset Manager role. This role represents the consumer side value recipient of this collaboration.

2. Additional refined consumer-side roles include financial controller, purchasing team, and IT team, representing other stakeholders who have a say in the successful outcome of a buying transaction in a consumer organization.

3. On the provider side, we have refined the sales and product development department roles into more granular roles that represent the specific roles needed to successfully close a deal for AssetManager PRO. These refine roles in sales and product development departments.

4. The provider roles, such as Demo Giver, Deal Owner, etc., are generic and designed to indicate the role's responsibilities in the collaboration. It is important to note that these roles are not job titles nor imply that different people must play them. The same person may be a Demo Giver and the Deal Owner on any given sales deal, and different people may assume these roles for different deals.

5. The critical point is that refinement focuses on transactions between consumers and providers and the collaborations between roles on each side needed to complete a transaction successfully. The refinement preserves the principle of adding detail to collaboration between roles in the network being refined.

6. The activity network is a bridge representation between the flow of work and the flow of value. It identifies what cross-functional transactions between roles are needed to successfully close a deal (the value-creating transaction) without necessarily specifying the detailed steps required to execute those transactions. That next level of detail usually belongs to more detailed process mapping techniques.

7. Buying transactions can activate this network in various sequences. Rather than tracking each possible sequence, the network representation emphasizes the key roles and interactions common to all company sales transactions. Sequencing, however, can be applied to the transactions in the collaboration network to create a more process-centric view of the activity network.

8. Depending on how we model value streams, sequences in the activity network may also correspond to value streams, providing a natural bridge to value stream mapping. For example, mapping the above collaboration network as a Demo-Close value stream would be perfectly consistent with current value stream management practices. However, it should be apparent that the collaboration network focuses on the people and interactions required to achieve a successful outcome rather than the end-to-end workflow of steps, resources, etc, needed to do this. The latter is the domain of value stream mapping or other process mapping techniques.

9. VDML provides first-class representations of sequences in a value network, providing a formal bridge between the value network representation and more process-centric views such as value stream maps.

The General Picture

I want to re-emphasize that the mapping approach we have taken here is but one possible way to use the very general concepts behind value networks.

That said, I've found that my approach of defining a top-level value network with roles and transactions between a company and its external customers, then iteratively refining key roles and transactions at the department/team and transaction levels to link work processes to the flow of value, is promising.

Figure 7 outlines the general picture.

Throughout the rest of the season, we will expand on these mapping techniques and offer detailed examples that connect value network mapping with other established methods for enhancing visibility, decision-making, and impact on software product development flow.

Up Next

In the next episode, we’ll explore the relationship between value network mapping and value stream mapping. While value streams and value stream mapping are well-established for workflow optimization, I contend that, for software products, these models don’t fully connect the flow of work to the flow of value.

I’ll argue that value streams organically emerge from the flow of value within a value network and are dynamic constructs in the complex realm of software development. The business value network represents the more natural and stable structure of value-creating collaborations from which value streams arise.

Now that we have a concrete example of a value network in a software product context, we can make this argument.

The Entrepreneur and The Queueing Theorist introduced the first significant theme we will explore in more detail in the rest of this season of The Polaris Flow Dispatch: the role of queueing theory in building causal models for the flow of work in software product development.

In this post, we will introduce the second central theme, Value Networks, which help build causal models for the flow of value.

In our post, Throughput != from last season, we argued that when measuring performance, productivity, efficacy, etc., in software product development, we inappropriately conflate the flow of work with the flow of value.

Many of the measurement techniques we use to measure these aspects of software product development derive from those developed in the manufacturing and service industries.

However, a critical aspect of these two domains is that the flow of work is a reasonable proxy for the flow of value.

In software, especially for software products, it is not.

Many of the metaphors we borrow from manufacturing, code as inventory, low usage features as waste, etc., all rely on the implicit assumption that the “things” we produce are what have value.

However, a line of code, a feature, or a novel product capability has no intrinsic value.

In the software product context, the value “flows” only when a product recipient derives some utility from a product, and the user’s perception of this utility determines whether or not something has value.

This “flow of value” happens at a different time scale, level of abstraction, and between different entities. It is often only indirectly related to the “flow of work” required to produce the product.

The Value Network is a model that lets us explicitly make these connections, model the flow of value, and connect it to the flow of work.

Value Networks

Value Networks are a concept developed by Verna Allee. They blend ideas from network theory, complexity science, and value delivery modeling into an intuitive mapping and analysis technique that is very powerful and general despite its apparent simplicity.

In this short video, she beautifully explains the fundamental intuition behind a value network.

Ms. Allee developed Value Network Analysis in the 1990s and early 2000s. During that period, she explored the interplay between Value Network Analysis and other types of network analysis of complex systems and developed this concept in great detail.

Her book, Value Networks and the True Nature of Collaboration explains these ideas clearly. I highly recommend reading it to understand the ideas she presented in their original form.

Ms. Allee's initial Value Network model was more informal and focused on collaborative mapping and analysis of value creation mechanisms.

The Value Delivery Modeling Language standard from the Object Management Group unifies the value network perspective of high-level business value creation with a richer ontology that models characteristics of activities, resources, deliverables, and value contribution.

It provides a comprehensive way to model the relationships between a business's operating model and the value-creating ecosystem in which it operates at varying levels of detail.

Ms. Allee was a key contributor to the VDML standard, which has a much more precise set of definitions and is much more suitable for capturing and communicating these models in a standard way and for building interoperable analytical models and tooling.

For the most part, we will adopt the more precise terminology of VDML while relying on informal visual notations in Ms. Allee’s formulation to describe models.

The Basic Model

A value network is a complex system model built from a small set of abstract primitives: Roles, Transactions, and Deliverables.

Roles represent (groups of) people and their contributing roles in a collaboration that creates value for the participants.

Arrows between roles represent transactions that exchange something of value between the roles. A key aspect of value networks is that the “deliverables” exchanged in this transaction may be tangible or intangible.

Intangibles constitute a significant component of the “flow of value,” and value networks model these explicitly.

Value network mapping aims to identify the roles, transactions, and deliverables in collaborations that create value. It places people and their interactions at the heart of the value-creation process.

From this seemingly simple set of primitives, rich contextual models can be created that illuminate the relationship between the flow of value and work in product development at different timescales and levels of detail.

This is a much more intuitive way to model value-creating activities between groups of people, and we will see that this perspective complements process-oriented perspectives, such as value streams.

While process-oriented mapping techniques such as value stream mapping provide valuable insights into the flow of work, they can be much more powerful when augmented with value network analysis's perspective for how the work creates value.

Each perspective sheds insights on and enhances the other. Both are useful, but together, they can provide some unique insights. Processes emerge naturally from value network analysis. While process models are also often augmented to describe interactions between actors, they are not the model's primary focus.

In this sense, Value Networks and value delivery modeling are highly relevant to many vital ideas currently at the forefront of software product development, including Value Stream Management, DevOps, and Team Topologies.

Why does this matter?

Value networks let us model and reason about the flow of value in a business ecosystem by capturing the collaborations that generate this value.

VDML enables us to represent these networks at varying levels of detail through a structured ontology.

We can analyze the value exchanges between business participants at higher abstraction levels. At more granular levels, we can focus on the flow of activities, deliverables, and interactions that support these collaborations, all represented uniformly by roles, transactions, and deliverables.

We began this season by exploring queueing theory as a paradigm for reasoning about the temporal dynamics of the flow of work. When we return to this topic, one fundamental connection we’ll make is how queuing network models, derived from value network representations at different levels of detail, enable formal reasoning about both the temporal dynamics of the flow of work and the flow of value.

Value networks are also a robust foundation for building other simulation models, including system dynamics models and agent-based simulations of value-creating ecosystems.

System dynamics models help us understand the network's feedback loops, delays, and accumulations, providing insights into how value creation processes evolve.

Agent-based simulations take this further by modeling the behaviors and interactions of individual agents within the network. They allow us to explore emergent behaviors, adaptive strategies, and the impact of local decisions on the broader ecosystem.

Together, these models enable us to simulate and analyze value networks' complex, dynamic nature, starting with a uniform way of representing value networks.

In the next episode, we will explore Value Network modeling further with a detailed example of a software product business.

AssetManagerPro is a SaaS product that helps commercial property owners manage small to mid-sized real estate portfolios. 

The value proposition:

“AssetManagerPro empowers small to mid-size commercial property owners and asset managers with an all-in-one platform that simplifies both financial management and operational logistics with a user-friendly, scalable solution tailored to your specific needs, providing real-time insights into rental income, property metrics, and maintenance workflows—all in one place, at a cost that fits your budget.”

Stay tuned as we model the Value Network for AssetManagerPro.

Episode 1 introduced our protagonist, The Entrepreneur, CEO of an AI-powered custom software factory in 2034. She struggled to understand why she lost money on her company’s customer guarantee: “Your idea, live in production in one business day, or your money back.”

Her engineers showed her that their delivery process was shipping orders with a cycle time of half a day. With two engineers, she was convinced they should comfortably meet their customer service guarantee. All her competitors were doing it, so why not her team?

In Episode 2, the Advisor, a Queueing Theorist, showed her why, using a simple queueing model for her business. The critical thing she was missing was that as queuing in front of the system increased with increasing order flow, the probability that customer lead times would exceed a day and trigger refunds also increased.

The Advisor alerted her that while her current losses were still modest, she was at much greater risk of losing money on the customer guarantee should her business grow further, as it seemed to be doing.

We pick up the story here.

The Current State

“Let’s recap,” the Advisor says.

“We know that currently, your current order arrival rate means your team is operating at a 60% utilization, and so you should expect some amplification of your service time of half a day when considering the end-to-end customer lead time, and this is entirely due to stochastic delays introduced by queueing.”

“Approximately 7% of your customers see lead times of greater than a day, and these orders trigger the refunds on the customer guarantee. As I explained, you must consider this a queueing tax for your operations. It is unavoidable given your current utilization.”

“The thing about your one-day guarantee is that it materializes the cost of delay and makes it tangible in your financials. The cost of delay should always have been part of your business model and planning, and you must manage this risk much more closely than you have been doing. Luckily, things are not terrible now but could easily worsen if demand increases.”

“For instance, let's look at what happens if demand increases by 20%, assuming that arrival patterns remain largely the same as they are today.”

“You can see now that the probability that a customer will experience a lead time of more than a day has increased to 20%! That is a significant fraction of your revenue that you will be refunding, and you probably won’t be able to sustain that. The cost of delay has become material now.”

“Wow!” says the Entrepreneur. “No way we can survive that, for sure! What do we do?”

“Well,” says the Advisor, “first, let’s see why this is happening.”

“At a 20% increase in demand, and assuming your service stays at the steady half-day cycle time, your system is at 73% utilization. At these levels, it is much more probable that an incoming order will find both engineers busy working on orders, and the probability of queueing increases rapidly. So too does the probability of customer lead times exceeding a day.”

“So what should you do? I recommend hiring a third engineer immediately. If your business expands as you think it will, they will pay for themselves in short order if they can help you keep all the money you earn in revenues instead of refunding customers.”

Scenario 1: More Engineers

“Let’s see what your process will look like with 20% more demand and an extra engineer.”

“You can see immediately how much of a difference the extra engineer makes! The Average customer lead time drops to 0.55 days even with 20% increased demand, and you only have a 2% queueing tax. Queueing is still a problem, but with your extra engineer, you are operating at a much lower utilization of 46% percent, so you have plenty of headroom to absorb both the overall demand and the variability in that demand.”

“But wait,” says the Entrepreneur. “This is good, but you’re telling me my only option is to hire more engineers? This was not something I had in my business plan at this time. I’ll need to show my board we considered other options before they’ll sign off on this!”

“Of course!” says the Advisor. “We should examine those options. It’s hard to hire skilled engineers even if you have the budget, so let’s consider the alternatives.”

Scenario 2: Increase Efficiency

“Before increasing staffing, it’s always a good idea to see if you are operating as efficiently as you can today. We already know that you have a highly optimized process, but it’s not difficult to assess what a hypothetical improvement to the current service time might do.”

“Let’s consider what the impact of reducing your current service time might look like. Let’s say we go from an average of 0.5 to 0.4 days for a 20% improvement in service time. Let’s assume your demand goes up by 20% simultaneously.”

“Here are your customer lead time probabilities.”

" The results are remarkable! The entire lead time probability distribution has shifted to the left. The most probable lead time is 0.42 days, and your average customer lead time is 0.51. There is only a 2.9% probability of lead times over a day. These results are very comparable to the effects of hiring a new engineer.”

“This shows you the hidden power of improving efficiencies in your operation. Improving efficiency has allowed your service a higher demand at a lower utilization, with the same number of engineers! This is a powerful tool to have at your disposal. It’s an option you always need to consider in these situations.”

The case for slack

“Except there is a catch in your case. Your team is already operating close to the edge in servicing the current demand. You have to consider how you are going to find these efficiencies you are looking for when the same team members are the ones who will need to help you figure out where they are and how to improve the system. Taking them offline for any time to create these improvements will impact your ability to service current customers.”

“You are running with minimal slack capacity, given your one-day guarantee. Adding an engineer is your best bet at this stage because once you have that engineer on board, you’ll be running at around 38% utilization at your current demand. This might seem scandalously low if you expect your engineers to be maximally busy at all times. But, this is capacity that you should reserve to optimize and improve your system.”

“You’ll have the opportunity to do this once the new engineer is onboarded and producing, and that is the point at which you can shift your lead engineer’s attention to trying to find efficiencies and further optimize your process.”

“Do both things, and you’ll always be running Lean.”

“Ultimately, the best way to manage your capacity strategically is to maintain enough slack to keep your options open on how to act. Once you lose the flexibility of having slack in your system, like you have today, you only have hard choices left, leaving you at risk of being unable to respond to your customer demand when you most need it.”

“I get it now." said the Entrepreneur.

“But there is one thing that is still bothering me. You seem to be implying that 60% is a soft limit on the utilization of my team if I want to maintain my customer guarantees. Are you saying there is no way I can achieve the maximum velocity we expected in our business plan? That seems like a big miss!”

“Yes,” says the Advisor. Since we are considering scenarios, let's play this out so you understand what achieving maximum velocity would imply.”

Scenario 3: Saturation

“Let’s say we wanted to run at maximum velocity. This means that we are delivering four orders per day, which implies that orders are arriving at least at the rate of four orders a day. In other words, utilization is 100%. For discussion, let’s use 99% utilization in our scenario.1

“Here is what your customer lead time distribution looks like in this scenario.”

“That’s completely shocking!” says the Entrepreneur.

“Absolutely, but completely expected.” says the Advisor. Your average customer lead time is now 18.5 days. A significant number of customers wait a month or more for their orders. Your team is maxed out servicing orders continuously, and every new order that comes in has to get in line behind a large queue of waiting orders. You are now in the world of saturation.”

“Once high utilization pushes a system over into saturation, it can become hard to dig yourself out of this zone and move back into a stable operating zone.”

“Before we had all these AI-powered tools we have today, much of the software industry operated in a permanent zone of saturation. Demand was always vastly higher than supply, and it was typical for customer lead times to stretch into months and even years. It was simply considered the way software development worked.

“Once you reach saturation, you only have one choice assuming you can’t add staff or increase efficiency: you throttle arrivals.”

“You set up backlogs to decide which customers deserve to be serviced before others, add prioritization and expediting policies to deal with exceptions, and generally have an inconsistent and unwieldy process and perenially unhappy customers.

“You would never stay in business with a money-back guarantee like the one you can offer today. As you can see, nearly all your customers would get free orders under this scenario!”

“From a utilization standpoint, what you are doing in this scenario is throttling arrivals to reduce the effective rate at which you start orders to maintain a certain utilization level relative to the service rate.”

“You put a big physical queue in front of your process where orders wait until your team pulls them into the service queue when they are ready to work on them. Maintaining that physical queue lets you pay attention to priorities and service customers with different strategies, etc.

“But most of your customers would wait for a long time to get anything prioritized through the development process.”

“I am only introducing these options here as a thought experiment and for historical context. In the 2034 market, these are entirely unacceptable strategies if you want to stay in business. Your customers would move on to more operationally competent providers!

“Unfortunately, the one-day guarantee is now table stakes in this business, so you cannot ignore the cost of delay like people could a decade ago.”

“Ok. You’ve convinced me,” says the Entrepreneur. “I guess our strategy has to follow your recommendation: hire another engineer and plan on continuously optimizing our process to push off the point where we need to hire the fourth as much as possible while maintaining sufficient slack at all times.”

“I’m glad you concur.” says the Advisor.

The Takeaway

“I’m happy we brought you in to help us resolve this disconnect in our metrics,” says the Entrepreneur.

“We thought we were dealing with a measurement or data problem, but you’ve opened my eyes to something much more fundamental I should have been paying attention to all along.”

The Advisor says, “You are not alone. I often see this in my work. It is common for operational metrics to be internally focused and explicitly focused on maximizing velocity. Velocity is a necessary measurement component, but you will always miss the big picture of your work's impact unless you also measure things from a customer perspective.

“Your one-day guarantee made the cost of delay embedded in your business model visible very early in your company's lifecycle. This was invisible in your operational metrics, but you started paying attention early because it cost you real money in refunds. Now you know what it means for your business, have the tools to continually monitor it, and stay ahead of the curve as you grow.

“Once you are upside down on having adequate capacity to meet demand and forced to operate at high utilization, you will always have much more complex choices. I am happy I was able to help you see this at a point where you can get ahead of it.”

“Let me summarize the key takeaways,” says the Entrepreneur.

• My customer lead times depend not just on having an efficient service, but I also need to understand how customers interact with and place demand on the service in my operational metrics.

• A probabilistic model helps me understand the causal relationships between customer experiences and my operational processes. My best bet is to use these models to improve the long-term probabilities of desirable customer experiences.

• Since my business model is based on short lead times, the cost of delay is an important constraint that I need to pay attention to. In particular, I cannot expect to maximize the velocity in my process and run at very high utilization since this will increase the probability that I trigger refunds under the one-day guarantee.

• I need to maintain a healthy amount of slack to be responsive to variable demand and have spare capacity to improve my process continuously. This is a mutually reinforcing cycle since improving efficiency creates more slack!

“Perfect! I could not have said it better!” says the Advisor.

The parable of the Entrepreneur and the Queueing Theorist will form the starting point of a deeper exploration into the applications of queueing theory and probabilistic reasoning in the rest of Season 2 of The Polaris Flow Dispatch.

We’ll delve into the Advisor's techniques in modeling the entrepreneur’s process and explain the math behind why her approach works.

We’ll also explore how this parable surfaces many missing aspects of measurement in software development today - the customer perspective, the cost of delay, probabilistic modeling, incorporating variability, etc., as core measurement tenets for software development systems.

While this example might seem overly simplistic, it surfaces deeper issues worth examining in more detail.

I hope you’ll stay tuned for the rest of the season.

In particular, the Entrepreneur was surprised by the tradeoff between throughput or productivity and customer lead time and the role of randomness introduced by queueing in creating this tradeoff.

We pick up the story here. Read Part I of The Entrepreneur and The Queueing Theorist if you are just joining.

Understanding Queueing

“It’s straightforward to understand queueing if you think of it as orders backing up in front of your services as customers place their orders simultaneously. Your developers can only work on a small number of orders simultaneously, and if new orders come in when they are busy with other orders, the new order will have to queue up and wait.” said the Advisor.

“Very often, there is no queueing if orders are spaced well enough apart in time. At other times, queues build up for a little while and get drawn down as your developers catch up.”

“This is precisely the same thing that happens when you are in line at the supermarket or the security line at the airport. Depending on how long the queueing lasts, the time it takes a customer to fulfill their order will vary quite a bit, even if the actual development cycle time needed for each order is very stable.”

“In particular, if orders consistently arrive at a rate that your process cannot service, we have a situation where queueing happens continuously. When this happens, there is no limit to how long customers might have to wait for their orders. We never want to be in this situation.”

“Queueing introduces randomness into even deterministic processes; thus, we need probabilistic tools to reason about this behavior. Luckily, queueing theorists have been studying this problem for over a century, and we have powerful mathematical tools called queueing models that will allow us to analyze queueing in stochastic processes and reason about its causes.”

The Queueing Model

“We’ll construct a probabilistic model of how your customers interact with your service, which will clearly explain how queueing is causing you to lose money on the one-day guarantee.” the Advisor says.

“This model, like all queueing models, consists of

1. The Arrival Distribution A: A probability distribution that describes how requests arrive at the service over time - the shape of the demand for the service.

2. The Service Distribution S: A probability distribution that describes how long it takes your service to fulfill requests and

3. The Service Concurrency c: The maximum number of requests the service can process simultaneously.

Note that all three components relate to time: how often requests arrive, how long they take to process, and how many the service can process simultaneously.

Queueing models explain how delays emerge in a system, and these three components are the basic building blocks you need to reason about this.”

“Let’s look at what these components look like for your system,” she says.

The Arrival Distribution

“The arrival time distribution shows the probability of the time between consecutive arrivals to your service. The intuition here is that queueing occurs when many orders arrive in a short window of time, and so we want to capture the probability that inter-arrival times are short vs more spread out in time.”

“It’s important to note that these are long-term probabilities. We analyzed several months of order data to understand arrival patterns and built this probability distribution from that analysis. Since your business is growing fast, you must keep an eye on these probabilities since they will change and have a material impact on your business as it grows.”

“We can see that currently, the arrivals are skewed on the high-frequency end, which means that usually, many customer orders arrive close to each other. The average inter-arrival time is 0.41 days, slightly smaller than the 0.5 days it takes to service an order, so we should expect to see some queueing under these circumstances.”

The Service Distribution

“The service distribution shows your process’s probability distribution of service times. This is the time it takes your team to fulfill an order once they start working on it.”

“Your process is highly optimized, and most orders are processed in around 0.5 days with minimal variability. Our model will approximate this with a deterministic (constant time) distribution to illustrate the impact of queueing much more clearly. In reality, this service has some variability, so this is a conservative assumption. The queueing impact will only worsen once we account for this.”

The Service Concurrency

“Finally, we’ll model the service concurrency c=2 since you can process at most two orders concurrently with your current team.

For now, we’ll assume there is no multi-tasking and that the team takes an order from start to finish before starting a new one. Your work-in-progress data seems to bear this out, and again, this is a conservative assumption that will highlight the impact of queueing.”

The Probability of Queueing

“The first thing to assess is the probability that queues will form in your system, given the three parameters above. We do this by looking at probabilities for the total number of items in the system, both in progress and waiting for service.”

“We noted earlier that the ratio of the arrival rate to the service rate, which we defined as utilization, is an important driver of how the system behaves. The queueing probabilities are shown here for utilization of 60%, which is where your system is currently.”

“We see that the most likely scenario is that the number of items in the system is less than the concurrency limit, which implies that there is no queuing in those cases. Again, this agrees with our intuition since arrival rates are well below service rates.”

However, queueing will occur whenever the number of orders in the system exceeds the concurrency limit. We can calculate the probability of this happening as the area under this curve to the left of the solid red line in the distribution, and this number is significant at 41%.”

“We see that up to 5 orders can be queued up in the system at a time, waiting for service. These are the potential candidates for higher customer lead times. The critical question is how it impacts the probability of the customer lead time exceeding a day - the ones that trigger your losses on the one-day guarantee!”

“So let’s put everything together and look at how long your customers typically wait for their orders to be fulfilled at the current utilization. Remember, this was the relationship you found surprising earlier!”

The Customer Experience

“This is captured by the Customer Lead Time probability distribution, one of the outcome parameters for your process. “

“The distribution shows that the impact of queueing on customer lead times is not too significant (at least, not yet).

The most probable lead time that a customer will experience is 0.51 days, and the average lead time is 0.6 days, which aligns with your lead time flow metrics. But as you can see, higher lead times are also probable for some customers, and overall, this lead time distribution is much more variable compared to the very deterministic service time distribution you have for the internal process.

The difference between the two distributions is entirely attributable to queueing. It is the most significant factor determining the end customer experience. And to a large extent, you cannot control the impact directly when you don’t control the demand.

In particular, there is a non-zero probability that up to 7% of your customers will wait more than a day to fulfill their orders and will, therefore, get their money back.

Think of this 7% loss rate as a queueing tax. Based on your current capacity, it is unavoidable. But think of this as a way of keeping you honest in a competitive market.

At least your customers will not be as unhappy with the small slips in your SLAs, and you now have a very tangible economic reason to optimize your end-to-end customer experience instead of just focusing on optimizing your internal process.

The primary lesson here is that queueing will always amplify your service times, and your customers will always experience these amplified service times.

To see how critical this is, let’s look at what these amplified service times will look like if your order volume goes up by 20%. Since your service rate is what it is today, this amounts to seeing what happens when utilization of your process goes up from where it is today.”

“As you can see here, the probability of customer lead time exceeding a day when demand for your process goes up from here goes up dramatically: from 7% to over 20%! “

Now we are talking real money that will quickly make your business unviable if you don’t get it under control early!”

“That’s sobering news!” says the Entrepreneur.

“How do we get ahead of this?”

“Let’s examine some options,” says the Advisor.

In the next episode, the Advisor examines several options and the tradeoffs they involve so that the Entrepreneur can stay ahead of the looming disaster that might come with more growth in her business as the money-back guarantee backfires in a big way!

Silicon Valley has relocated to cryopods in near-earth orbit as the utopians await the Singularity.

It is now expected in 2040.

In the meantime, AI has helped solve many mundane problems of the early 21st century.

Rapid software product development is considered a solved problem. Small teams of experienced domain experts and skilled software engineers manage AI coding farms, delivering software at previously unimaginable speeds.

One-day delivery of new features and change requests to complex custom applications is routine.

Most businesses outsource application development to specialized companies with the technical expertise and capital needed to build and deliver software with AI-optimized infrastructure.

The Entrepreneur

Our protagonist is the CEO of one of these innovative custom software factories1, which are the backbone of the software development industry today.

Her startup has developed an AI-optimized development process, and her team of engineers and domain experts can take a custom order from idea to production in half a business day.

The company pitch is “Your idea - live in production in one business day, or we’ll give you your money back.”

The team is still tiny: two domain experts and two engineers who manage their AI coding farm, which does much of the heavy lifting.

Business has been growing fast.

But so have losses on the one-day guarantee…

The Weekly Business Review

The Entrepreneur is unhappy.

“The losses on the one-day guarantee are starting to hurt us,” she tells the Lead Engineer.

“We designed our process to deliver four daily orders with two engineers. Our throughput is below target, and our work in progress is below what it needs to be to meet this target!”

“Our engineers need to be more productive. We need to increase our velocity!”

The Lead Engineer looks at the same dashboard and says, “Look, our engineering cycle time and customer lead times are exactly where we designed our systems to be. ”

“We have a customer lead time SLA of 1 business day. Our current development cycle time is 0.54 days, and our customer lead time is 0.64 days on average. That’s well within our SLA.”

“You do realize this is not a factory making the same widgets repeatedly, right?”

“Every order and change request is different. Our engineering skills in mapping customer orders to the right prompts for the AI, correcting for hallucinations2, and keeping all our delivery pipelines green through all this are what make this operation work!”

“Our team already feels like they can barely keep up with the work coming in!”

“We designed our process around maintaining predictable development cycle times and customer lead times, and we are meeting these commitments. Why are we focusing on velocity and productivity instead of customer response time?”

The Entrepreneur is puzzled but agrees the Lead Engineer has a valid point.

“But why do we often fail to meet our one-day customer guarantee if we are within the SLA?” she asks.

The Lead Engineer does not have an answer.

“Maybe something is wrong with the data?” he asks.

They are at an impasse, so they engage an Advisor to help resolve the question.

The Queueing Theorist

“I need you to help us understand why we are losing money on the one-day guarantee when all our operational flow metrics seem to say we are doing fine,” the Entrepreneur says to the Advisor.

The Advisor spends time with the team to understand how the operation works, examines how they measure their processes, and requests some additional information.

“There is an important metric you are not currently tracking, which should help us get to the bottom of what is happening here.”

“I’ll need to understand how and when your customer orders are coming into your process,” she says.

She reviews some data from the company order management system and builds a model of the customer experience to help the team understand what is going on.

It does not take long to resolve the first puzzle that concerns the Entrepreneur the most: is velocity/productivity good enough?

“The first thing to note is that none of your metrics are looking at the inputs to your process,” the Advisor says to the Entrepreneur.

“Your flow metrics will vary depending on how heavily your process is being loaded concurrently by customer demand, so the first thing to check is to see what that demand looks like.”

“A quick analysis shows that you receive an average of 2.4 orders daily, which, not surprisingly, matches your throughput of 2.4 orders daily.”

“So, we can confidently say that your velocity/productivity is not your problem. You can’t ship orders any faster than they are coming in!”

“But let’s look at the underlying principle that lets me make this claim.”

“Your service rate - the rate at which you can service orders with two engineers when each order takes half a day, is four orders per day, and the variability in your development cycle time is very low. Your arrival rate, at 2.4 daily orders, is well below this rate. We can confirm this from your current cycle time data.”

The critical metric I mentioned that you should pay close attention to is utilization—the ratio of these two numbers.

This is 0.6 (2.4/4), and as long as this number is less than 1, your throughput will always match your arrival rate because you have enough capacity to keep up with the demand.”

“However, talking to your engineers, they already feel overwhelmed with the customer demand today, and you are starting to see some customers experience larger lead times.”

“This is not surprising at these utilization levels, and, as we’ll see, this is also the underlying reason for your losses on the one-day guarantee.”

The Entrepreneur says, “I don’t understand. What does utilization have to do with customer lead time?”

“If we want to be efficient, shouldn’t we maximize our utilization and ensure we are getting the most productivity from our engineers? They are our biggest expense after AI costs. They are also very hard to find these days.”

“No, unfortunately.” says the Advisor.

“Your business model relies on high throughput and engineering productivity, which is higher when running at higher utilizations. However, you can only go so far with that strategy since you also have money riding on short customer lead times because of your money-back guarantee.”

“Customer lead times increase as you increase utilization. So throughput/productivity and customer lead time are always in tension.”

“Please explain how this can be. I’m really curious now! It seems I am missing some fundamental piece of the puzzle here,” says the Entrepreneur.

“Yes, this is a common confusion. To understand why, we need to understand the impact of queueing in your system.” says the Advisor.

Queueing

“You’ve designed a highly optimized delivery process, and looking at the data, each custom order does indeed take around 0.5 days to go from start to finish. There is minimal variability here, and it’s a tribute to the technology and process capabilities you’ve built around it!”

“However, your business model has not accounted for the variability in how and when customer orders reach this process, and here we run into the fundamental constraint of concurrency.”

“If a customer order arrives when your team is busy processing orders, then that order has to wait until the team can work on it. This wait time becomes significant if many orders arrive within a short window. This is what we call queueing.”

“In your case, the impact of queueing is reflected directly in your customer lead time. The random wait times due to queueing, added to your stable development cycle times, introduce significant variability into your customer lead times. This is the crucial factor you have overlooked in your business model and the flow metrics you are currently tracking.”

“Some fraction of your customers will experience lead times of well over a day, even though each order was processed in a half day or less internally. These are the orders that are costing you money.”

“How do we fix this?” the Entrepreneur asks.

“You can’t fix this,” says the Advisor.

“Queueing is a phenomenon that emerges whenever you have concurrency constraints in your process. It’s often not easy to tell where and when this might emerge. It introduces an element of randomness into even the most deterministic process, especially when you don’t have control over demand.”

“We can never eliminate the probability of queueing emerging in a process with concurrency constraints. However, recognizing that you are dealing with a random process instead of a deterministic one gives you powerful tools to manage the impact of queueing much more strategically.”

“The important thing is determining the probability that queueing behavior will cause meaningful impacts on your business. In this case, it is clear this is happening, so the question is how bad the impact is and what your risks of this getting worse as your business grows are.”

“How do we do this?” asks the Entrepreneur.

“We’ll start by constructing a causal model for your process, something that will let you connect the output metrics you are currently tracking, like throughput, cycle time, and customer lead times, to the controllable inputs that cause the metrics to be the way they are.”

“We’ve seen many elements of this causal model already in the high-level analysis of productivity and throughput I gave you earlier. But there is so much more we can do once we build one, so let’s understand what one looks like for your business.”

“The causal model for your process is relatively simple. I’ll show you how we can use it not only to understand your current risks but also to understand what risks you face as your business grows and how to manage those risks strategically.”

“I can’t wait to dive into this!” says the Entrepreneur.

In Part II, The Advisor will show the Entrepreneur how she can use a queueing model to strategically manage key process-related risks for her business.

After a brief flurry of writing in the Summer of 2023 outlining some broad themes I wanted to explore in this blog, this publication promptly went on an extended hiatus.

I was wrestling unsuccessfully with scope creep and trying to simplify material that is mathematical at its core without being too technical.

In the end, I decided to put it aside until I felt I could explain things in a way that struck the right balance, and after a year of reading and experimentation with drafts and talks, I’m back to make another pass.

The Broad Themes

The themes explored in this blog remain unchanged: the relationship between value creation and the flow of work in software product development, the connection between economic models and value streams, and the underlying mathematical foundations that help us reason reliably about product development flow with real-time data.

Last summer’s posts can be considered informal, tactical explorations of key themes at a very high level.

In “Stability First,” we discussed the importance of stabilizing flow in product development. In “Stable does not always mean steady,” we discussed what it intuitively means for a process to be stable. In “Flow Signals and Flow Metrics,” we looked at establishing a goal-oriented framework for flow metrics. Finally, “Throughput!= ” examined the connections between flow metrics and economic outcomes.

This time, I plan to explore these themes, their underlying theories, and their mathematical foundations more deeply. While the content will be more technical, I aim to keep the discussion informal as much as possible without sacrificing rigor.

A Key Focus: Queueing Theory

As we advance, queueing theory and the importance of probabilistic models for reasoning about software development will be key focus areas for this blog.

The Lean Model

I assume readers are already familiar with concepts such as Little’s Law and the Utilization Law, as they are applied in Lean/Agile Software development.

We explored these informally in the posts “The Iron Triangle of Flow,” “A Highway at Capacity is not a Parking Lot,” and “A Parking Lot is not a Highway at Capacity.”

While these concepts stem from queueing theory, their application in software development is indirect, via principles adopted in Lean manufacturing that rely on queueing theory for their validity.

The manufacturing domain allows for several simplifying assumptions, such as predictable demand, repeatable production processes, low variability in task completion times, and deterministic work routing.

These assumptions lead to simpler, quasi-deterministic queueing models from the perspective of general queueing theory. Specifically, as discussed in later posts, they assume that the inputs to a parameterized queueing model are known beforehand with reasonable certainty.

These assumptions enable the design of stable processes optimized to produce outputs efficiently given those inputs. They also allow the operational focus to shift to managing the process’s outputs and exceptions.

However, software development is far more dynamic and unpredictable, and none of these simplifying assumptions, specifically those about deterministic inputs and stable processes, apply.

Lean software development introduces interventions such as WIP Limits, Pull Policies, and Constraint Management to make those assumptions fit within specific bounded contexts in a software development process.

While they have proven valuable in improving the flow of work and stability of development processes in smaller, localized contexts, these techniques become more unwieldy as we try to expand to broader and more general organizational scopes1.

More fundamentally, the Lean approach ignores the stochastic nature of software development inputs. Modeling such processes falls comfortably within the scope of general queueing theory.

General Queueing Theory

Queueing theory is a general mathematical framework that explains how and why delays occur in processes under resource constraints. It highlights the importance of concurrency as a constraint to flow and allows us to characterize how variability in demand and development capacity influences delays.

In particular, in the general queueing theory model, stochastic processes are the inputs to a queueing system, and the theory uses probabilistic arguments to explain the relationship between those inputs and the model’s outputs.

This gives us powerful new tools to help us reason probabilistically about system stability, resilience, and the capacity to perform work in contexts where volatility and uncertainty are typical.

The themes we will explore are general queueing theory and its underlying probabilistic reasoning techniques, the representation of product development value streams using queueing networks, and causal models that help us measure and model cause-and-effect relationships between process behavior and economic outcomes, even in complex adaptive environments.

While techniques such as probabilistic forecasting are becoming standard parts of Lean/Agile practice, viewed from the perspective of general queueing theory, they are still primarily forecasting future output parameters of a stochastic process based on the values of past output parameters of the same process.

This approach makes forecasts volatile, but more importantly, it does not provide a way to reason about why they are volatile.

I’ll argue that this is a consequence of starting with the simpler output-focused Lean model and that a model based on general queueing theory is a much stronger foundation for building forecasting models for software development.

Starting from the first principles of queueing theory and modeling software development as a network of inter-connected stochastic processes will help us build a more realistic picture and give us a robust set of tools and techniques to reason rigorously about real-world software development.

The Road Ahead

Many of the problems we struggle to model today in software development are surprisingly similar to the ones that initially motivated the development of queueing theory in the early 20th century.

Over the past century, theory and applications have built on each other as practitioners used them to solve problems in various domains, including computer architecture, traffic analysis, healthcare, public services, and computer networking.

Many of these problems are isomorphic to the ones we struggle to describe and model accurately in software. While software development, some aspects of software development are more complex than many of these areas, the generality of queueing theory seems well-equipped to tackle even these complexities.

We will first see how elegant, well-understood techniques from queueing theory and queueing network models applied in other domains can answer many relevant questions in software product development and delineate the bounded contexts in which managers can use them to make critical economic decisions.

We’ll investigate new ways to model product development flow in complex adaptive systems, incorporate uncertainty at a foundational level into our reasoning about software processes, and reason causally about how process improvements can drive economic outcomes in software development.

Examining these concepts from a different perspective, we hope to provide practical insights that can help inform your approach to software product development.

Warm-up: The Entrepreneur and The Queueing Theorist

We’ll begin our exploration starting with a parable set in the near future.

Imagine the following scenario: AI has completely solved all the problems we face today in software delivery.

And yet… many of the debates and challenges we face today, delivering value to customers, remain…

Check out the three-episode series first to get oriented around some of the discussions we’ll be delving into this season on The Polaris Flow Dispatch.

Episode 1: The Problem

Episode 2: The Analysis

Episode 3: Scenarios

The idea of stable flow often conjures up a picture of an assembly line churning out identical widgets of the same size and shape at a steady rate. 

In fact, a system can be stable even if its outputs are not steady, and a steady output does necessarily mean the system is stable. 

A stable Scrum?

Consider a team that delivers a single feature towards a sprint goal in a 2-week sprint, followed by a 2-week sprint where they work with users to fine-tune the UX based on feedback and repeat this over and over again consistently.

This process will have very different outputs (cycle time and throughput) if you measure them sprint by sprint. 

The size and shape of work between sprints will probably look quite different. Their outputs measured over two-week windows may not look very steady. 

But this can still be a stable system, provided all work that starts in a sprint is finished within a sprint or two.

In fact, setting a single sprint goal and pulling work into sprints based only on this goal can be a very effective mechanism to achieve stable flow.

Stability is a business goal.

When talking about stability, the observation window you are measuring over and the frequency with which you take measurements (to compute averages) are very important.

For example, in our example above, if you take repeated weekly measurements over 30-day windows, you may find your output metrics are steady, and the system meets the conditions for stability, even if they are neither when measured across a narrower observation window of two weeks1.

The trick, of course, is to make your system stable over some policy driven window that meets the needs of your business.

This is determined by how quickly your customers need you to ship changes to them and how quickly you need to respond to their needs to compete effectively in the market.

In general, the steadiness of output is not easy to achieve because of the nature of software development, but it is not particularly important anyway.

What matters is the stability of the whole process.

A stable system only starts as much work as it can deliver within some policy driven (execution) window, which then makes it easier to coordinate the flow of work between product development and the rest of the business.

A stable flow is the first step in being able to synchronize your product development process with the pace at which your customers need you to deliver for them, and the conditions of stability provide a wide range of options to design a process that lets you do this.

What makes a process stable?

In general, you can’t say anything about stability simply by looking at the steadiness of its outputs.

You have to look at the outputs relative to the work in progress over an observation window that the business gets to choose.

What matters for stability is that the WIP and the average age of WIP stay bounded over a suitably chosen observation window, that work starts and finishes at roughly the same rate, and that you finish all the work that you start.  

These are fairly weak requirements, and there are quite a few different ways to meet them.

You can lean directly into the manufacturing analogy as Kanban does, hold your WIP constant, and use a disciplined policy of only pulling in a new item when some item finishes.

This will give you steady throughput but not necessarily a steady cycle time or a stable process unless you also place a limit on the age of WIP.

For stability in a software process, you need explicit policies in your process to manage both the WIP amount and the aging of WIP.

Further, no matter what methodology you adopt, you need to have some way of ensuring that work keeps moving.

Otherwise your process will never be stable.

Which quadrant is the right one?

In the figure, we give some examples of choices that can meet the requirements of stability, steadiness, or both.

Note that we are not suggesting that these are directly tied to which methodology you choose, just that well-functioning implementations of these choices will tend to fall into these quadrants.

Of the four quadrants in the figure above, the only one that is always undesirable is the top right one, where the process is neither stable nor steady.

You get this when you have unmanaged WIP and unmanaged scope/aging of work.

Depending upon the economic model of your business, any one of the other options might be a workable solution for your context.

Stability is a goal you aim for no matter what methodology you adopt.

Even an ad hoc one.

And the great thing is that stability represents a process-agnostic process outcome that you can measure without knowing anything about the specific process you are using.

Most of the current methodologies we have today get us a good part of the way towards achieving this, provided you factor in the need for stability by focusing on how you scope work, manage WIP and start what you finish.

This is what makes the concept of stability so powerful to cut through the noise of the methodology wars.

Unfortunately, the parts you need for stability are often left out of the standard playbooks people get when they adopt one of these methodologies.

So in practice, you can implement a process that falls into any of these quadrants, no matter which methodology you choose.

Most real-world implementations of any of these methodologies are neither steady nor stable.

Still, stability is the problem we need to solve to make the process work for the business.

In the end, stability and steadiness are not something you get from the choice of your methodology but from how well you implement them with a clear focus on stability.

It does not come for free simply by the choice of your methodology.

In any case, don’t fall into the trap of thinking that trying to make software development stable means forcing the work to look like assembly line manufacturing.

That’s just a myth.

Update (Oct 7th, 2025)

This post, written in July 2023, was an informal articulation of concepts that we can make very rigorous and formal with the help of Little’s Law.

Please see our 2 part series from 2025 that fills in the math.

Building software is not like working on an assembly line. 

One key difference lies in how work “moves” in software vs. on an assembly line.

Newton’s First Law of Motion says, 

𝘈𝘯 𝘰𝘣𝘫𝘦𝘤𝘵 𝘢𝘵 𝘳𝘦𝘴𝘵 𝘴𝘵𝘢𝘺𝘴 𝘢𝘵 𝘳𝘦𝘴𝘵 𝘢𝘯𝘥 𝘢𝘯 𝘰𝘣𝘫𝘦𝘤𝘵 𝘪𝘯 𝘮𝘰𝘵𝘪𝘰𝘯 𝘴𝘵𝘢𝘺𝘴 𝘪𝘯 𝘮𝘰𝘵𝘪𝘰𝘯 𝘸𝘪𝘵𝘩 𝘵𝘩𝘦 𝘴𝘢𝘮𝘦 𝘴𝘱𝘦𝘦𝘥 𝘢𝘯𝘥 𝘪𝘯 𝘵𝘩𝘦 𝘴𝘢𝘮𝘦 𝘥𝘪𝘳𝘦𝘤𝘵𝘪𝘰𝘯 𝘶𝘯𝘭𝘦𝘴𝘴 𝘢𝘤𝘵𝘦𝘥 𝘶𝘱𝘰𝘯 𝘣𝘺 𝘢𝘯 𝘶𝘯𝘣𝘢𝘭𝘢𝘯𝘤𝘦𝘥 𝘧𝘰𝘳𝘤𝘦.

In assembly line work, this unbalanced force is exerted by the moving assembly line, which keeps work in constant motion unless someone explicitly stops the line.

In software development, the opposite is true.

The only unbalanced force that can keep work moving is attention: from people with the right knowledge and skills to collaborate and keep work in motion. 

Work stops moving when the attention is taken away or not in the right place at the right time.

So odd as it might seem, software development and the famous Canadian sport of curling have much in common!

Both of them need constant attention on the “work” for it to keep moving through the “system,” particularly in the most knowledge-intensive parts of the process like UX design and coding.

There is no denying that the software development process's most valuable and knowledge-intensive parts are kept in motion by the force of human attention, at least in these early days of generative AI.

One of the critical arguments for automating the development process, wherever possible, is to create an assembly line-like external force that keeps work moving through the pipeline without needing this constant human attention, particularly in the non-value-added packaging and deployment phases.

So what?

First, cognitive load has been recognized as a key limiting constraint to flow in software development 1, but measuring this directly is tricky.

If, however, we take the view that focusing attention on a unit of work consumes cognitive capacity and turns it to motion - a directly perceptible and potentially measurable property of work - then we have an indirect way of measuring the cognitive capacity and distribution of cognitive load within a system, by examining the motion of work within it.

This gives us concrete ways of measuring if changes made to organizations to facilitate the flow of work based on the basis of optimizing the cognitive load on teams are having their intended effect.

Second, in software development, it is often difficult to plan what work needs attention, from whom, and when, even if we know everything that needs to be done and maybe even the order in which we want to do it. 

This might make it feel like software development is inherently chaotic or complex and unpredictable.

But a straightforward way exists to manage this complexity and uncertainty.

Watch the work in progress and look for the work that is not moving. 

If we can accurately measure the “motion” of software work, we can identify imbalances between cognitive capacity and demand in the system lie and what, if anything, needs to be done about it.

This is important because motionless work is a key indicator of an unstable system, a system that takes on more work than it can deliver.

Motion and Instability

If you recall the four conditions for system stability, the critical condition impacted by this is the fourth one.

The average age of the units of work in progress is neither increasing or decreasing unboundedly.

Work that stops moving continues to age in the system, and the longer it stays immobile, the greater the impact on the average age on work in progress in the system, and the likelihood that it will violate the fourth condition pushing the system into instablity.

However, if we can reason rigorously about the motion of work, we have a very practical principle we can apply to manage this condition for stability.

We call it the “Keep Work Moving” principle.

If the first three conditions for stability are satisfied, and in addition, we can keep all the work in the system moving at all times, then the system will be stable.

Why “Keeping Work Moving” Matters

The key idea is that the system should only take on as much work that it can keep moving at all times.

In software, the aging of work is just as critical a factor in creating instability as the amount of work in progress and the ability to visualize the “motion” of work, together with policies that are designed to regulate the flow of work in response to the slowing or stalling work are critical.

This, in turn, sheds light and provides tools to manage imbalances in cognitive capacity and load across a system, which is a critical constraint in software development work.

If all work in progress is moving at all times, then the cognitive load on the system is within manageable levels. Otherwise, there are imbalances that need to be identified and addressed.

You can think of “Keep Work Moving” as a principle we need in software development in addition to the principles of “Limit WIP" and “Pull Work” used to manage the number of items in the system and the rate at which work is accepted into the system at any time, to stabilize flow through a system.

There are essential relationships between all these principles, which we will explore later in our series.

The “Keep Work Moving” principle2, combined with measuring and visualizing the motion of work, gives us some useful tools to manage aging work actively and regulate the flow of work when aging causes a system to move away from stability.

Analyzing the impediments to “Keeping Work Moving” can be a powerful tool for system analysis and improvement and can shed light on process inefficiencies, skill gaps in delivery, knowledge gaps and constraints, and true capacity to deliver work in a stable fashion, among many others.

Thanks for reading.