Managing WIP at the Program Level

Everyone talks about WIP limits in the context of Kanban boards and individual teams. But the place where uncontrolled work-in-progress causes the most damage is at the program level — where multiple teams, shared dependencies, and competing priorities create a perfect storm of context switching and delayed delivery.

The Program-Level WIP Problem

When I took over managing three concurrent programs, one of the first things I noticed was that individual teams had reasonable WIP limits, but the program as a whole did not. Engineers were being pulled between projects. Architects were reviewing designs for three different initiatives simultaneously. Shared infrastructure teams were juggling requests from everyone.

The result was predictable: everything was in progress, nothing was finishing. Lead times ballooned while everyone stayed busy. The utilization numbers looked healthy. The outcomes did not.

How I Think About Program WIP

I track WIP at three levels. Team-level WIP is the standard Kanban metric — how many items are in progress per team. Cross-team WIP tracks how many initiatives require coordination between two or more teams at any given time. And individual WIP monitors how many projects each key person is actively contributing to.

The third one is the most revealing. When I found that our lead architect was actively involved in seven different workstreams, it explained why every architecture decision was taking three times longer than it should. The constraint was not capacity — it was attention.

Making It Work

I negotiated with stakeholders to sequence work rather than parallelize everything. Instead of three programs each getting thirty percent of a shared resource's attention, we structured dedicated sprints where the resource focused on one program at a time. The throughput improvement was immediate.

I also introduced a simple rule: no engineer works on more than two programs in a sprint. Exceptions require my explicit approval with a documented reason. This felt restrictive initially, but the teams reported significantly less cognitive load and higher code quality within weeks.

Program-level WIP management is unglamorous work. But it is some of the highest-leverage work a program leader can do.