Michael Kennedy did his readers a real service by calling his excellent book Product Development for the Lean Enterprise instead of the more obvious Lean Product Development. In that book, Kennedy describes the set-based principles of the Toyota Development System, and how they may be applied to any product development business. TDS is a fascinating system, equally as innovative and interesting as the Toyota Production System, but also very different in the mechanism of its operation.
On the other hand, my own journey down the road of lean development started with Donald Reinertsen’s Managing the Design Factory. Don’s description of Lean Product Development is more like the application of lean production principles to product development, breaking the work into small pieces, managing capacity, measuring flow, and delivering value incrementally. It is this view of lean that my friend David Anderson expounded upon in his book Agile Management for Software Engineering.
The difference between TDS and TPS creates a lot of confusion in discussions about Lean Product Development. Does LPD mean product development targeted to lean production systems? Or does it mean the principles of lean production applied to product development? These two definitions have very different consequences.
If it wasn’t already clear, I am decidedly in the camp of lean production principles applied to product development workflows. Even though I think TDS is ingenious, and I wholeheartedly endorse set-based thinking, I do not consider TDS to be Lean Product Development. To me, lean development is a means to an end. That end is evolutionary design, and lean production fits that end in a way that set-based development does not. Which is not to say that there is not a strong evolutionary interpretation of SBD, as large-scale open source development is exactly that. But I’m not really speaking to the open source audience here. I expect my readers are largely of the enterprise variety, building products or IT systems to spec and for hire. And evolution with such finite resources means flow.
Observant readers have probably noticed that I don’t talk much about Mary and Tom Poppendieck here. I feel a little bit bad about that, because I think they deserve credit and respect. I think they have done the software profession a tremendous service by popularizing the relevance of lean principles to software development. But they have also done a couple of things that bother me, including blurring the definition between set-based, time-boxed methods like TDS and continuous workflow methods like TPS. The consequence of this is that people can (and do) weasel out of lean principles by hiding behind the weakest interpretation. By conflating these definitions, the Poppendiecks, perhaps unwittingly, encourage their readers to claim to be lean while avoiding actually doing it. One of the greatest offenses I see again and again is the rationalization of “craftsmanship” under the auspices of Lean.
In contrast, Womack and Jones (and Roos) were not at all ambiguous about what is Lean and what is not. Jim Womack, who coined the expression, “lean production,” to describe the principles behind the Toyota Production System, explicitly defined lean production as neither craft production nor mass production. Not craft production is part of the definition of lean, and he dedicates whole chapters in his books to why craft production is inferior:
Our advice to any company practising “craftsmanship” of this sort in any manufacturing activity, automotive or otherwise, is simple and emphatic: Stamp it out.
- The Machine that Changed the World, The Strange Case of the “Craft” Producers
Now, I realize that development is not manufacturing. But using that as an excuse to rationalize craft methods is overwhelmingly contrary to philosophy of lean. I am not saying that you shouldn’t practice craft development if that’s what you want to do. But claiming that it is lean to do so is either ignorant or outrageously dishonest. Standard Work is not an optional practice. Craftsmanship means doing it your way, Standard Work means doing it our way. If you’re not doing Standard Work, you’re not doing Lean. Period.