Learning = Extending the Threshold of Knowledge

“My computer won’t boot.”

Mrs. TheLeanThinker’s computer was hanging on the logo screen, keyboard unresponsive.

I know already that if the CPU were bad it wouldn’t get this far.

I also knew that the system hasn’t even tried to boot the OS from the hard drive yet, so that likely isn’t the problem.

Working hypothesis: It’s something on the motherboard.

Start with the simple stuff that challenges the working hypothesis:

  • Hang test a different, known good, power supply. No change.
  • Pull memory cards and reinstall them one by one. No change.
  • Pull the motherboard battery, unplug, wait a few minutes to possibly reset the BIOS. No change.
  • Try holding down the DEL key on power-up to get into BIOS settings. Nope, system still hangs, though it does read that one keystroke, the keyboard is dead after that.
  • Try Ctrl-Home to reach the BIOS flash process. Nope.

image

There is no evidence that the motherboard is not dead. Final test:

Get the numbers off the motherboard, find the same model on Amazon, order it for $37.50 to the door. (Intel hasn’t made this processor type since 2011).

New motherboard arrived today. Switch it out, takes about 30 minutes.

Boot up the machine, works OK, set the time in the BIOS, and pretty much good to go.

Convince Windows 10 that I haven’t made a bootleg copy.

Done.

The Threshold of Knowledge

I learned to code in 1973 on PDP-8 driving teletypes. Although my programming skills are largely obsolete these days, I am comfortable poking around inside the box of a PC, and I generally know how they work. Thus, the troubleshooting and component replacement I described above was not a learning experience. Yes, I learned what was wrong with this computer. (The “bad motherboard” was a hypothesis I tested by installing a new one.) But I didn’t learn anything about computers in general.

Rather than working through experiments into new territory, I was troubleshooting. Something that had worked was not working now. My experiments were an effort to confirm the point of failure.

Therefore, as interesting as the diversion was, aside from a little research on some of the more arcane troubleshooting, it was not a learning exercise for me. It was all within my Threshold of Knowledge.

In the Improvement Kata, “threshold of knowledge” refers to the boundary between “We know for sure” and “We don’t know.” Strictly speaking, we only say “We know” when there is specific and relevant evidence to back it up.

image

In this case, my challenge (fix the wife’s computer) was well inside the red circle.

But this wouldn’t be the case for everyone.

The Threshold of Knowledge is Subjective

Someone else with the same challenge may not see this as a routine troubleshoot-and-repair task. Rather, he has to learn.

I had to learn it at some point as well. The difference is that I had already learned it. I had already made mistakes, taken a week to build a PC and get it working many years ago. I learned by experimenting and being surprised when something didn’t work, then digging in and understanding why. On occasion, especially in the early days, I consulted experts who coached me, or at least taught me what to do and why.

Coaching To Extend the Threshold of Knowledge

Learning is the whole point of the Improvement Kata. That is why we call the “improver” the “learner.” If someone encounters a problem like my example and I am responsible for developing their skills, I am not serving them if I do something like:

  • Sit down at their machine and troubleshoot it.
  • Tell them what step to take, and asking what happened so I can interpret the outcome.

That second case is deceptive. The question is “Who is doing the thinking?” If the coach is doing the thinking, then the coach isn’t coaching, and the learner isn’t learning.

In this case I would also have to recognize this is going to take longer than it would if I did it myself. That is a trap many leaders fall into. They got where they are because they can arrive at a solution quickly. But the only reason they can do that is because, at some point in the past, they had time to learn.

“My computer doesn’t boot.” If my objective is for this person to learn, then I need to go back to the steps of learning. Given that the challenge is likely “My computer operates normally,” what would be my next question to help this person learn how to troubleshoot a problem like this?

I need to know what they know. “Do you know where in the boot sequence it is hanging up?” If the answer is “No,” or just a repeat of the symptom, then my next target condition is for them to understand the high-level sequence of steps that happens between “ON” and the login screen. That would be easy to depict in a block diagram. It’s just another process. But my learner might have to do a little research, and I can certainly point him in the right direction.

I’m not going to get into the details here, because this post isn’t about troubleshooting cranky computers.

General Application

“If somebody comes to me with a problem, I have two problems.”

  • The original issue.
  • The fact that this person didn’t know how to handle it.

You can easily translate my computer example into a production quality example. A defect is produced by a process that normally does not produce them. What is different between “Defect” and “Defect-Free?” Something is. We just don’t know what.

Is it something we need to learn? Something we need to teach? Or something we need to communicate?

If my working challenge for my organization is something like “Everyone knows everything they need to do their jobs perfectly.” then I am confronted every day with evidence that this is not as true as I would like.

If I look at those interventions as “the boss just doing his job” then I lose the opportunity to teach and to grow the organization. I am showing how much I know, and by doing so just extending the dependency. That might feel good in the short term, but it doesn’t do much for the future.

Think about this… in your organization, if the boss were promoted or hired out of the job tomorrow, would you look outside the immediate organization for a replacement? If so, you are not developing your people. When I see senior leaders being hired from outside, all I can do is wonder why they have so little faith in the people they already have.

_________

*I remember when Gateway built their own machines, which I guess shows how long I’ve been playing with PCs. Then again, I remember when the premium brand was Northgate. Of course, I also remember programming on punch cards.

Coaching Kata: Walking Through an Improvement Board

Improver's Storyboard

The Coaching Kata is much more than just asking the 5 questions. The coach needs to pay attention to the answers and make sure the thinking flows.

Although I have alluded to pieces in prior posts, today I want to go over how I try to connect the dots during a coaching cycle.

Does the learner understand the challenge she is striving for?

The “5 Questions” of the Coaching Kata do not explicitly ask about the challenge the learner is striving for. This makes sense because the challenge generally doesn’t change over the course of a week or two.

But I often see challenges that are vague, defined only by a general direction like “reduce.” The question I ask at that point is “How will you know when you have achieved the challenge?

If there isn’t a measurable outcome (and sometimes there isn’t), I am probing to see if the learner really understands what he must achieve to meet the challenge.

This usually comes up when I am 2nd coaching and the learner and regular coach haven’t really reached a meeting of the minds on what the challenge is.

Is the target condition a logical step in the direction of the challenge?

And is the target condition based on a thorough grasp of the current condition?

I’m going to start with this secondary question since I run into this issue more often, especially in organizations with novice coaches. (And, by definition, that is most of the organizations where I spend time.)

It is quite common for the learner to first try to establish a target condition, and then grasp the current condition. Not surprisingly, they struggle with that approach. It sometimes helps to have the four steps of the Improvement Kata up near the board, and even go as far as to have a “You are here” arrow.

Four steps of the Improvement Kata
(c) Mike Rother

Another question I ask myself is Can I directly compare the target condition and the current condition? Can I see the gap, can I see the same indicators and measurements used for each so I can compare “apples vs apples”?

Along with this is the same question I ask for the challenge, only more so for the target condition:

How will the learner be able to tell when the target is met? Since this has a short-term deadline, I am really looking for a crisp, black-and-white line here. The target condition is either met or not met on the date.

Is there a short-term date that is in the future?

It is pretty common for a novice learner to set a target condition equal to the challenge. If they are over-reaching, I’ll impose a date, usually no more than two weeks out. “Where will you be in two weeks?” Another way to ask is “What will the current condition be in two weeks?”

Sometimes the learner has slid up to the date and past it. Watch for this! If the date comes up without hitting the target, then it is time to reflect and establish a new target condition in the future.

Is the target condition a step in the direction of the challenge?

Usually the link between the target condition and the overall challenge is pretty obvious. Sometimes, though, it isn’t clear to the coach, even if it is clear in the mind of the learner. In these cases, it is important for the coach to ask.

Key Point: The coach isn’t rigidly locked into the script of the 5 questions. The purpose of follow-up questions is to (1) actually get an answer to the Coaching Kata questions and (2) make sure the coach understands how the learner is thinking. Remember coach: It is the learner’s thinking that you are working to improve, so you have to understand it!

(And occasionally the learner will try to establish a target condition that really isn’t related to the challenge.)

Does the “obstacle being addressed” actually relate to the target condition?

(Always keep your marshmallow on top!)

The question is “What obstacles do you think are preventing you from reaching the target condition?” That question should be answered with a reading of all of the obstacles. (Again, the coach is trying to understand what the learner is thinking.) Then “Which one (obstacle) are you addressing now?”

Generally I give a pretty broad (though not infinitely broad) pass to the obstacles on the list. They are, after all, the learner’s opinion (“…do you think are…”). But when it comes to the “obstacle being addressed now” I apply a little more scrutiny.

I have addressed this with a tip in a previous post: TOYOTA KATA: IS THAT REALLY AN OBSTACLE?

It is perfectly legitimate, especially early on, for an obstacle to be something we need to learn more about. The boundary between “Grasp the current condition” and “Establish the next target condition” can be blurry. As the focus is narrowed, the learner may well have to go back and dig into some more detail about the current condition. If that is impeding getting to the target, then just write it down, and be clear what information is needed. Then establish a step that will get that information.

Sometimes the learner will write down every obstacle they perceive to reaching the challenge. The whole point of establishing a Target Condition is to narrow the scope of what needs to be worked on down to something easier to deal with. When I focus them on only the obstacles that relate directly to their Target Condition, many are understandably reluctant to simply cross other (legitimate, just not “right now”) issues off the list.

In this case it can be helpful to establish a second Obstacle Parking Lot off to the side that has these longer-term obstacles and problems on it. That does a couple of things. It can remind the coach (who is often the boss) that, yes, we know those are issues, but we aren’t working on those right now. Other team members who contribute their thinking can also know they were heard, and those issues will be addressed when they are actually impeding progress.

Does the “Next step or experiment” lead to learning about the obstacle being addressed?

Sometimes it helps to have the learner first list what they need to learn, and then fill in what they are going to do. See this previous post for the details: IMPROVEMENT KATA: NEXT STEP AND EXPECTED RESULT.

In any case, I am looking to see an “Expected result” that at least implies learning.

In “When can we go and see what we have learned from taking that step?” I am also looking for a fast turn-around. It is common for the next step to be bigger than it needs to be. “What can you do today that will help you learn?” can sometimes help clarify that the learner doesn’t always need to try a full-up fix. It may be more productive to test the idea in a limited way just to make sure it will work the way she thinks it will. That is faster than a big project that ends up not working.

The Root (Cause) Of All Problems

One of my clients has been working with Steve Spear. They shared a great point he made with me, and I want to share it with you:

“The root cause of all problems is ignorance.”

— Steven Spear

I can’t argue with that. If you don’t understand the root cause, you need to learn more about the problem. And to be clear, “problem solving” and “improvement” are learning processes. If you didn’t learn, you didn’t solve the problem, and you didn’t improve anything. At best you suppressed the symptoms.

So… next time you encounter a problem (which is likely as soon as you put your head up from reading this), instead of asking “What should we do?” ask “What do we need to learn about this?” It will set people off in an entirely different (and far more robust) direction.

Averages, Percentages and Math

As a general rule I strongly discourage the use of averages and “percent improvement” (or reduction) type metrics for process improvement.

The Problem with Averages

Averages can be very useful when used as part of a rigorous statistical analysis. Most people don’t do that. They simply dump all of their data into a simple arithmetic mean, and determine a score of sorts for how well the process is doing.

The Average Trap

There is a target value. Let’s say it is 15. Units could be anything you want. In this example, if we exceed 15, we’re good. Under 15, not good.

“Our goal is 15, and our average performance is 20.”

Awesome, right?

Take a look at those two run charts below*. They both have an average of 20.

On the first one, 100% of the data points meet or exceed the goal of 15.

Run chart with average of 20, all points higher than 15.

On the one below, 11 points miss the goal

image

But the both have an average 5 points over the goal.

In this case, the “average” really gives you almost no information. I would have them measure hits and misses, not averages. The data here is contrived, but the example I am citing is something I have seen multiple times.

Why? Most people learned how to calculate an arithmetic mean in junior high school. It’s easy. It’s easier to put down a single number than to build a run chart and look at every data point. And once that single number is calculated, the data are often thrown away.

Be suspicious when you hear “averages” used as a performance measurement.

Using Averages Correctly

(If you understand elementary statistical testing you can skip this part… except I’ve experts who should have known better fall into the trap I am about to describe, so maybe you shouldn’t skip it after all.)

In spite of what I said above, there are occasions when using an average as a goal or as part of a target condition makes sense.

A process running over time produces a range of values that fall into a distribution of some kind.

Any sample you take is just that – a sample. Take a big enough sample, and you can become reasonably confident that the average of your sample represents (meaning is close to) the average of everything.

The move variation there is, the bigger sample you need to gain the same level of certainty (which is really expressed as the probability you are wrong).

The more certain you want to be, the bigger sample you need.

Let’s say you’ve done that. So now you have an average (usually a mean) value.

Since you are (presumably) trying to improve the performance, you are trying to shift that mean – to change the average to a higher or lower value.

BUT remember there is variation. If you take a second sample of data from an unchanged process and calculate that sample’s average, YOU WILL GET A DIFFERENT AVERAGE. It might be higher than the first sample, it might be lower, but the likelihood that it will exactly the same is very, very small.

The averages will be different even if you haven’t changed anything.

You can’t just look at the two numbers and say “It’s better.” If you try, the NEXT sample you take might look worse. Or it might not. Or it might look better, and you will congratulate yourself.

If you start turning knobs in response, you are chasing your tail and making things worse because you are introducing even more variables and increasing the variation. Deming called this “Tampering” and people do it all of the time.

Before you can say “This is better” you have to calculate, based on the amount of variation in the data, how much better the average needs to be before you can say, with some certainty, that this new sample is from a process that is different than the first one.

The more variation there is, the more difference you need to see. The more certainty you want, the more difference you need to see. This is called “statistical significance” and is why you will see reports that seem to show something is better, but seem to be dismissed as a “statistically insignificant difference” between, for example, the trial medication and the placebo.

Unless you are applying statistical tests to the samples, don’t say “the average is better, so the process is better.” The only exception would be if the difference is overwhelmingly obvious. Even then, do the math just to be sure.

I have personally seen a Six Sigma Black Belt(!!) fall into this trap – saying that a process had “improved” based on a shift in the mean of a short sample without applying any kind of statistical test.

As I said, averages have a valuable purpose – when used as part of a robust statistical analysis. But usually that analysis isn’t there, so unless it is, I always want to see the underlying numbers.

Sometimes I hear “We only have the averages.” Sorry, you can’t calculate an average without the individual data points, so maybe we should go dig them out of the spreadsheet or database. They might tell us something.

The Problem with Percentages

Once again, percentages are valuable analysis tools, so long as the underlying information isn’t lost in the process. But there are a couple of scenarios where I always ask people not to use them.

Don’t Make Me Do Math

“We predict this will give us a 23% increase in output.”

That doesn’t tell me a thing about your goal. It’s like saying “Our goal is better output.”

Here is my question:

“How will you know if you have achieved it?”

For me to answer that question for myself, I have to do math. I have to take your current performance, multiply x 1.23 to calculate what your goal is.

If that number is your goal, then just use the number. Don’t make me do math to figure out what your target is.

Same thing for “We expect 4 more units per hour.”

“How many units do you expect per hour?” “How many are you producing now?” (compared to what?)

Indicators of a W.A.G.

How often do you hear something like  “x happens 90 percent of the time”?

I am always suspicious of round numbers because they typically have no analysis behind them. When I hear “75%” or “90%” I am pretty sure it’s just speculation with no data.

These things sound very authoritative and it is easy for the uncertainty to get lost in re-statement. What was a rough estimate ends up being presented as a fact-based prediction.

At Boeing someone once defined numbers like this as “atmospheric extractions.”

If the numbers are important, get real measurements. If they aren’t important, don’t use them.

Bottom Line Advice:

Avoid averages unless they are part of a larger statistical testing process.

Don’t set goals as “percent improvement.” Do the math yourself and calculate the actual value you are shooting for. Compare your actual results against that value and define the gap.

When there is a lot of variation in the number of opportunities for success (or not) during a day, a week, think about something that conveys “x of X opportunities” in addition to a percent. When you have that much variation in your volume, fluctuations in percent of success from one day to the next likely don’t mean very much anyway.

Look at the populations – what was different about the ones that worked vs. the ones that didn’t — rather than just aggregating everything into a percentage.

Be suspicious of round numbers that sound authoritative.

_______________

*These charts are simply independent random numbers with upper and lower bounds on the range. Real data is likely to have something other than a flat distribution, but these make the point.

Toyota Kata: Is That Really an Obstacle?

“What obstacles do you think are preventing you from reaching the target condition?”

When the coach asks that question, she is curious about what the learner / improver believes are the unresolved issues, sources of variation, problems, etc. that are preventing the process from operating routinely the way it should (as defined by the target condition).

I often see things like “training” or worse, a statement that simply says we aren’t operating the way the target says.

Here is a test I have started applying.

Complete this sentence:

“We can’t (describe the target process) because ________.”

Following the word “because,” read the obstacle verbatim. Read exactly what it says on the obstacle parking lot. Word for word.

If that does not make a grammatically coherent statement that makes sense, then the obstacle probably needs to be more specific.

 

 

Prediction Doesn’t Equal Understanding

Lunar Eclipse over Everett, WA. Photo by Mark Rosenthal, © 2015Sometimes people fall into a trap of believing they understand a process if they can successfully predict it’s outcome. We see this in meetings. A problem or performance gap will be discussed, and an action item will be assigned to implement a solution.
Tonight those of us in the western USA saw the moon rise in partial eclipse.

We knew this would happen because our understanding of orbital mechanics allows us to predict these events… right?

Well, sort of. Except we have been predicting astronomical events like this for thousands of years, long before Newton, or even Copernicus.

The photo below is of a sophisticated computer that predicted lunar eclipses, solar eclipses, and other astronomical events in 1600BC (and earlier). Click through the photo for an explanation of how Stonehenge works:

Photo of Stonehenge
Creative Commons flickr user garethwiscombe

Stonehenge represented a powerful descriptive theory. That is, a sufficient level of understanding to describe the phenomena the builders were observing. But they didn’t know why those phenomena occurred.

Let’s go to our understanding of processes.

The ability to predict the level of quality fallout does not indicate understanding of why it occurs. All it tells you is that you have made enough observations that you can conclude the process is stable, and will likely keep operating that way unless something materially changes. That is all statistical process control tells you.

Likewise, the ability to predict how long something takes does not indicate understanding of why. Obviously I could continue on this theme.

A lot of management processes, though, are quite content with the ability to predict. We create workforce plans based on past experience, without ever challenging the baseline. We create financial models and develop “required” levels of inventory based on past experience. And all of these models are useful for their intended purpose: Creating estimates of the future based on the past.

But they are inadequate for improvement or problem solving.

Let’s say your car has traditionally gotten 26 miles-per-gallon of fuel. That’s not bad. (For my non-US readers, that’s about 9 liters / 100 km.) You can use that information to predict how far a tank of fuel will get you, even if you have no idea how the car works.

If your tank holds 15 gallons of fuel, you’ll be looking to fill after driving about 300 miles.

But what if you need to get 30 miles-per-gallon?

Or what if all of a sudden you are only getting 20 miles-per-gallon?

If you are measuring, you will know the gap you need to close. In one case you will need to improve the operation of the vehicle in some way. In the other case, you will need to determine what has changed and restore the operation to the prior conditions.

In both of those cases, if you don’t know how the car operated to deliver 26 miles-per-gallon, it is going to be pretty tough. (It is a lot harder to figure out how something is supposed to work if it is broken before you start troubleshooting it.)

Here’s an even more frustrating scenario: On the last tank of fuel, you measured 30 miles per gallon, but have no idea why things improved! This kind of thing actually happens all of the time. We have a record month or quarter, it is clearly beyond random fluctuation, but we don’t know what happened.

The Message for Management:

If you are managing to KPIs only, and can’t explain the process mechanics behind the measurements you are getting, you are operating in the same neolithic process used by the builders of Stonehenge. No matter how thoroughly they understood what would happen, they did not understand why.

If your shipments are late, if your design process takes too long, if your quality or customer service is marginal, if the product doesn’t meet customer’s expectations, and you can’t explain the mechanisms that are causing these things (or the mechanisms of a process that operates reliably and acceptably) then you aren’t managing, you are simply directing people to make the eclipse happen on a different day.

“Seek first to understand.”

Dig in, go see for yourself. Let yourself be surprised by just how hard it is to get stuff done.

 

 

How Do We Deal With Multiple Shifts?

This is a pretty common question.

Today I was talking to a department director in a major regional hospital that is learning Toyota Kata. She picked it up very quickly, and wants to take the learning to the off-shifts.

She (rightly) doesn’t want the night shift to just be deploying what day shift develops, she wants night shift totally involved in making improvements as well. Awesome.

Her question was along the lines of “How do I maintain continuity of the effort across both shifts?” She was jumping into asking how to provide good coaching support, whether there were separate boards, or a single board etc. and playing out the problems with each scenario.

My reply was pretty simple. “I don’t know.”

“What do you want to see your learners doing if they are working the way you envision?”

In other words, “What is your target condition?”

But… how do we coach them, and so on?

I don’t know. But until we understand what we want the improvement process to look like, especially across the shift boundaries, we can’t say. Different target conditions will have different obstacles.

And what worked at Boeing, or Genie, or Kodak, or even another hospital I’ve worked with likely won’t work here in your hospital. The conditions are different. The conditions are different in different departments in the same hospital!

She admitted that she was having a hard time thinking about a target without dealing with all of the potential obstacles first. My suggestion was that this challenge is her improvement board, and the best way to work out a solution was to actually follow the Improvement Kata (that she has been doing such a great job at coaching for the last month).

Trust the process. Once there is a clear target condition for the people doing the work (in this case, the learners / improvers), then we’ll better understand the obstacles we actually have to deal with. That will likely be fewer than every possible problem we can think of right now.

Establish your target condition, then list your obstacles, then start working on them one by one.

The Improvement Kata is exactly the tool to apply when you know you want to do something, but can’t figure out exactly how to do it.

Step by step.

Keep it up, Susan.  Smile

Output vs. Takt Time

The team’s challenge is to reach steady output of 180 units per hour.

Their starting condition was about 150 per hour. Their equipment and process is theoretically capable of making the 180 per hour with no problem.

They calculated their takt time (20 seconds) and established a planned cycle time of 17 seconds.

Some time later, they are stuck. Their output has improved to the high 160s, but those last 10-12 units per hour are proving elusive.

This is the point when I saw their coaching cycle.

Looking at their history, they had set a series of target conditions based on output per hour. Their experiments and countermeasures had been focused on reducing stoppages, usually on the order of several minutes.

“Does anybody have a calculator?”

“Divide 3600 seconds by 180, what do you get?”

“20 seconds.”

“Do you agree that if your line could reliably produce one module every 20 seconds that you would have no trouble reaching 180 modules per hour?”

Yes, they agreed.

“So what is stopping you from doing that?”

They showed me the average cycle times for each piece step in the process, and most were at or under 15 seconds. But averages only tell a small part of the story. They don’t show the cumulative effect of short stoppages and delays that can cascade through the entire line.

The team had done a lot of very good work eliminating the longer delays. But now their target condition had to shift to stability around their planned cycle time.

Performance vs Process Metrics

This little exercise shows the difference between a process metric and the performance metric.

Units-per-hour is a performance metric. It is measured after the fact, and tells the cumulative effect of everything going on in the process. In this case, they were able to make a lot of progress just looking at major stoppages..

Stability around the planned cycle time or takt time (you may use different words, that’s OK) is a process metric.

It shows you what is happening right now. THIS unit was just held up for 7 seconds. The next three were OK, then a 10 second delay. It’s those small issues that add up to missing the targeted output.

The team’s next target condition is now to stabilize around their planned cycle time.

Since they averaged their measurements, their next step is to (1) take the base data they used to calculate the averages and pull the individual points back out into a run chart and (2) to get out their stopwatches and go down and actually observe and time what is really going on.

I expect that information to help them clarify their target condition, pick off a source of intermittent delay, and start closing the remaining gap.

A Tale of Two Sites

With apologies to Charles Dickens, but the opening line is just too good to resist…

The Best of Times

In this plant, the advance team is chaired and actively led by the most senior manager on the site. He is actively coaching, he is actively being coached. He is questioning his own learning, seeking council, and acting on it.

They are clear that, while there may be general guidelines, they must learn by trying and experimenting. They cannot simply deploy a roadmap because they can only see the next mile on a 1000 mile journey.

They see it as a method to shift their culture away from its “tell me what to do” legacy and toward one of an empowered workforce that takes initiative and works on the right things, the right way.

There is no doubt among the leadership team that this is the path forward.

They are starting to apply the language of the Improvement Kata informally in their meetings and discussions.

Overall, it seems a bit messy. But learning is like that.

The Other Site

The “implementation of Toyota Kata” is a directive from the corporate Continuous Improvement team.

The corporate team spends much of their energy developing and deploying templates, PowerPoint presentations, setting standards for the forms and the layout, lettering and colors on the improvement boards, and setting milestones.

They have published a step-by-step procedure for a site to implement Toyota Kata, based on their assumptions of what ought to work. None of them has actually led a change like this.

They are, in turn, working through the site continuous improvement team who is expected to execute to these standards.

The site leader receives weekly reports on progress. Training the managers and “implementing Toyota Kata” is the responsibility of one of the site’s continuous improvement staffers. The site leader questions him using the 5 Questions each week, and issues direction in response to the answers.

It is the continuous improvement practitioner who is responsible for motivating the members of the management team to challenge their own processes and develop their improvement boards. A significant number of them are questioning the need or purpose of this exercise.

Thoughts

Unfortunately I run into the second case far more often than I see the first. But the story is decades old. That is how we did Six Sigma, kaizen events, Theory of Constraints, Total Quality Management. In each case we have separated the deployment of a core change in the way we manage operations from the responsibility for actually managing.

It

doesn’t

work.

This TED talk by Tim Harford actually sums up the difference pretty well:

But beyond what works, and what doesn’t, we also have to ask “Which approach is respectful of people?”

What are the underlying assumptions about the people at the gemba when “standards” are established thousands of miles away, published, and then audited into place?

Why do they feel they must tell people exactly what to do?

What do they feel is lacking on the site?  Competence? or Clarity?

Scientific Improvement Beyond The Experiment

“How do we deploy this improvement to other areas in the company?” is a very common question out there. A fair number of formal improvement structures include a final step of “standardize” and imply the improvement is laterally copied or deployed into other, similar, situations.

Yet this seems to fly in the face of the idea that the work groups are in the best position to improve their own processes.

I believe this becomes much less of a paradox if we understand a core concept of improvement: We are using the scientific method.

How I Think Science Works

In science, there is no central authority deciding which ideas are good and worth including into some kind of standard documentation. Rather, we have the concept of peer review and scientific consensus.

Someone makes what she believes is a discovery. She publishes not only the discovery itself, but also the theoretical base and the experimental method and evidence.

Other scientists attempt to replicate the results. Those attempts to replicate are often expanded or extended in order to understand more.

As pieces of the puzzle come together, others might have what seems to be an isolated piece of knowledge. But as other pieces come into place around them, perhaps they can see where their contributions and their expertise might fit in to add yet another piece or fill in a gap.

If the results cannot be replicated at all, the discovery is called into serious question.

Thus, science is a self-organized collaborative effort rather than a centrally managed process. All of this works because there is a free and open exchange among scientists.

It doesn’t work if everyone is working in isolation… even if they have the same information, because they cannot key in on the insights of others.

What we have is a continuous chatter of scientists who are “thinking out loud” others are hearing them, and ideas are kicked back and forth until there is a measure of stability.

This stability lasts until someone discovers something that doesn’t fit the model, and the cycle starts again.

How I Think Most Companies Try To Work

On the other hand, what a lot of people in the continuous improvement world seem to try to do is this:

Somebody has a good idea and “proves it out.”

That idea is published in the form of “Hey… this is better. Do it like this from now on.” image

We continue to see “standardization” as something that is static and audited into place. (That trick never works.)

What About yokoten. Doesn’t that mean “lateral deployment” or “standardize?”

According to my Japanese speaking friends (thanks Jon and Zane), well, yes, sort of.  When these Japanese jargon terms take on a meaning in our English-speaking vernacular, I like to go back to the source and really understand the intent.

In daily usage, yokoten has pretty much the same meaning [as it does in kaizen] just a bit more mundane scope…along the lines of sharing a lesson learned.

Yokogawa ni tenkai suru (literally: to transmit/develop/convey sideways) is the longer expression of which Yokoten is the abbreviation.

Yoko means “side; sideways; lateral. Ten is just the first half of “tenkai” to develop or transmit. Yokotenkai..

If you take a good look at the Toyota internal context, it is much more than just telling someone to follow the new standard. It is much more like science.

How the Scientific Approach Would Work

A work team has a great idea. They try it out experimentally. Now, rather than trying to enforce standardization, the organization publishes what has been learned: How the threshold of knowledge about the process, about a tricky quality problem, whatever, has been extended.

We used to know ‘x’, now we know x+y.

They also publish how that knowledge was gained. Here are the experiments we ran, the conditions, and what we learned at each step.

Another team can now take that baseline of knowledge and use it to (1) validate via experimentation if their conditions are similar. Rather than blindly applying a procedure, they are repeating the experiment to validate the original data and increase their own understanding.

And (2) to apply that knowledge as a higher platform from which to extend their own.

But Sometimes there is just a good idea.

I am not advocating running experiments to validate that “the wheel” is a workable concept. We know that.

Likewise, if an improvement is something like a clever mistake proofing device or jig (or something along those lines), of course you make more of them and distribute them.

On the other hand, there might be a process that the new mistake-proofing fixture won’t work for. But… if they applied the method used to create it, they might come up with something that works for them, or something that works better.

“That works but…” is a launching point to eliminate the next obstacle, and pass the information around again.

oh… and this is how rocket science is done.

Edit to add:

I believe Brian’s comment, and my response, are a valid extension of this post, so be sure to read the comments to get “the rest of the story.” (and add your own!)