There’s a fascinating piece by Michael Feathers in which he questions the what “inventory” is in the context of lean software development, and concludes that companies should remove the code supporting unprofitable features. I don’t agree with his piece entirely, but his thinking, and the debate in the comments, draws out a curious aspect of lean software development: Waste gets confused with inventory.

The Toyota Production System (TPS) tries to eliminate waste, of which the most tangible example is inventory (stuff hanging around the factories waiting to be used). The TPS gave rise to lean manufacturing which focuses on eliminating inventory. And then software developers, impressed with those efficiencies and with an innate desire to be efficient, try to emulate lean manufacturing: they ask “what is inventory in our world?” when they should be asking “what is waste in our world?”

Let’s look again at what’s happened here:

1. A specific, real world problem (waste in Toyota’s car production) gets a specific solution (the Toyota Production System).
2. The solution gets generalised to a reusable framework for manufacturing more widely (lean manufacturing).
3. Another community of people try to derive their own process from the generalised framework by using analogies (“what is our inventory?”)

But when you start picking away at the wrong part of a theory you end up in all sorts of trouble. The wrong part of the theory in this case is the analogy (inventory), whereas the substance is about eliminating waste.

When we focus on the analogy we get confusing results. Traditional lean software development says inventory is undelivered requirements. Michael Feathers and others say it’s code. Alistair Cockburn says it’s unvalidated decisions. We get three different answers because we’re dealing with something which is necessarily removed from reality. (If we were to return from the analogy to the real world then it’s no longer an analogy.)

Similarly, the analogy is difficult to translate in other situations. What is inventory when it comes to, say, the maintenance of social housing?

On the other hand, focusing on the reality gets us real results. The original TPS focused on eliminating waste, one measure of which is reducing lead time. From this perspective we can see that improvements in the maintenance of social housing can be achieved by eliminating waste in the request-to-repair process and measuring success through lead time. In fact, this is one case study John Seddon uses in “Freedom from Command and Control”. This also explains why Seddon says “lean drives me potty” — because lean tends to be based on car production, and people refer to that rather than its underlying principles.

Focusing on eliminating waste (and proving success through measuring cycle time or lead time) also gives us a particular process for software development. This delivers working software very effectively, and given such a system we may then draw analogies with Japanese car production, if we like, and talk about “inventory” and dub our monitoring board a “kanban board”.

Analogies are helpful, but we mustn’t get too hung up on them. The Toyota Production System demonstrated how efficient you can be with a relentless focus on eliminating waste. But it’s easy to get distracted by the abstractions and the generalisations. In the end we must not lose sight of what the actual problem is.