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?

My doubts about lean come from my perception of an overly tool based focus when it comes to applying lean. As 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 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:

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 expert, or 10 years to really get The Toyota Way and use it in a sustainable way.