I was looking at the long respin cycles taking place in some of our projects and I came to the conclusion that we are not factoring in WIP (work-in-progress) inventory during product design. In more simple terms, it means “release fast - release often”. This philosophy is merely an implementation of queuing theory applied to fields like lean manufacturing and product design. What happens is that, classically, all work is thought of in terms of %age utilization of resources (in our case people). However, what we should be looking and analyzing instead is product design queues.

In any queue based system (like manufacturing for example), the philosophy of identifying has long since shifted from increasing utilization to reducing spare inventory. In software, spare inventory is usually work-in-progress. Practically, what happens is that when you have a long laundry list of items pending for deployment and which go together, it hits all the symptoms of getting-rid-of-spare-inventory.

What I propose is that we move to a system of much more frequent deployments. Before the product management team gets all happy (!), let me mention that it comes with its tradeoffs - reduced resource utilization is the most frequent. For example, if one looks at some of our sprints, we can see that we had very broad-impacting releases  (typically accompanied by a bunch of seller mailers, communiques, full QA cycles, etc.) - in short a lot of dependencies, which translates into long queues. What you will also see is that I deliberately reduced WIP inventory during that period, which is why you will see reduced resource utilization. However, it allowed us to focus and maintain quality in our releases.This means that product management’s metrics should factor “cycle time” as one of the metrics - time taken to conceive a product to putting it into production - rather than focus solely on resource utilization as the only metric. The important thing to remember is that more often than not, cycle-time will be inversely proportional to resource utilization. This is not an axiom but a mathematical fact born out of queuing theory.