Mary Poppendieck, Henrik Kniberg and a bunch of other people are on a Lean Tour in Japan that might turn out to be historical. According to this blog post, a Toyota software development manager has spoken openly for the first time on how they develop software, and guess what? Yep, it’s waterfall. We’re waiting for more details on the Lean Development list regarding how they manage to pull this off and what they think of the Agile community, but I think we’re going to learn a lot here.
Update 2/May: this is what Mary says about what Toyota is doing and thinking
The person we heard from at Toyota – Ishii-san – deals with embedded software in production automobiles. I understand that for a prototype part, software can take a matter of days. In production parts, the cycle was 3 months. When you are dealing with embedded software in production hardware, a 3 month waterfall is really fast. And note that at Toyota, people really do talk about “bad news first”, so what we heard about is what they consider a problem, as opposed to what is going well.
To answer your question about agile, Ishii-san said they are studying agile, but their architecture is not particularly supportive of it. His real motivation, as I heard his comments, is that improvement is necessary because of the late detection of defects. I imagine that they will focus on early removal of defects, and adopt whatever processes prove (after PDCA cycles) to be more proficient at doing this.
Toyota people will not just do agile because someone says it is good. They will look at their objectives and adopt whatever process gives them more of what they consider good. And Toyota is VERY good at doing this – I would not want to be competing against them!
Tags: agile, Agile Alliance, Lean, toyota, waterfall
-
I commented on this thread that started with JetBrains’ blog article on the whole “Toyota does Waterfall” diatribe.
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
-
I worked for Toyota in 2006/2007 on a Very Large Software Project and they worked purely waterfall. In theory they have a process called TUP, based on RUP, but they actually don’t follow that.
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…
-
I am wandering if the fact that Toyota’s IT does not follow the TPS principles (Lean and Agile in this case) possibly proves that Toyota, as many other enterprises, either does not consider IT as a vital part or its top management considers IT as a magical box and does not touch it.
-
Thanks to Alan Dayley for directing me to this posting. I can understand why TPS is not the model for software development at Toyota. It has taken folks like Mary to help adapt the decidedly linear process model that is TPS in manufacturing to the software development paradigm.
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.
-
I finally found the time to describe in more detail what we learned about Toyota’s software development process during our visit. Here’s the article “Toyota’s journey from Waterfall to Lean software development”:
http://blog.crisp.se/henrikkniberg/2010/03/16/1268757660000.html -
Given the recent quality issues at Toyota it is interesting to see Geert’s comments above, from the inside of a development.
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.
You must be logged in to post a comment.
6 comments
Comments feed for this article
Trackback link: http://www.xqa.com.ar/visualmanagement/2009/04/confirmed-toyota-does-waterfall/trackback/