Why Controlling Work-in-Progress (WIP) Matters: Lessons from Ancient River Management

This piece introduces the most important yet challenging Kanban practice—controlling work-in-progress (WIP)—and frames it with a story about why to control it (Why), what to control (What), and how to control (How).

5.1 Why Control WIP

Using the historical example of Pan Jixun, a Ming‑dynasty water‑management expert, the article describes his "束水攻沙" (constrict water to wash sand) method, which accelerated river flow to remove sediment. The analogy shows that limiting WIP in product development speeds up value delivery and exposes issues, just as faster water carries away sand.

Applying Little's Law (Average Delivery Cycle = Average Parallel Demand / Average Delivery Rate), the article explains that fewer parallel items reduce cycle time, enabling faster market response.

Average delivery cycle = average parallel demand / average delivery rate

Controlling WIP not only shortens cycles but also makes problems visible. A quoted proverb from Pan Jixun—"急则沙随水流，缓则水漫沙停"—illustrates that unchecked flow leads to accumulation of issues.

急则沙随水流，缓则水漫沙停 —— 潘季驯

Three purposes of WIP control are highlighted: 1) accelerate value delivery, and 2) expose problems instantly.

5.2 WIP in Product Development

Examples show WIP manifesting as backlog in a single stage, the need for end‑to‑end visibility, and the user perspective as the ultimate standard for determining WIP.

In a waterfall project, many requirements pile up in development, creating hidden risks and delayed testing. Visualizing WIP helps identify completed, near‑complete, and problematic items, reducing parallel work and restoring flow.

Another team reduced parallel work early but later accumulated WIP in testing and release phases, showing that WIP control must consider the entire system, not just individual stages.

From a user viewpoint, even completed sub‑tasks are still WIP if they cannot be delivered, emphasizing the need for cross‑team integration before considering work finished.

5.3 Negative Impacts of WIP

Drawing on Don Reinertsen’s research, the article lists six problems caused by excessive WIP: longer delivery times, hidden risks, increased coordination load, higher system variability, reduced team motivation, and degraded quality.

Unlike manufacturing inventory, WIP in product development is invisible financially and physically, making it easy to overlook despite its detrimental effects.

By visualizing value flow and treating WIP as inventory, organizations can better manage and reduce it, setting the stage for the next article on practical WIP control techniques.

Summary

WIP comprises all started but not yet delivered work; controlling it requires an end‑to‑end, user‑centric view to lower system‑wide WIP and improve product development performance.