The underlying themes the book points out for successfully getting an organisation to adopt a lean approach is that we must have a change agent, lean knowledge and a lever for change. Interestingly that lever for change can often be a recession when a firm needs to make changes in order to survive - when times are good there is no need to change so it’s easier to just keep the status quo.

My favourite quote from the book is the following which talks about the mindset needed for lean thinking:

One idea which really resonated with me as someone working in the industry was how Pratt & Whitney had to get past the managerial attitude of "ship on time and you’ll be fine [even if you’re shipping junk]" in order to make improvements. Often with software projects I have found that there appears to be a real focus on the data of promised delivery even though it would be beneficial to ship a bit later and ensure greater quality. Often there is no actual loss (except loss of face) from doing this either.

Co-locating teams is a constant thread throughout the book and I’ve found this to be an important factor in successfully delivering software as well. The author also talks about the need to look at the cost across the whole life cycle of the product rather than just the cheaper production cost of offshoring operations. Around the time I read this chapter I was drinking some Ribena which said on the label that the blackcurrants were picked in New Zealand, the drink bottled in China and I was drinking it in Australia. There were quite a lot of transportation costs involved in the life cycle of that drink! In software it is the cost of communication rather than transportation that we need to consider when deciding to spread a team across different locations.

The idea of takt time stood out for me - the idea here is to only produce at the rate at which the product is being demanded. This means that sales people shouldn’t go trying to create spikes in demand which I think is quite different to the way that typical organisations operate. Software wise I suppose this would be about delivering at the pace at which the customer needs the functionality and trying to release regularly so there aren’t spikes in the requirements.

In the Wiremold case study the idea of reducing the suppliers so that there are less integration points in the whole process is described. In software having less moving parts certainly makes it easier for us to go faster.

An interesting thing that is pointed out is that in all the firms case studied there are never any layoffs directly linked to lean improvements. This despite the fact that a lot less people will be needed once the process has been improved. It is pointed out that if people lose their jobs from lean then they’re going to do their best to sabotage it. The importance of everyone being involved in the continuous improvement is also emphasised. There are endless steps of improvement, we are never done.

The importance of having a standard language when talking about lean is emphasised, helping ensure that everyone is talking about the same things. I think the idea is fairly similar to that of the ubiquitous language from Domain Driven Design.

One of the wishes of the author is to create lean enterprises where lean thinking is applied all along the value stream from the raw materials all the way to the customer. The difficulty of getting all the firms to work together to allow this to happen is described but I can’t really see how this is going to happen for the time being.