6 Flow in your development cycle

Flow in software development is presented as the movement of value from an idea to something users actually experience in production. The chapter argues that what matters is not how busy developers appear, but how long it takes work to travel through the whole system. Like a manufacturing value stream, software delivery contains value-adding steps, necessary checks, and pure waste such as waiting, rework, and queues. Much of the hidden delay comes from invisible inventory: open branches, pending reviews, blocked environments, and work already started but not yet delivered.

The chapter emphasizes that improving flow starts by seeing the real system and measuring it honestly. Value stream mapping reveals where work spends time transforming and where it sits idle, often showing that only a tiny fraction of the total lead time is active work. It distinguishes multiple streams, such as features, defects, and deployments, and shows that each can be slowed by different constraints. The key insight is that optimizing a single step, like coding or build speed, does little if the real bottleneck is elsewhere, such as review queues, deployment approvals, or meeting cadences.

To improve flow, the chapter recommends shrinking batch sizes, limiting work in progress, and focusing on the constraint that governs throughput. Smaller changes move faster, are easier to review, and surface defects sooner, while WIP limits force teams to finish work instead of juggling too many tasks. The same logic applies to CI/CD: automation helps only when it reduces waiting and preserves feedback speed, but becomes harmful when it adds validation delays or queue depth. Overall, the chapter frames flow as a system property that improves through deliberate, measured changes aimed at removing delay, exposing bottlenecks, and redesigning the path from idea to user value.

A typical manufacturing value stream from raw material to customers' hands.

A typical software value stream from an idea to a feature in production, delivering user value.

A full value stream exposing the length of time a typical small fix takes to flow through the system.

A clean, formal view of a typical value stream from request to production.

A realistic view of a typical value stream from request to production.

A feature value stream that shows typical delays that contribute to a low activity ratio.

A defect value stream that shows typical phases that a bug fix flows through.

A deployment value stream that shows the role governance can play in a typical production push.

The true value stream extends beyond just what engineering delivers.

Batch size comparison for impact on the value stream and feedback flow.

Causes of inflated WIP without any malice involved, just a desire to stay active and busy.

A simple flow-based decision-making method for WIP management for a team.

A growing bottleneck week by week as reviews become the constraint in the system.

The simplified ToC model to focus on the low capacity constraint.

Current value stream of a simple work breakdown and acceptance cadence.

Future value stream designed to elevate the constraint

• Flow is the movement of value from idea to user, not the speed of coding.
• Activity ratio reveals where you spend more time waiting than adding real value.
• Large batches amplify delay, risk, and rework. Small batches protect feedback and reduce the blast radius.
• High WIP hides constraints; low WIP exposes them.
• The bottleneck governs throughput, regardless of effort elsewhere.
• Improving non-constraints increases inventory, not flow.
• Future value streams must be designed deliberately, not assumed.
• CI/CD protects flow when it reduces waiting; it disrupts flow when it becomes the constraint.
• Release is part of the value stream; batching at the end reintroduces delay.
• Flow improves through targeted Kaizen, not sweeping reform.

FAQ