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?