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 – “mistake-proofing”

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 – “automation”

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.

1. Detect the abnormality: normally a Scrum Team will rely on the XP technical practices of CI and automated testing to identify code level problems.  Additionally, the Scrum framework offers three places to detect abnormalities.   The Daily Scrum to identify impediments to flow, the Sprint Review of the potentially shippable product helps everyone stay focused on the regular delivery of customer value and the role of ScrumMaster is to make visible any impediment or abnormality in the development process.
2. Stop: everyone in Scrum is responsible for quality.  If you notice that something is wrong, ask another member of the Team, the ScrumMaster and\or the Product Owner for their opinion.  Often times in Scrum we make decisions based on limited or incomplete information and through the process of developing the product we learn something new that invalidates our assumptions – this is a good thing!  When this occurs we need to share this information with other Team members, if the new information impacts some technical aspect of the product.  Or we need to share it with the Product Owner, if it will have an impact on the requirements or the Team’s ability to deliver.  Finally, it is essential to keep the ScrumMaster informed of these conversations since it is their job to identify and anticipate recurring patterns of behavior within the Team.
3. Fix (or correct) the immediate condition: once we understand and agree the situation is abnormal, we make the correction to fix (or mitigate the impact of) the error.  We do not allow it to persist, otherwise someone else will have to deal with it later and it will introduce an unnecessary delay.  Team members should use the Daily Scrum to identify any abnormalities they encountered and how they fixed the situation so other Team members are aware the development process is having issues, to be on the lookout for potential abnormalities and perhaps implement a fix in their own work.
4. Investigate the root cause to install a countermeasure: use the Retrospective meeting to begin the conversation around the origin of the abnormality, identify the root cause of the issue and define an action item that will remove the impediment.  If the issue requires a deeper investigation, the ScrumMaster and Team members may start an A3 investigation to probe the problem, gather data and come up with an effective countermeasure.