Library→First Way: Flow→Concepts→The Principle of Flow
The Principle of Flow
How work moves through a system. Why fast flow reduces risk, improves quality, and accelerates learning.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
What is flow?
Flow is the smooth, continuous movement of work from left to right through a value stream — from development to operations to the customer. When work flows well, features move quickly from idea to production without piling up, waiting, or being blocked.
The concept comes from Lean Manufacturing. Taiichi Ohno at Toyota observed that the fastest way to produce something is not to work harder on individual steps, but to eliminate everything that stops work from flowing. The same principle applies to software.
The three properties of good flow
Fast
Work moves from commit to production in hours or days, not weeks or months. Every delay is a signal that something is blocking flow.
Smooth
Work does not pile up at any one stage. No single step is a bottleneck that everything waits on. The rate of work entering equals the rate leaving.
Visible
You can see where work is at all times. Blocked work is immediately visible. Problems surface quickly before they compound.
Why fast flow reduces risk
This seems counterintuitive. Surely moving faster means more mistakes? The opposite is true.
- 1
Smaller changes
Fast flow requires small batches. Small changes are easier to understand, test, and debug. A 10-line change is safer than a 10,000-line change.
- 2
Faster feedback
When something breaks in a small change, you know immediately what caused it. In a large monthly release, finding the root cause takes days.
- 3
Less work in progress
Lower WIP means fewer things can go wrong simultaneously. Less context switching means higher quality work.
- 4
Earlier problem detection
Problems found in development cost 10x less to fix than problems found in production. Fast flow pushes problems left, closer to their source.
DORA research shows elite performers deploy 973x more frequently than low performers and have 6,570x faster lead times — with 3x lower change failure rates. Speed and stability are not trade-offs. They reinforce each other.
Flow vs throughput
A common mistake is to optimize for throughput — getting each individual step to work as fast as possible. But local optimization does not improve global flow.
Example: If Development doubles its speed but Review stays the same, work piles up at Review. The team is busier, but value is not reaching customers faster. Flow is a system property, not a local property.
Throughput thinking
How fast can each team or step work? Optimize locally. Measure individual velocity.
Flow thinking
How fast does work move end-to-end? Optimize the system. Measure lead time.
Flow at Nexus Corp
When you joined Nexus Corp, the value stream had 41.5 days of total lead time with 18% flow efficiency. Here is how each mission improved flow:
Further reading
DevOps Handbook
Part II: The First Way — The Technical Practices of Flow. The complete playbook for fast, reliable software delivery.
The Phoenix Project
Parts 1-2: The Three Ways. Bill Palmer's journey from chaos to flow through IT transformation.
Lean Thinking — Womack & Jones
Chapter 3: Flow. The source material — how Toyota eliminated everything that stops work from moving.
DORA 2023 State of DevOps Report
Key findings on deployment frequency and lead time. The data behind elite vs low performer comparisons.