Skip to main content

Module flow_framework

software_engineering

Module flow_framework 

Source
Expand description

§Flow Framework

Mik Kersten’s Flow Framework (from Project to Product) treats software delivery as a value stream and defines five core measurements: flow velocity, flow distribution, flow time, flow load, and flow efficiency. This module implements the arithmetic behind flow time, flow load, and the Little’s law relationship that binds flow load to flow time.

§Formula

Flow time  = t(delivery) − t(entry)
Flow load  = count of items currently active or waiting in the value stream
Little's law: flow load (WIP) = arrival rate × flow time (cycle time)
Flow efficiency = active time / total elapsed time × 100%

t(entry)     = when a flow item enters the value stream
t(delivery)  = when a flow item is delivered
arrival rate = new items entering the value stream per unit time

§Why it matters

Flow load does not just correlate with flow time — via Little’s law it mathematically dictates it. If flow load keeps rising while arrival rate stays flat, flow time is guaranteed to rise too. This turns “we’re too overloaded, things are taking too long” from a qualitative complaint into a provable, quantitative argument a business leader cannot easily dismiss. Flow efficiency captures a related, and usually surprising, fact: most software delivery pipelines run between 10% and 25% flow efficiency, meaning the dominant cost is wait time, not active effort.

§Example

use software_engineering::flow_framework::{
    flow_time, littles_law_wip, littles_law_flow_time, flow_efficiency_percent,
};

// A flow item enters day 0 and is delivered day 12.
let t = flow_time(0.0, 12.0);
assert_eq!(t, 12.0);

// Little's law: WIP = arrival rate (items/day) × flow time (days).
let wip = littles_law_wip(2.0, t);
assert_eq!(wip, 24.0);

// Solve the other direction: given WIP and arrival rate, find flow time.
let recovered = littles_law_flow_time(wip, 2.0).unwrap();
assert!((recovered - t).abs() < 1e-9);

// Ten active hours out of ninety total elapsed hours: 10% flow efficiency.
let efficiency = flow_efficiency_percent(10.0, 100.0).unwrap();
assert!((efficiency - 10.0).abs() < 1e-9);

§Pitfalls

  • Quietly narrowing the flow-time starting point (e.g. from genuine business-need identification to engineering pickup) shrinks flow time without improving genuine responsiveness — document the entry point explicitly and audit it periodically.
  • Measuring flow load only periodically forfeits its value as a leading indicator; track it continuously.
  • Applying a WIP limit as an individual quota rather than a system constraint misapplies the technique and risks individual gaming.
  • Treating a low flow-efficiency number as a sign of a bad team: 10% to 25% is typical of most delivery pipelines, and is a starting point for investigation, not a verdict.

§Sources

  • Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.
  • Little, John D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research, 1961.

Topic doc: 02-01-the-flow-framework.md, 02-03-flow-velocity-and-flow-distribution.md, 02-04-flow-time-and-flow-load.md, 02-05-flow-efficiency-and-work-in-process.md

Functions§

flow_distribution_percent
Flow distribution: the percentage share of one flow item type among all completed items.
flow_efficiency_percent
Flow efficiency: the percentage of total elapsed time that was active work.
flow_load_from_items
Flow load: total count of flow items currently active or waiting in the value stream.
flow_time
Flow time: total elapsed time from a flow item entering the value stream to its delivery.
flow_velocity
Flow velocity: count of flow items completed per unit time.
littles_law_flow_time
Little’s law, solved for flow time: flow time = WIP / arrival rate.
littles_law_wip
Little’s law, solved for flow load (work in process): WIP = arrival rate × flow time.