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.
Kanban discussion
Kanban Group
Jay Packlick | 25-Mar-08 at 2:53 pm | Permalink
I’m curious how you think one might go about applying the concept of standard work (and the elimination of variation) to development activities that by their nature are creative and uncertain exhibiting unpredictable durations. How does one standardize the work of developing a new OR algorithm or a new molecule? The answer is you don’t; instead you optimize the system to accommodate the variation inherent in the process. If you’re trying to apply standard work to the creative elements of development, that’s not lean since by its nature – attempting to do so is wasteful. A much better model than manufacturing to look to for optimizing the development process is the modern computer operating system that does a darned good job of prioritizing and streamlining the flow of intrinsically unpredictable (and thus non-standard) work. In other words, embrace variation. Seeing to eliminate it in development is quixotic.
Corey Ladas | 25-Mar-08 at 4:40 pm | Permalink
Hi Jay,
I agree that it would be possible to get carried away with standardizing development work and suffocating creativity, but creative engineering does not have to mean poetic anarchy.
Not all parts of the development process are equally creative, even for the most novel problem. And not all software development problems are especially novel. Most of the work that most developers do most of the time is significantly less novel than designing a new algorithm or a new molecule. I tried to say as much with my spectrum of novelty post.
Even then, methods like TRIZ or Dijkstra’s method of Correctness by Construction aim to make even inventive work somewhat regular and predictable. Probabilistic methods like Pugh Concept Selection or Toyota’s set-based development reduce variation through resource buffering, allowing wide variation for individuals, but narrow variation for the process as a whole. Agile methods like user stories, planning poker, pair programming, and time-boxed iteration are also focused on reducing or controlling process variation.
One of the things we try to focus on is distinguishing things that have intrinsic variation from things that shouldn’t. For variation that is truly necessary, we do not seek to eliminate it, we only seek to control it. The variation that we seek to eliminate is only of the unnecessary variety.
There are all sorts of things that could be subject to standards that shouldn’t constrain meaningful creativity. Coding conventions, design rules, check-in procedures, test coverage targets, inspection procedures, and so on, are not the places to look for creative license. Further, the Lean idea of standard work is not the blind following of a rule for once and for all. Standards are the foundation of Kaizen, or continuous improvement, and you can’t have one without the other. A standard isn’t the best way to do something forever. It is only the best way that the team knows how to do something today.
We don’t see Lean as being exemplary of manufacturing. Lean and Kanban, as principles, apply to any work that has a natural sequence. And as you suggest, processor scheduling is indeed a good place to look for inspiration in general scheduling problems, especially when you know what it is that you are optimizing for. In our case that is almost always throughput.
The SEI’s Team Software Process and Personal Software Process are very helpful in understanding the role that kaizen-style process standards can play in software development.
Jay Packlick | 28-Mar-08 at 11:28 am | Permalink
“Poetic anarchy” (a brilliant term) is clearly a bad thing where economic outcomes are a concern, but then so are standards that don’t add value. The examples you cited generally DO tend to add value in most contexts (all the ones I’ve seen, but I haven’t seen them all).
Finding the balance between harnessing creativity and value added standards is a delicate balancing act requiring skill, understanding, and feedback; tilting too far in either direction results in waste.
The mistake too many organizations make is drinking the Kool-Aid on the latest craze set of practices without taking the time to understand the underlying principles that made them work in the contexts in which they emerged. Adaptations are almost always needed. Pair programming, for example, can pay off big in terms of productivity and quality however, slavishly followed as a standard it can lead to waste for some programming activities.
For lean to be truly successful in an organization, it’s leaders need to grasp the underlying principles so that they can be applied to maximize value in that organization’s context (i.e. market goals, corporate culture, customers, geographic area, work-force distribution, types of systems, competition, etc.)
Even fixed duration iterations are not sacrosanct; some of the more lean development organizations are evolving toward a more constant single-piece feature flow model of development.
As a complete aside - the real breakthroughs in productivity possible in lean development I think will come more from optimizing the interactions between the different parts of the organization; sales, product management, marketing, customer support, development, delivery, IT, etc. Yeah, there’ll always be more to optimize in the dev house - but restructuring interactions to promote pull and flow throughout the organization will provide opportunities for huge pay offs. None of that’s going to happen without a fundamental understanding of lean.