

Class Registration
To build a quality product we need to let go of the outdated 20th century idea that quality can be achieved through inspection alone, i.e. testing. Instead, let us focus on constructing a framework that produces quality outcomes from the beginning and the two Lean concepts highlighted in this article will help you achieve this goal. In the last article in our series on Lean Thinking, I shared with you the concepts of gemba (“real place”) and genchi genbutsu (“go and see”) as a way to stay grounded on where to find value and encourage everyone to take time to see for themselves how the product is being used. This article will discuss how we can build processes that will deliver the minimum amount of errors from the beginning.
Poka-yoke means mistake-proofing. A poka-yoke is any mechanism in a Lean process that helps the participants avoid mistakes. Its purpose is to eliminate product defects by preventing, correcting or drawing attention to human errors as they occur. Poka-yoke can be implemented at any step of a process where something can go wrong or where an error can be made. Either the participant is alerted when a mistake is about to be made, or the poka-yoke device actually prevents the mistake from being made.
Many of the common mistake-proofing techniques for Team members come from Extreme Programming (XP). Continuous integration (CI) is the classic examples of poka-yoke for software development. However, CI only works when everyone on the Scrum Team is checking in their code multiple times a day and knows how to back out their changes when they cause the build to fail. Automated unit and functional testing is another example of poka-yoke since the automated tests exist to alert programmers that they have introduced errors while the design is still fresh in the their minds. Finally, pair programming is another excellent mistake-proofing process for coding and design errors since two sets of eyes review all new code. While not perfect, pairing eliminates many design, testing and requirement errors from entering the code in the first place. Frankly, I find it astounding that in 2014 that CI, automated testing and pairing is still not the standard practice for all software teams.
ScrumMasters and Product Owners should work with the Team to poka-yoke all the procedures and processes. Once a defect, error or abnormality creeps into the development process, ScrumMasters and Product Owners should provide leadership and support in mistake-proofing the process from future errors.
Jidoka is a Japanese term describing a quality control process that can be best summarized as “automation with a human touch”. It is a type of automation which implements supervisory activities rather than producing more product. When an abnormal situation arises in the Toyota Production System, the machine will stop and workers will stop the production line to resolve the issue immediately (sometimes this is called “Stop the Line”). To me, jodoka is about how do we work smarter so that we focus our attention on understanding the problem to ensure that it never recurs.
Here are four general principles to jidoka within the context of Scrum.