Japanese Terms For DevOps Practitioners

Gemba

The Japanese meaning is “the real place”. In business it  typically means “where value is created” and in lean manufacturing it means “the factory or shop floor”.  In Lean Six Sigma (LSS) it is common to hear the phrase “Going to Gemba” (meaning the real place where the work is being done).  This is also sometimes referred to as process mapping.

The reason this is an important word in terms of DevOps is that DevOps inherits a lot of ideas from LSS and the “Theory of Constraints” (TOC) and both LSS and TOC are heavily focused on global optimization (seeing the big picture).  Improving the whole and and not just focusing on the parts is a core tenant of both LSS and TOC.  Understanding bottlenecks and flow is an important part of understanding the “Value Stream”.

In DevOps we talk about the “Aha to the Ka-Ching” or the left to right flow.  “Going to Gemba” is very important to actually see the flow first hand and not just by word of mouth.  We need to walk the Gemba in order to determine how it can be improved by a) eliminating waste (Muda) and b) minimizing irregularities, inconsistencies or variation (Mura).

Kanban

In Japanese Kanban means “signboard” or “tavern keeper’s final call for orders before taking the sign down.”  Kind of a “last call.” Taiichi Ohno, the father of Toyota Production System (TPS), which later became Lean Manufacturing, used Kanban as a means to achieve “Just in Time” (JIT) production systems.  Kanban cards were used to signal when to replenish and order new material as a way to control inventory and flow.

In 2007 David J Anderson helped define what is now known today as the Kanban Method, focusing more on software delivery patterns rather than the original TPS manufacturing models.  Today Kanban is a valuable tool used by many agile teams.  Kanban is also an instrumental tool in many DevOps focused organizations.  Some of the key ideas behind Kanban are the ideas of a) Kanban as a pull system, b) visualizaing workflow to help improve throughput and c) putting Work in Process (WIP) limits on specific types of work.

The reason Kanban has found a lot of it’s popularity in DevOps focused shops is because Kanban works very well in operations or service oriented groups e.g., highly interrupt driven.  While Scrum and XP work well in development organizations.  In many organizations where DevOps is a philosophy, and Dev and Ops tend to work closely together, you will find a lot of examples of Kanban use.

Kaizen 

Wikipedia describes Kaizen as an “improvement,” or “change for the better” which refers to a philosophy or practices that focus on continuous improvement of processes in manufacturing, engineering, game development, and business management.

Kaizen is a daily process, each day is better then the last.  Kaizen is also rooted in the idea that it is much more than just simple productivity improvement. When done right it’s about humanizing the workplace and eliminating overly hard work (muri).  Kaizen also teaches people how to apply the scientific method and learn how to spot and eliminate waste.

Kaizen play a huge role in DevOps in that, like Lean, there is always a sense of improvement in the flow.  Finding variation (bugs, performance issues) late in the flow and engineering them earlier in the process.  Also, Kaizen is also about continuously optimizing for the whole by alleviating bottlenecks.

Kata

Literally means “the form and order of doing things.”  The term is mostly popularized in the martial arts; however, outside of martial arts it refers to cultural conditioning.   Kata, in Japanese business, is the idea of doing things the “correct” way.  The art of bowing, exchanging name cards,  the importance of apology, and the origin of the Japanese obsession for quality are all deeply rooted in their culture.

An organization culture can be characterized as it’s Kata through it’s consistent role modeling, teaching, and coaching.  Mike Rother also popularized the notion of Kata and Lean in his book “Toyota Kata.”   Toyota Kata is broken into two areas: Improvement Kata and Coaching Kata.  Improvement Kata teaches the mastery of continuous improvement, adaptiveness, and innovation. Coaching Kata stresses the aspect of periodic observation and guidance.  The theory is that if we are doing something that is difficult and we are not used to it we will default to the familiar without a coach.  In DevOps we think of Kata as the culture whereas Kaizen is the continuous improvement.  When an organization has optimized its Kaizen we can say that is their Kata.

Muda

Muda is waste.  According to Taichi Ohno of Toyota (father of Toyota Production Systems or what is called Lean) any activity that does not add value is considered waste.  Taichi Ohno identified the famous Seven forms of waste (Transportation, Inventory, Motion, Waiting, Over-processing, Over-production and  Defects).  The idea is to classify all activities into two categories: activities that add value and ones that don’t.

Eliminating waste in DevOps is a key principle.  When we talk about the Aha to the Ka-ching we are always looking for wasteful boundary handoffs as well as things that impede our cycle time for customer delivery (i.e., the Ka-ching).

Mura

Mura means inconsistency or excess variation. When work is not standardized it can add waste in the form of  wasted movement (e.g., not having clear process and procedures defined).  Mura can lead to quality issues.

One of the core principles of Kanban as described by  David Anderson is making process policies explicit.  Kanban is an excellent tool for reducing Mura.  One could argue that configuration management tools like Chef, Puppet and CFEngine control Mura by making processes for installing and configuring systems standardized.  In may ways Lean is about eliminating waste (muda) and Six Sigma is about reducing variation (Mura).  In DevOps we strive to reduce all of the 3 M’s (Muda, Mura, Muri).

Muri

Muri is the third form of waste as as described by the Toyota Production System (TPS) along with (Muda and Mura).  In Japanese the term literally means overburden, unreasonableness, or absurdity.  Muri represents the activities where processes, people, or machines are pushed beyond a reasonable limit.

An organization with Muri is more likely to have increased stress levels and reduced job satisfaction.  Organizations that are continually operating at capacity tend and have less flexibility and longer lead times.   Many DevOps organizations try to combat Muri by building slack into their environment. Things like hack days, innovation days, and just percentage free time (e.g., Google 20% time) all help to reduce Muri.

In Eliyahu Goldratt’s book titled “The Goal” the Theory of Constraints (TOC) was introduced as way to control flow.  One of the core tenants of TOC is the idea of Drum-Buffer-Rope (DBR) where the buffer is the slack time between the rhythm (i.e., the drum) and the line-delivery (i.e., the rope).  DBR and DevOps both take into account  the fact that Murphy not only exists but that he is definitely out to get you.  In which case slack time is an excellent tool to defend against Muri.

Poka-yoke

Means fail-safing or mistake proofing. Poke-yoke is used in manufacturing to eliminate defects and help draw attention to human errors.  The term was adopted by Shigeo Shingo as part of Toyota Production Systems (TPS).

A great example of a real world poka-yoke is when your ice maker in your freezer shuts off when the bucket is full thus making sure your freezer doesn’t fill up with ice.  Poka-yoke has obvious implications in DevOps.  Most people would agree that a majority of the DevOps related opportunities are based on human activities.  Software and operational engineering are human endeavors and poka-yoke’ing an infrastructure is one the DevOps goals.  Test Driven Development (TDD) is an example of “software poka-yoke.”  Operational self service offerings or a PaaS is another form of Poka-yoke.  Monitoring is a great example of Poka-yoke in that it looks for errors in a system before they occur.

- About The Authors

John Willis

John Willis has worked in the IT management industry for more than 35 years and is a prolific author, including "Deming's Journey to Profound Knowledge" and "The DevOps Handbook." He is researching DevOps, DevSecOps, IT risk, modern governance, and audit compliance. Previously he was an Evangelist at Docker Inc., VP of Solutions for Socketplane (sold to Docker) and Enstratius (sold to Dell), and VP of Training & Services at Opscode where he formalized the training, evangelism, and professional services functions at the firm. Willis also founded Gulf Breeze Software, an award winning IBM business partner, which specializes in deploying Tivoli technology for the enterprise. Willis has authored six IBM Redbooks for IBM on enterprise systems management and was the founder and chief architect at Chain Bridge Systems.

Follow John on Social Media

• 
•