SPA 2006 – Jidoka
Run by Kevin Rutherford this session was based on the question, is it appropriate to transfer the concept of jidoka from the assembly line to software development?
Question like this come up fairly regularly in discussions about lean software development. Lean manufacturing is a set of principles pioneered by Toyota; this includes the minimising of waste, pull rather than push manufacturing and time boxing of when to make decisions. While lean has worked extremely well in manufacturing there is always someone willing to point out the differences between manufacturing and product development.
The jidoka principle is to stop the production line as soon as a fault is detected. This minimises the compounding of the error (i.e. building a car with a faulty part). Having stopped the line the fault must be resolved and finally the root cause resolved. So, can we apply this principle to software?
- Detect a fault
- Stop (any continuation is based upon false premise)
- Fix fault
- Fix root cause (process improvement).
In presenting this concept Kevin lead us through a history of the application of this technique in weaving. Following this we experimented with feedback in a game of Chinese whispers.
The discussion that followed highlighted the need for pragmatism when transferring the technique into software development. In particular we must acknowledge that multiple threads of development exist. We must assess which threads need to stop when a fault is detected. Also to apply this technique we must have a continuous integration environment along with regular check-ins. Finally we must be realistic about our sphere of influence and not waste time tackling root causes that are out of our control. Perhaps a root cause list should be kept for use in the retrospective?
