Finding and Addressing Bottlenecks

A bottleneck is a stage that limits the throughput of the entire system. It's the slowest step in the process.

Theory of Constraints (Eli Goldratt): The output of the system can never exceed the output of the bottleneck. Improving anything other than the bottleneck doesn't improve the system.

In Kanban:

• Work piles up in front of the bottleneck
• Downstream stages are starved
• The bottleneck's throughput = system throughput

Metrics that reveal bottlenecks:

1. Queue lengths (WIP in waiting states) If "Ready for QA" has 8 items while other queues have 1-2, QA is likely the bottleneck.

2. Time in stage If items spend 3 days in development but 5 days in code review, code review is slowing things down.

3. CFD band widths Wide bands = high WIP = bottleneck. Look for bands that grow over time.

4. Age of oldest item per stage If the oldest item in "Deploy" is 2 days but oldest in "Testing" is 10 days, testing is the constraint.

Common bottlenecks in software teams:

• Code review (not enough reviewers)
• QA/Testing (insufficient capacity or automation)
• Deployment (manual processes or infrequent releases)
• Requirements/Design (upstream bottleneck)
• Approvals (waiting for stakeholders)

Once you've identified the bottleneck, options include:

1. Add capacity to the bottleneck

• More people
• Cross-training
• Automation
• Remove waste from the bottleneck process

2. Offload work from the bottleneck

• Can other stages help?
• Can the bottleneck work be simplified?
• Can some work skip the bottleneck?

3. Reduce demand on the bottleneck

• Tighter WIP limits upstream (don't flood it)
• Better preparation of work items
• Batching (sometimes—trade-off with flow)

4. Subordinate other stages to the bottleneck

• The bottleneck sets the pace
• Don't optimize non-bottlenecks (wastes effort)
• Feed the bottleneck at exactly the rate it can consume

5. Elevate the bottleneck

• Invest in making the bottleneck faster
• Eliminate the constraint entirely if possible

When you fix a bottleneck, a new one appears. This is expected and healthy.

The cycle:

1. Identify the bottleneck (QA)
2. Improve it (automation, cross-training)
3. A new bottleneck emerges (now it's code review)
4. Identify and address the new bottleneck
5. Repeat

Common progression in software teams:

1. First bottleneck: Testing/QA
2. Fix: Test automation, cross-training → Bottleneck moves to...
3. Second bottleneck: Code review
4. Fix: Pair programming, async reviews → Bottleneck moves to...
5. Third bottleneck: Deployment
6. Fix: CI/CD, feature flags → Bottleneck moves to...
7. Fourth bottleneck: Product decisions

This is progress! Each time the bottleneck moves, your system capacity has increased.

The danger: Trying to fix all bottlenecks at once. You can't. Focus on the current constraint. When it's no longer the constraint, move to the next.