Why Limiting Work-in-Process Is Important
There is a certain mindset that is hindering organizations from limiting their work-in-process (WIP) during product delivery. You might ask yourself why limiting WIP is important. First, remember that WIP refers to the unfinished work items that linger during the various stages of the value stream.
According to Little’s Law, the higher the WIP, the longer it takes to deliver from concept to cash. There is strong empirical evidence suggesting that better software quality is attained when we limit the WIP.
At the Lean Kanban Central Europe Conference in October 2012, Don Reinertsen's presentation, “The Science of WIP Constraints,” addressed the scientific basis supporting setting WIP constraints in product development. According to Reinertsen, as system utilization increases, large queues are accumulated, which significantly increase the cycle time.
Going further on this point, Alan Shalloway wrote in this Scrum Alliance article that working on multiple items at the same time can make a team’s productivity decrease while the defect rate goes up.
Jeff Anderson sees this as an analogy between the flow of features and the flow of vehicles in a highway, as he wrote in a blog post “Explaining Why Limiting WIP Is So Important.” In this post, Anderson gave quantitative figures proving that the average vehicle velocity is lowered when highway utilization goes up.
But if limiting WIP is important, why do we not practice it?
Maybe it’s because limiting the WIP requires a new organizational mindset rather than just adding another team value. In my own work, I have found that the lack of understanding of how experimental product development can be is a common cause of failing to set the WIP limit.
For example, Steve Berczuk in his Techwell post, “How Software Leans toward Agility and Experimentation,” wrote that “software development seems like a natural medium for experimentation and agility.”
Usually, people who are in charge of a clogged delivery cannot easily buy into the idea of limiting WIP. To counter this, Reinertsen explained in his slides a model for adding work to queues by which the sender (management) senses the first response from the receiver (delivery organization) before sending more work.
As a result of this unbalance between demand and throughput, management establishes projects to compensate for the uncertainty in delivery. Such projects could be avoided if the teams were trusted to set their WIP limits.
I would like to hear your comments on this cultural perspective of organizations that do not limit WIP.
