Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Toyota Using Waterfall?

Toyota Using Waterfall?

This item in japanese


Lean software development has been inspired by lean manufacturing and specifically the work that Toyota pioneered in the field.  It is then very surprising to find out that the software development arm of Toyota has been traditionally working with waterfall and is in it's infancy in lean software development.  Henrik Kniberg reported on this on his blog describing a lean study tour he undertook last year.  Henrik and the members of his group had the opportunity to visit Toyota and their head of software development:

We had the great honour of meeting Satoshi Ishii, manager of the embedded software division – i.e. the software that goes into the cars. His English was rather halting and I didn’t take detailed notes, so some of the quotes and conversations below are paraphrased.

First surprise was when he opened up by saying “I think you know more about Lean software development than we do”, and after that it just got more and more interesting.

Henrik's visit to Toyota was full of suprises.  When he asked about if they had considered Agile software development techniques:

We asked Ishii-san if he had considered Agile software development. He was aware of Agile and liked the ideas, and said they will probably move in that direction. But they will do it in the Toyota Way – patiently and methodically, as Agile is not a goal in itself. I couldn’t agree stronger.

He said that “we are trying to learn how to apply TPS (= what we call Lean in the west) to software development”. Imagine the look on our faces. We came there to learn from what we thought would be the holy grail of lean software development, most of us were expecting to be dazzled and impressed.

Many of the things the Toyota team has discovered matches much in the Agile world, and some of them are contrary:

One of the big impediments is their current software architecture. He didn’t get into details, but mentioned that they need to make significant changes in their architecture to enable Lean and Agile software development. My belief is that it is the other way around – that Lean and Agile software development provides a way to implement the architectural change in an iterative & incremental way.

He emphasized the importance of testing & fixing defects early. A defect found in the production phase is about 50 times more expensive than if it is found during prototyping. If the defect is found after production it will be about 1,000 – 10,000 times more expensive! I’ve seen other studies showing similar numbers. He showed some data on this, visualized in the bar chart below:

Israel Gatt, also wrote about three things we can learn from Toyota's current predicament:

Whatever Agile method you practice - Scrum, Lean, Kanban, Crystal, etc. – you need to be cognizant of three touch points with the Toyota experience reported above:

  • Just like the Toyota Production System, your software method is a “vehicle” which is subject to policy decisions from above. It cannot, however, compensate for policy failures.
  • If your company relentlessly pursues growth, the quality/technical debt liability it is likely to incur coud easily outweigh the benefits of growth. Consider the upside potential of growth vis-a-vis the downside of the resultant technical debt. When appropriate, monetize technical debt using the technique described in Technical Debt on Your Balance Sheet.
  • In addition to monetizing the technical debt, evaluate the various kinds of risks indicated in The View From The Executive Suite. A sense of how devastating those might be is given by Toyota’s own experience.

With the current problems that Toyota is having with it's software , we have to wonder if they had been building their software differently, would they be where they are today?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Duplicate Quote

    by craig w,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Looks like a copy/paste error, the quote that starts with "We asked Ishii-san if he had considered..." shows up twice.

  • Re: Duplicate Quote

    by Slobojan Ryan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Craig,

    Thanks for the heads-up, this has been fixed.

  • We haven´t advanced much since 1968

    by Javier Diaz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Technically (sw´s mathematical base) we have advanced a lot. There are mature fields now: relational databases, compilers, standard Operating System design (all areas where we have standard open source alternatives). At least these are taught in School. Semi-mature: type theory: typing as declarative sw definition, web applications, API and framework design, declarative programming, modular design ...

    Educationally and experimentally (sw practice), we are still not there: half of Agile et al is common practice as done by small start ups and in all places were the sw builders are the owners of the product. Universities still teach lots of untested nonsense, but at least all that Toyota has realized is known to any student without any experience in the field ... Big companies are in the dark ages while small and specialized sw shops are ready to go to the Moon ... Agile has done more to enhance practice than all academia in the last 30 years.

    From a psychological-sociological POV (sw as a sustainable profession) we still think our little piece of the field is special and the law of gravity does not apply ... It will take a couple of generations to retire and a couple thousand sw disasters to make sw come of age into adulthood.

    Organizationally we are in still into slavery (sw management): from a management POV sw is pyramid building or patching castles to avoid huge disasters ... MBA-like culture fears and misunderstands sw completely (build-control everything, externalize everything, outsource talent, retain data, force development against secret specs-data-parties, : they have done all those, sometimes simultaneously) . Managing a farm is no t the same as managing a magazine ...

    In some environments, for sw to bloom, management has to die (so it won´t happen there). Some organizations deserve the sw they get ...

  • No, they're not

    by Dan Tines,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    They're using agile, lean, scrum, BDD, and Kanban

  • While this is sad...

    by Mark Levison,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    ...why is anyone surprised? We've studied Toyota for their manufacturing and product development ideas. Not their software engineering. In addition anytime we go into a larger company that is successfully using Agile/Lean to drive their software development, we find other areas that are holding the business back. Toyota is no different. So why are we surprised when it happens at Toyota?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p