How busy should a development team be? The immediate answer from most managers is “Constantly.” People on development teams are expensive resources. Unless they stay busy they are wasting time and money. They should strive for full utilization.
Unlike some metrics, utilization is fairly easy to measure, another attractive quality for managers. Staff can track time against projects to show that they put all of their time to good use.
Most engineers echo this thinking. When talking about how to handle things that block team progress, the first question they ask is “What do I do when I’m blocked?” They’ve been drilled all their careers in the need to stay busy and spend as much time as possible on project work.
Every engineer I know has a long list of side projects to work on when he has time, things like learning a new programming language, becoming more expert in a programming tool, improving some oft-used utility, and so on. Yet even with so many options they worry about failing to stay busy on project work.
It goes without saying in these settings that idle teams are an avoidable cost. But a more complete economic analysis shows something very different.
The responsiveness to new work requests depends strongly on availability of those resources. At low utilization, resources are available to work on new requests. At high utlilization the requests queue up waiting for resources to become available. And as utilization approaches 100%, the wait times soar.
This cost of delay from queueing time for work awaiting resources, the price you pay for later delivery of value through completion of the work, looks like the blue curve in the following figure. (See Reinertsen’s Principles of Product Development Flow for a full treatment.)
At the same time, idle resources waiting for work impose a different type of cost. These are proportional to the idle time for the team, and so they look like the purple line. At 0% utilization you pay full cost, and at 100% utilization you pay zero cost.
Adding these two costs gives the green total non-productive cost curve. This curve reaches a minimum somewhere between the two extremes of 0% and 100% utilization. While the exact shape of this curve may vary, the general shape remains. Pushing for high utilization will at some point move you away from optimum total cost.
In addition, the brown lines tangent to the cost of delay and total cost curves show the impact of disruption at a couple of utilization levels. Note that near the optimum point the impact is relatively low compared to the steep impact at very high utilization. We’ve all experienced this—when everyone is busy the smallest disruption makes timing vary wildly and unpredictably. And almost all surprises disrupt to the right, needing more rather than fewer resources.
In a seemingly reasonable quest to avoid wasting time and money, managers routinely push for high utilization. In doing so they simultaneously increase the total costs of development and undermine predictability. The easy measurement of utilization serves them poorly. Contrary to popular belief, full utilization is not maximally productive.
Moving away from full utilization and allowing some slack in the system lowers the total cost of development and avoids the extreme unpredictability that comes from spiking wait times. Are you too far out on the curve toward full utilization? Try lowering your utilization slightly and measuring the effect.
Posted by William Baxter on Nov 1, 2015