Review
The Flow Framework is a compelling frame for a problem that most technology organizations genuinely have. I came to this expecting a practical guide I could run inside a large organization, and I didn't quite get that. Kersten is precise on the diagnosis: project-oriented management creates the wrong visibility, optimizes for the wrong things, and breaks down at scale in ways that Agile and DevOps alone haven't fixed. The four flow item types (features, defects, risks, debts) and the metrics built around them give a leadership team a vocabulary that most never develop. Implementation is another matter. Without a serious organizational commitment, or some external help, landing this inside a large enterprise is an uphill battle. What stayed with me is a sharper understanding of the zero-sum tradeoffs between features, quality, and risk, and why those tradeoffs stay invisible as long as you're running on a project model.
Key Takeaways
The parts worth keeping
The core diagnosis
IT and digital transformation failures trace back to a structural mismatch: organizations run software delivery like a series of projects when they should be running it like a product portfolio. This shows up as three recurring disconnects: project focus over product focus, cost focus over profit focus, and timeline focus over business value delivery.
The three epiphanies
- Software productivity declines as software scales because the architecture and the value stream become misaligned. Realigning daily work around the value stream instead of the architecture increases productivity.
- Disconnected software value streams are the primary bottleneck to software productivity at scale. These disconnects are caused by the misapplication of the project management model.
- Software value streams aren't linear manufacturing processes. They are complex collaboration networks that need to be aligned to products.
The Flow Framework
The Flow Framework connects business and technology by making value stream delivery visible and measurable. It has three components: a product-oriented mindset (treating software as evolving products, not projects), Value Stream Networks (the infrastructure that provides visibility and automation), and four MECE flow items that define what gets tracked.
The four flow items for any software value stream:
| Flow Item | What it is |
|---|---|
| Features | Units of functionality delivering business value |
| Defects | Bugs, quality issues, escaped problems |
| Risks | Security, regulatory, and compliance work |
| Debts | Technical debt that impairs future flow |
The five flow metrics
- Flow Distribution: the proportion of each flow item type within a value stream. Setting flow distribution is the starting point for the framework since all other metrics depend on it. It makes the tradeoffs between feature delivery, debt paydown, and risk work visible and explicit.
- Flow Velocity: the number of flow items completed over a given period. Unlike traditional agile velocity, it doesn't rely on estimation; it's an empirical measure based on direct observation. If 10 features and 5 risks are completed in a release, flow velocity is 15.
- Flow Time: how long it takes to deliver a flow item from the decision to take on the work to the value being delivered. Four flow states: New, Waiting, Active, Done. Flow time measures Active to Done. Lead time is less useful because items can sit in a backlog indefinitely.
- Flow Load: concurrent work-in-progress within a value stream. Too high a flow load degrades velocity and extends flow time.
- Flow Efficiency: the ratio of active work time to total elapsed time. Flow efficiency drops as dependencies create waiting time. It surfaces bottlenecks and queuing problems that are otherwise invisible.
Business results per value stream
Each value stream should be tracked against four categories of business results:
| Category | Example metrics |
|---|---|
| Value | Revenue, MRR, 7-day active users |
| Cost | Total staff, operations, and infrastructure spend |
| Quality | Escaped defects, NPS, retention |
| Happiness | eNPS, employee engagement |
Four questions everyone in the organization should be able to answer
- Who is the customer?
- What value is the customer pulling?
- What are the value streams?
- Where is the bottleneck?
Software vs manufacturing: key differences
- Variability: manufacturing minimizes variability; software has to embrace it.
- Repeatability: manufacturing maximizes throughput of the same widget; software maximizes iteration and feedback loops that continually reshape it. The process must be optimized for flow, feedback, and continual learning, not repeatability.
- Design frequency: physical products are designed up front; in software, design happens inside the system during delivery.
- Creativity: manufacturing increases automation and removes creativity from production; software focuses on enabling creativity and collaboration at every step.
Five sources of waste (Dominica DeGrandis, Making Work Visible)
- Too much work in process: overloading teams leads to inefficiency and reduced flow.
- Unknown dependencies: unrecognized dependencies between teams, components, and products generate unplanned work.
- Unplanned work: emergencies and rework disrupt planned activities and introduce bottlenecks.
- Conflicting priorities: misaligned goals across the business impair decision-making and delivery.
- Neglected work: deferred technical debt and zombie projects accumulate and hinder flow.