Lean Terms

Agile, or at least Scrum is based on the manufacturing practices of Japanese car companies from the 1980’s. At the time, Japanese car companies were building cars with better quality, faster and cheaper than their American counterparts. The most successful of these Japanese companies was Toyota with their Toyota Production System. From this, evolved the Lean process.

Myself and my team are about to go visit the Toyota plant in Altona Victoria later this month. So I thought it would be a good idea to get myself reaquainted with Lean terms that I read in “The Toyota Way” by Jeffrey Liker.

I’m going to try to relate these terms to the CAMS (Culture, Automation, Measurement/Monitoring, Sharing) principles developed by John Willis and Damon Edwards that was developed during their DevOps Cafe podcast and give my explanation of what I think the terms mean in terms of software development.


Poka Yoke : Mistake Proofing (culture, automation) – In my thoughts, this is trying to prevent Defects in the software development process. One possible method of mistake proofing is through Test Driven Development where you build your tests before you start your development. It can also mean automation. There are a number of tasks that we that are manual, repetitive, and or simply done so infrequently that it’s hard to remember all the steps. By removing the component that can cause mistakes in tasks of this nature (The human) you can prevent mistakes from happening.

Hansei : Self Reflection (culture) – This I think is the retrospective in Scrum, but in a more personal level. It is simply to think over what you have done whether it’s in the past hour or the past sprint and try to think of a better way to improve.

Andon : Sign or signal to highlight action required (measurement, monitoring) – This is simply a signal to tell when a developer is in trouble or when the system is in trouble. In software development, it can take the form of an alert, an email, even a red light.

Jidoka : automation (automation – obviously) – To put simply, all types of automation. Automation of the build process, automation of the development process. Automation of tasks you do every day. For example a daily health check email. Anything that you can automate that will improve the system.

Just in Time (culture) : This is simply to have resources, requirements come just as they are required. Contrary to popular thinking about Agile that you do not need planning, to get Just in Time to work, you need to plan. If for example, to make a change to the firewall to get some ports opened up, and there is a 2 day lead time, you need to make that request 2 days before you need the ports opened up. Not when you need the ports, nor significantly in advance as requirements may change.

Henjunka : production smoothing or leveling (culture) – This is leveling the workload. How many of you have been on a project where at the beginning there is a lot of slack time. Nothing to do. Then at the end there is a mad rush to get the project completed in time. By doing the work in small chunks (sprints) you should have a constant flow of work.

Kaizen : Continuous improvement (culture) – This is where you try to continuously improve the system. Try something, try it at a scale that will not cause significant impact, see if it improves the situation. If it does, decide whether to adopt the changed process or not. If there is no improvement, determine whether or not to modify the trial procedure or drop the change completely. Don’t be afraid of failure, as each failure should be treated as a learning experience. Kaizen is one of the methods where PDCA (Plan Do check Act) learning cycle is used to try improvements.

Genchi Genbutsu : go and see for yourself (culture) – I see it a lot, I’ve done it myself a lot of times. I would come up with a theory on how something works. Or why it’s not working. The best way to determine how something works is to actually run it. Try it.Be it an API, a new technology etc. With the advent of Open Source and trial software, it’s easy to try products out yourself and see if they work for you.

Nemawashi : laying the groundwork or foundation for consensus (culture) – This I think is when the Team decides. It can be in the form of team meetings where you discuss the use of a new process, plan the work to be done. Just get everyone together and discuss.

kanban : signboard (culture) – This is where the Kanban board got its name from. With the Kanban board, you have a card which represents a piece of work. As it flows through the board, you see it’s progress. This gives a good visual queue to anyone who may be passing by as to the progress of any single piece of work.

gemba : the place where the actual work is done (culture) – This is a little tricky in Software development. In manufacturing, it’s simply the factory floor. In software development, it’s done at people’s desks. On the computer and in their heads.  For managers though, if you want to know what is happening with your people, go out and talk to them. Don’t just rely on reports, the wall, burn down charts etc.

zero quality control (culture, automation, measurement, monitoring) – This I think is part of the “Shift Left” movement where quality is being pushed towards the developer. The idea being that you build in quality as part of the process. Not as a process you do at the end of the development cycle as is done with traditional testing. Zero Quality Control is an asymptotic goal. A goal that is to be strived for but may never be reached. By continuously improving and trying to remove the cause of defects (not the actual defects themselves) you work towards the goal of never having any defects.

kaikaku : radical improvement (culture) – This is where significant change happens. It can mean moving from Waterfall to Agile, Agile to DevOps. Changing company direction. Anything that has a significant, radical change to they way work is done. This is opposed to Kaizen which is incremental change.


This is only a quick overview and my own explanations of what I think these terms mean to me. I may at some point in the future go through these in more depth.  I really need to re-read the Toyota Way. This time around, take notes as it sticks in my head better.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.