The Toyota Way: Book Review
Date: 2008-11-19 06:53:08

== The Book

http://www.amazon.co.uk/Toyota-Way-Management-Principles-Manufacturer/dp/0071392319/ref=sr_1_1?ie=UTF8&s=books&qid=1227011994&sr=8-1[The Toyota Way] by Jeffrey Liker

== The Review

I was initially very skeptical about the value of lean in software development but became intrigued as to its potential value after listening to http://jchyip.blogspot.com/[Jason] championing it. Since The Toyota Way is the book where many of the ideas originated from I thought it only made sense for this to be my first port of call to learn about lean.

== What did I want to learn?

* What are the similarities and differences between the Lean and Agile principles?
* How do we apply ideas around quality in software development?
* How important are leaders to making it all happen?
* If lean is not about tools what is it about?
* Is waste ever acceptable in our process?

== What did I learn?

* My doubts about lean come from my perception of an *overly tool based focus when it comes to applying lean*. As http://dannorth.net/2008/06/learning-to-lean[Dan points out] those just learning a technique require tools and practices to apply but I don't believe this can work in the long run. I was therefore very pleased that early on the author recognised this problem and points out that to achieve proper results from applying Toyota's approach we need more than tools and that *lean needs to 'permeate an organisation's culture'*.
* The concept of *learning by doing* was one that came across as being very important and it was emphasised constantly throughout the book. This can certainly be applied in software development, and it is actually often quicker just to try out things and see what happens rather than spending huge amounts of times reading up on the best approach. This is actually something I have learnt several times over the last few weeks and reminded me of something Scott Young posted http://www.scotthyoung.com/blog/2008/10/30/is-reading-making-you-stupid/[questioning the value of reading] when we're not actually doing the things we're reading about.
* It was interesting to note the *similarities between mass production thinking and waterfall* compared to the Toyota/lean/agile approach to solving the same problem. My favourite quote referring to this was:
+
____
What is the ideal way to organize your equipment and processes? In traditional mass production thinking\...,the answer seems obvious: group similar machines and similarly skilled people together.
____
+
This is a completely different approach to the cross functional teams that we assemble for agile projects and which are used in Toyota.

* I liked the idea of poka yoke - devices used to make it impossible for an operator to make a mistake. The emphasis is on *fixing the process rather than blaming the person*. I think this is quite a useful idea to take into the world of software development although I think in the agile world at least there is more emphasis on working together rather than blaming each other for mistakes.
* Throughout the book there was an emphasis on working out *how we can add value to the customer* - the idea being that the next stage or process is our customer. Often when we think of the customer it's only the customer right at the end of the process so this was an interesting difference. In general the book emphasises Toyota's process focus over the final outcome. I like this idea because there is a lot more to be learnt when it comes to reflecting on our process instead of just the result from my experience.
* Although most of the book and indeed most of the previous material I have come across about lean and Toyota talks about removing waste and non value added processes, the underlying idea of *continuous improvement* was what I found the most intriguing. Ideas such as stopping the line if there's a problem in order to improve that part of the process and expecting for the line to be stopped otherwise there will never be any improvement are concepts that would be quite unusual to many western businesses I would imagine. I think the 'stopping the line' idea can be applied in software development to raise problems when they arise as well. This way we can get everyone involved in trying to solve the problem rather than just letting one person struggle with it. I think this idea is partially applied with regards to the continuous integration build status but it would be unusual to see the whole team stop doing their work because it was red.
* Early on in the book the TPS House was mentioned - the idea being that everything must be strong from the use of the tools to the belief in the philosophy. It seemed to me from reading this that *applying Toyota's ideas successfully is an all or nothing* game - i.e. it would be very difficult to be successful in the long term by just picking and choosing certain ideas without having the other ones to support them.
* Again I came across the idea that it takes 10 years to become an http://www.sciam.com/article.cfm?id=the-expert-mind[expert], or 10 years to really get The Toyota Way and use it in a sustainable way.

== In Summary

The lean terminology (inventory, waste, etc) has become much more widely used on the last couple of projects I have worked on so it is good for me to have read this book as I now have a better understanding of what people are talking about. This served as a very good introductory book around this area.

I was worried that the book wouldn't be that applicable to me as a software developer but I was able to see the parallels between how what we do and what is done in manufacturing have similarities. The next book for my lean learning will be The Poppendieck's 'http://www.amazon.co.uk/Lean-Software-Development-Agile-Toolkit/dp/0321150783/ref=sr_1_1?ie=UTF8&s=books&qid=1227012935&sr=8-1[Lean Software Development]'