The Problem Nobody Wants to Name

Ask any engineering manager why their team is slow and you will hear the same answers - unclear requirements, technical debt, too many meetings, not enough engineers. These things are real, but they are rarely the primary cause of slow delivery.

The primary cause, in most teams, is that too many things are being worked on at the same time.

This is counterintuitive. More work in progress feels like more activity. More activity feels like more productivity. But it is not. The relationship between Work In Progress (WIP) and delivery speed is not linear - it is deeply nonlinear, and understanding why changes how you see your entire system.

Little's Law

John Little, an MIT professor, proved a result in 1961 that applies directly to software delivery. Little's Law states:

Average Cycle Time = Average WIP / Average Throughput

In plain language: the average time it takes to complete a piece of work equals the average number of things being worked on divided by the average rate at which work is completed.

The implications are significant. If your team completes five items per week and has fifteen items in progress, your average cycle time is three weeks. If you reduce WIP to ten items while maintaining the same throughput, cycle time drops to two weeks. No new engineers. No process overhaul. Just fewer things in flight at once.

The inverse is also true. Adding more work to a system that is already at capacity does not increase throughput - it increases cycle time. Every item added to an overloaded system makes every other item slower.

WIP and the Cost of Multitasking

WIP limits matter at the team level. But the same physics apply to individual engineers, and the costs there are just as real.

When an engineer switches between two tasks, neither task moves as fast as it would if they were focused on one. The switching cost is not just the minutes lost to context switching - it is the cognitive overhead of maintaining two separate mental models, two sets of open questions, two streams of decisions.

Research on multitasking consistently finds that human performance degrades significantly when attention is split. In knowledge work, where the primary tool is focused thought, this degradation is pronounced. An engineer splitting their time between three concurrent tasks is not working at 33% capacity on each - they are working at something closer to 20% on each, and spending the remaining 40% on switching overhead.

The practical implication: when you ask engineers to pick up a new piece of work while their current work is blocked, you are almost always making the situation worse. The better intervention is to remove the block.

Identifying Your Real WIP

Most teams dramatically undercount their WIP because they only count work that is explicitly tracked on a board. The real WIP includes:

• Items on the board in active development
• Items waiting for code review (blocked, but still in progress from a system perspective)
• Items in testing that are generating bug reports being worked on
• Bug fixes that are not on the sprint board
• Support escalations being handled alongside feature work
• Ad hoc requests from stakeholders handled informally
• Onboarding or knowledge transfer responsibilities

When you add it all up, most teams are carrying two to three times more WIP than their board suggests. This hidden WIP is particularly damaging because it is invisible - it does not appear in planning, does not get discussed in standup, and does not inform capacity decisions.

How to Surface Hidden WIP

Run a simple exercise with your team. Ask everyone to list everything they are actively working on or feel responsible for - including things not on the board. Gather the results anonymously and read them out. The response is almost always surprise at how much is actually in flight.

From there, the question is: which of these items should be tracked? Which should be deferred? Which should be stopped entirely?

Setting WIP Limits

WIP limits are a constraint you set on how many items can be in a given state at once. The most common implementation is a per-column limit on a kanban board - no more than four items can be in "In Progress" at any time.

When a limit is reached, the expectation is that people stop pulling new work and instead swarm on completing existing work. This is the key behaviour change. WIP limits force collaboration and completion over individual activity.

Finding the Right Number

There is no universal formula for the right WIP limit, but a reasonable starting point is one or two items per engineer in a column. A team of five engineers with a WIP limit of six in the "In Development" column is constrained enough to create useful friction without being so tight that people sit idle.

Expect the first WIP limits you set to be wrong. Set them, observe the system for two to four weeks, and adjust. If the limit is never reached, it is too high. If it is constantly causing conflict, it may be too low - or you have a systemic block that needs addressing rather than a number adjustment.

Kanban vs Scrum Approaches to WIP

Kanban makes WIP limits explicit and structural. They are built into the board design and the system does not permit violation without deliberate decision.

Scrum manages WIP implicitly through sprint capacity. The sprint commitment is supposed to represent what the team can complete, which in theory limits WIP to the sprint scope. In practice, sprint scope creep, mid-sprint requests, and carry-over work routinely push teams over sensible WIP levels.

Neither approach is inherently superior. The question is which creates more useful discipline for your team's context. Teams doing highly variable, interrupt-driven work often find kanban a better fit. Teams with more predictable, planned work often find scrum's cadence useful.

What matters is that the system - whatever it is - has some mechanism for making WIP visible and creating pressure to complete rather than accumulate.

Making Flow Visible

WIP limits only work if the system is visible. That means a board that reflects reality - not a theoretical board that nobody maintains because the real work happens in Slack and email.

Cycle Time Tracking

Start measuring cycle time for every item. The time from "work started" to "work delivered" is your primary flow metric. Plot it over time. Look for trends. Look for outliers - items that took dramatically longer than normal are usually a signal about a systemic issue.

Cumulative Flow Diagrams

A cumulative flow diagram shows the count of items in each stage over time. When stages bulge - when the "In Review" band grows wide - it tells you there is a bottleneck at review. When the "Done" band grows slowly, it tells you throughput is low. These visualisations make invisible patterns visible.

Aging Work Items

Track how long each item has been in its current state. Items that have been "In Progress" for three weeks are almost certainly blocked or abandoned, even if nobody has said so. Aging work surfaces the real state of the system.

Common Resistance and How to Address It

The most common objection to WIP limits is that they will cause people to sit idle. This almost never happens in practice because there is always productive work to do - reviews to complete, documentation to write, bugs to investigate, technical debt to address.

The second most common objection is that the work is too variable and unpredictable for WIP limits to work. This is an argument for kanban over scrum, not an argument against WIP management. Variable work especially benefits from flow-based approaches because they adapt to change rather than resisting it.

The hardest objection to address is from managers who measure productivity by activity rather than outcomes. WIP limits make periods of focused completion look like "people aren't busy." The conversation here requires shifting the frame from activity to flow - the goal is not maximum individual busyness, it is maximum rate of value delivery.

Getting Started

Start small. Pick one team. Put a WIP limit on a single column - "In Progress" is usually the right choice. Set it at roughly team size plus one. Run it for four weeks without adjusting. Review cycle time data. Then adjust.

The discomfort that WIP limits create is the point. They make invisible problems visible. The tension of a blocked WIP limit is the system telling you something needs attention. Your job as a leader is to treat that signal as information rather than noise.