Mark Needham

The Book

Taiichi Ohno's Workplace Management by Taiichi Ohno

The Review

Having completed The Toyota Way a few weeks ago I was speaking with Jason about what books were good to read next – he recommended this one and The Toyota Way Fieldbook.

I struggled to see a connection to software development with a lot of what I read, but there were certainly words of wisdom that we can apply to continuously improve our ability to deliver projects.

What did I learn

• Just in Time doesn't mean exactly when the raw material is needed – it means just before it's needed. This concept can certainly be applied in an agile software development process to ensure that story cards don't spend too long in any column before moving to the next one. The reasoning in our case being that the knowledge behind the analysis/development of them is at its greatest just when the card has completed that stage.
• If you make defects you have not worked – this is related to the idea of building quality into the process. You are not adding value if the work that you produce has defects in it. This is quite an interesting contrast to the more typical 'hours worked' approach whereby the productivity in these hours is not considered to be that important.
• The job of team leaders is to make life on the gemba (i.e. shop floor) better. This has some similarities with the Tech Lead role on software projects where the person playing that role will spend a lot of their time reflecting on the development process and looking for ways to make it work better. This can be through driving pair rotation on a team, running analytics on the code to find areas of weakness, helping t setup test frameworks etc. Reflection on these types of things is the only way to drive improvement.
• Stop defects moving through the system – this is achieved in agile by having story kickoffs and walkthroughs, the former to ensure that everyone is clear what is expected of a story and the latter to ensure that those criteria have been met. Catching defects early makes them much easier to fix since the story is still freshly in the head of the developers that worked on it.
• Stop the line for defects – the idea here is to prevent defects from moving through the system, similar to the above point. In this case I'd have thought it's more similar to not wanting code to be checked in on a red build so that the problems can be fixed before the line continues so to speak. It does seem a bit over the top to stop people checking in just because the build is red though, a better strategy perhaps being a team discipline to not check in when this is the case.
• Don't automate for the sake of it – look for manual improvements in the process before deciding to automate something. I think this is quite interesting as automating processes in software development is not as costly as it would be on a production floor. One area where maybe there is more debate is automated acceptance testing using UI driven tests. These can often take ages to run as part of the build when there may in fact be better (also probably automated) ways of testing the same functionality. In this case perhaps recognising that there are options when it comes to automating is the key take away.
• There were several mentions of standardising the approach which is probably more applicable to manufacturing than software development, although there are certainly areas, such as debugging, where a standardised approach would probably be more effective.

In Summary

This book is fairly short but it acts as a nice contrast to The Toyota Way and presents similar information in a slightly different way.

The Book

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 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 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:
  

  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 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 'Lean Software Development'