Flow Efficiency - Lean Software Development

1The Flow Efficiency Formula

Flow efficiency is a simple but powerful metric:

Flow Efficiency = (Value-Add Time / Lead Time) × 100%

Value-add time is time spent on activities that directly create value for the customer. Lead time is the total elapsed time from request to delivery.

Example: A feature has 10 days lead time. Actual value-add work was 2 days (development, some testing, some deployment work). Flow efficiency: 2/10 = 20%.

Typical flow efficiency in software: 5-15%.

That means 85-95% of the time, work is not being worked on. It's waiting. In queues. For decisions. For handoffs. For batch releases.

This number shocks most teams. They feel busy. They work hard. But the work itself? Mostly sitting idle.

The Efficiency Paradox

Organizations optimize for 'efficiency' by maximizing utilization—keeping everyone busy. But high utilization creates queues, queues create waits, and waits destroy flow efficiency. Being less busy can mean being more efficient.

2Why High Utilization Destroys Flow

Here's the counterintuitive truth: high utilization kills flow efficiency.

Consider a developer at 95% utilization. They're always busy. No slack. When new work arrives, it goes into a queue because they're working on something else. The queue grows.

Now consider a developer at 70% utilization. They have slack. When new work arrives, they can often start immediately. Queue stays small. Lead time stays short.

This is queuing theory, proven mathematically: as utilization approaches 100%, wait times approach infinity. The relationship isn't linear—it's exponential. Going from 80% to 90% utilization might double wait times. Going from 90% to 95% might triple them again.

Resource efficiency vs. flow efficiency:

Resource efficiency: Keeping people busy. "Everyone is working."
Flow efficiency: Moving work through fast. "Things get done quickly."

These are often in tension. Maximum resource efficiency creates queues and destroys flow efficiency. Good flow efficiency requires slack—which looks like "inefficiency" to resource-focused managers.

The 95% Utilized Team

Every developer is 95% utilized. The backlog never shrinks. Lead times are 6+ weeks. Management celebrates: 'We're running lean!' But customers wait months for features. The team is at capacity but not delivering.

The Slack-Rich Team

Developers are 70% utilized on feature work. 30% is slack, improvement, learning. When urgent requests come, they're handled immediately. Lead time is 3 days. Less utilization, more delivery.

3Improving Flow Efficiency

To improve flow efficiency, you must reduce wait time. How?

Limit WIP: Less work in progress means less queuing. When you finish something, capacity is available. New work can start immediately.

Reduce batch sizes: Big batches mean big waits. Small batches flow through faster.

Eliminate handoffs: Each handoff is a potential queue. Cross-functional teams eliminate handoffs.

Make decisions faster: Slow decisions are a form of wait. Empower teams to decide. Reduce approval chains.

Continuous deployment: Weekly or monthly releases are batching. Deploy continuously to eliminate deploy waits.

Visualize queues: Make waiting visible. If you can see items piling up, you can address it.

Accept lower utilization: This is the hard one. You may need to tolerate "underutilized" resources to achieve flow. The trade-off is worth it.

The goal isn't 100% flow efficiency—that's impossible. But moving from 5% to 25% can transform delivery. It means 5x less waiting without working any faster.

Measure It

Calculate flow efficiency for your last 5 completed items. Divide value-add time by lead time. If you're above 25%, you're doing well. If you're under 10%, there's significant opportunity.