My belief is that most of the TPS tools we are all familiar with (Kaizan, Kanban etc) simply do not relate to the new product development (NPD) process, they relate to the production process, which in their industry is very separate to the earlier NPD process.

I have always felt it makes more sense to compare the software development process with “new product development” rather than production. In which case rather than adapt TPS to software development we might do better to look at Set Based Concurrent Engineering (SBCE).

“The Toyota Product Development System” by Morgan and Liker describes their approach to NPD, which is very based around (SBCE).

Unfortunately I think Nick’s comments about software dev being a problem to most senior managers (whether they are in Toyota or not) might well apply.

Sounds as if they do not even use their “normal” NPD approach.

Since in software development one is rarely producing the same component twice (with reuse exceptions) this differs greatly from manufacturing where each component is intended to be like the previous. Pride of product quality by each individual spawns continuous improvement on the method and delivery upon demand removes waste; these are hallmarks of the method.

PDCA is foundational to TPS and to agile. TPS is extremely focused on metrics for “in process” control of quality. It is extremely difficult to find these in process metrics in software development. For instance if a automotive part is being created an operator can immediately measure in process to determine if the product is out of spec. The same is difficult in software as the creation is largely a thought exercise and the “spec” in not so well measured. So in agile we compensate for this by focusing on the process of development rather that the in process development of the product (with the exception some XP and PSP practices). We expose those products to early integration to then test the product quality, but defects can only be detected very early not predicted or prevented.

It will be very interesting to watch how companies like Toyota, with there relentless focus on effective production and quality, react to recent events that challenge the presumption of quality. Additionally as automobiles (and other Toyota products) become much more software based, it will be interesting to see how TPS is rolled into a software development methodology.

Indeed they use PDCA cycles, but only in a reactive way when management tries to find a way out of trouble.

I’m quite convinced a scrum type of management would haved saved them heaps of mony on that particular project…

It’s not really “Waterfall” as we know it, of course, as Mary says in your blog post quote.

Check out my review of this discussion and associated comments here: http://softwaredevelopmenttoday.blogspot.com/2009/04/does-toyota-really-use-waterfall-for.html#comments