Jidoka
Jidoka is one of the basic elements of the Toyota production System. Jidoka stands for “automation with a human touch” or “autonomation”. The term dates back to the Type-G Toyoda Automatic Loom which automatically stopped when it detected a problem such as thread breakage. That meant that an operator didn’t have to keep watching the machine, but could quickly intervene when one of many looms detected and signalled a problem.
The same principle can be applied to the production line. Whenever a machine or, more likely, an employee detects a problem, they “stop the line” and signal the problem using an “Andon” board. Everybody can see that there’s a problem. The team leader can quickly come and help diagnose the problem and solve it.
The sooner the problem is detected, the easier it is to fix and the smaller the impact. Thus, one of the important parts of Lean training is to be able to detect problems, raise them quickly, analyse and fix.
Jidoka and software development
Can we apply this production line principle to software development? Of course.
How can we detect problems and defects? One good way is to have a comprehensive suite of unit tests and continuous integration. Whenever we check in, our build server tells us quickly what we’ve broken. The build server serves as our Andon. Patrick Debois has several examples of Andons in his Visu-Wall collection.
Another way is to have a suite of automated functional tests, performance tests, code analysers and other tools that are run by the continuous integration server.
Good testers who are really involved from the start of the project and track the deliverables closely are a great way to implement Jidoka. The really great testers can tell us clearly what goes wrong and how to repeat the problem.
As long as you get fast, high quality feedback that’s something’s wrong, you’re implementing Jidoka.
Jidoka is an attitude
Is that all there is? Of course not. It’s not enough to detect problems, you have to do something about it.
The build broke? I didn’t check anything in, so it’s not my fault.
What do you mean by “It doesn’t work”? It works on my machine!
Who said so? Oh, Bob… He’s so negative, he’ll find fault with everything.
Have you ever heard remarks like that? It’s not enough to detect problems, you have to do something about it. The only correct answer to someone who reports a problem is “Thank you!”. And then your team corrects the problem.
When the problem has been corrected you’ve done half of your job. The other half is asking why your existing Jidoka mechanisms failed to detect that problem in time:
- Why didn’t any of our developer tests catch the problem in time? How can we improve the tests in that area? Is that a situation that could happen in other parts of our code? Will we detect it there?
- Why didn’t any of our customer tests catch the problem in time? How can we improve our specifications in that area? Are there other blind spots? How can we improve those specifications?
- Why wasn’t this case tested? Did we misunderstand what was needed? Didn’t we do what was agreed? Do we risk more of such misunderstandings?
The biggest bottleneck in IT is learning. By reflecting on our problems, we learn to detect issues earlier.
Jidoka requires Transparency, Trust and Collaboration
If Jidoka was just a matter of installing tools and procedures, it would be easy to implement. But it’s surprisingly difficult to implement, because Jidoka requires:
- To make every problem visible. My pride might be wounded by admitting I made a mistake.
- To reward people who admit mistakes. Doesn’t that conflict with the Lean idea of “Right First Time”? Shouldn’t we reward only perfect people?
- To take the time to improve our problem-detecting systems. But there are so many issues to fix and I have so little time!
- To thank people who make problems visible. Yes, even that curmudgeon who always finds fault with everything. Yes, even that tester who delights in finding “bugs” in my beloved creations.
- To collaborate as a team to resolve problems quickly and completely. Whoever “caused” or found the problem, our common goal is to create high quality, high value work.
Being really Lean or Agile is hard. Really implementing those Agile Values is hard.
Have you made a problem visible lately?
Have you thanked a tester lately?
Have you improved your Jidoka tools lately?
If not, are you only doing half of your job?
A lean evening
