Kaizen

12:50: History of Kaizen

“This is mostly taken from Wikipedia.”

It started within the Training Within Industry program during the 1940s. The initial premise related to American manufacturing during the war years, and was focused on small, incremental changes over time, rather than large changes that might have constituted a risk. As part of the Marshall Plan after WWII, American forces worked on rebuilding Japanese industry. The Civil Communications Section (CCS) developed a management training program that taught statistical control methods. This was taught by Homer Sarasohn and Charles Protzman during 1949-1950

“You may have a resource today that you may not have next week.”

It was after this point that W. Edwards Deming came into the picture. You might have heard of Deming at some point, as he was a major champion of statistical process control and one of the key people in Japan’s post-war growth into an industrial superpower. He is considered to have had more influence on Japanese industry than any non-Japanese person. He didn’t get a lot of recognition in the US until the early 90s, when he died, but his principles have seeped into American manufacturing as well. The Deming prize in Japan is named after him and he was awarded the Order of the Sacred Treasure, which is an honor granted by the emperor of Japan.

“We’re better than we used to be but people expect software to crash constantly.”

This dedication to continual improvement in manufacturing changed Japanese industry from one that had a reputation of making cheap, low-quality crap, to one that could take on American manufacturing, and often win (at least, until we started taking the ideas more seriously).

18:02 What’s the point of it?

“If you’re in a business environment, you probably can’t take a year off development to improve your environment.”

The point is to be able to surface incremental improvements in your processes, without excessive downtime that can create risk. In Toyota’s production system, personnel are expected to stop production lines if they notice an abnormality. When this happens they and their management will suggest improvements, which are then quickly implemented in the process.

“It’s one of those things where I’d like to just stop it and rewrite the whole thing.”

The cycle of Kaizen is Plan, Do, Check, Act. This is also known as the Shewhart Cycle or PDCA (or PDSA). Some variants of the methodology (notably Toyota’s) add an addition “O” step at the beginning that refers to observing the current situation before planning the next step.

“Obviously time is the most expensive asset that programmers have.”

There are numerous things in a business environment that this improves. It helps reduce waste, both in terms of time and materials. It reduces manufacturing defects, which improves product reliability in the field. It empowers employees to improve the manufacturing process, which improves morale and puts everyone in a position of looking for improvements instead of just a select few.

23:42 The steps of kaizen.

Observe

During this phase, you’ll determine what’s going on with the existing system, including taking actual measurements. It’s important to note that this is a “measurement” step, not a “feelings” or “guessing” step. You need real concrete data here to prove that your improvement actually helped things.

Plan

This is where you come up with your objectives and the process to achieve them. This also includes defining what success actually is. This requires actual measurable goals. It’s not about the feels.

Do

This is where you actually do the work to fix the situation, including the collection of data for use in the following steps. It is extremely important that you measure during this phase, in order to compare to your earlier baseline.

Check/Study

In this phase, you compare the new results you obtained to the previous ones you collected during the observation phase. You may want to chart the data you’ve collected over several PDCA cycles, especially if you are evaluating success based on multiple criteria.

Act

If the new process is better than the old one, this is where you make it official and it becomes the new baseline. If the new process isn’t better, then you don’t implement it.

32:35 How to use this yourself in a development lifecycle.

“It’s hard to argue with numbers because there’s so many of them.”

If you are in an agile environment, a lot of this is already in place with the typical agile lifecycle. Odds are also good that your agile process is missing some critical things for this to work. You have to measure your current state. “The app is slow” is not a measurement, but an opinion. You have to have a good definition of success and you have to a means of measuring it. You have to actually collect and use your measurements. You have to actually implement the improvements you discover.

If you are doing waterfall, this will be more difficult as your process doesn’t really support iterative change (or the iterations are too long to be useful).

To a large degree, kaizen can be considered a refinement of what you are probably already doing with agile, mostly by focusing on letting data drive your decisions. This will largely require plugging in things like analytics packages, running automated code tests and the like to be able to get useful data in a timely manner. For instance, if you are trying to improve performance, you’ll need to actually measure things like memory usage, time at each stage of a process, etc. You’ll have to have a baseline of performance and you’ll have to do this on your “improved” version of the code. You’ll need to compare the performance between the two versions, which means you’ll need the data in the same format.