Follow-on thoughts (What I Missed!): Improvement Kata and DMAIC

Last week’s post about The Improvement Kata and DMAIC prompted some interesting discussions during the week, and I’d like to share some additional thoughts.

Before you read on, reflect a bit on what you think I totally missed. Does this post go where you expected it to? Does it confirm, or refute, your hypothesis about whether Mark was right or not?

What I Totally Missed!

I was too focused on the structures within the Improvement Kata and trying to draw lines between them and DMAIC.

Though we talk about the high-level structure of the Improvement Kata as steps, I think it may be more useful in this discussion to think of that structure as representing four phases* of any improvement or problem-solving effort.

Let’s take the term “Improvement Kata” out of the discussion because, right now, I am finding it distracting. Instead, let’s look at problem solving and improvement in general.

Phase 1:

Regardless of the specific approach we are using, we want to begin by clearly understanding what problem we are actually trying to solve, and what “solved” looks like.

This is the case whether I am looking to improve a process to new levels; whether I am trying to hit some kind of KPI goal; whether I am trying to understand the root cause of a problem; whether I am seeking to develop a new product; whether I am trying to influence someone’s decisions or behavior. Diving into proposing solutions without this understanding can easily turn into an exercise in frustration.

As soon as that desired outcome is understood, it’s a good idea to start tracking it against the goal so we can see what progress we are making.** I tend to default to a run chart for this.

Phase 2:

Once the problem is well defined, the next phase is gaining understanding of what is actually happening so that we can explain any gap between the current condition and the ultimate goal. Depending on the specific high-level problem, we may be trying to understand the relationship between the underlying process and its performance; the relationship between product design characteristics and product performance; the relationship between the user interface and errors; the relationship between the work culture and someone’s behavior; the relationship between the characteristics of whatever we are investigating and the phenomenon we are trying to influence.

We are working to understand the factors that drive the dependent variable of outcome.

Even as we gaining that underlying understanding, we have to be aware of hard-wired human nature to assign meaning to anything we are perceiving. It is really easy to fill in gaps and jump to conclusions. It is important to resist that temptation. Any conclusion being reached should trigger another question along the lines of, “What evidence do I actually have (or need)?” and prompt another level of inquiry.

Phase 3:

Even with my caveats above, the line between understanding what is happening and assigning meaning is more blurred than most practitioners would care to admit.

The formal process of making meaning is analysis. But as we go, it is very common that things we want to address will emerge. Sometimes the thing we need to address is another level understanding. My favorite quote from Steve Spear is, “The root cause of all problems is ignorance.” There is something we do not understand well enough.

At this (some?) point we can propose a hypothesis: If I change x, then I expect to improve (or learn more about) y.

Our analysis may find lower level, operational, metrics that are driving the outcome. For example, if the outcome is a level of productivity, we will probably find some combination of total cycle time and / or sources of delay that are driving output. Or quality yield. Whatever it is, we are starting to build a hypothesis of cause-and-effect between the outcome and the things that are driving it.

We set an intermediate goal based on that hypothesis, perhaps sketch out how the process needs to look, or changes in the product that would be required. Then we look with more focus and ask, “What is making it hard to actually do this?” and propose what problems we might have to solve to get there.

The key is that we (think we) know what we want to try changing, what impact we think that change will have, and what problems have to be solved to make that change actually happen (and, once we prove it works, sustain).

Phase 4:

Then we can pick off one of those problems and start to propose solutions – though it is also common to begin with a need to learn more about it. But those proposed solutions need to be tested. So we propose any action we intend to take as an experiment: We are going to _____, and we expect that ( something we will learn ). That learning may be more information, it may be simply learning that this idea works, doesn’t work, or works in a way we did not expect.

As thorough as we have been, we will likely discover that our information is incomplete. That doesn’t mean we have been sloppy. It means that as we narrow our focus or start making changes we are very likely to discover things that we didn’t see before. It is critically important that the goal of learning takes precedence over proving we are right.

That learning may take us into a different domain than the one we started in. For example, we might be working on something like process cycle time and run into something about the engineering design of the product itself that is an obstacle to improvement. The process is agnostic – it doesn’t respect organizational or functional boundaries. Nor does it respect organizational politics. It just tells you what is in the way of making the change you want to make.


“You don’t have to like your reality, but you have to deal with it.” – Brian Bakke


Back to the top.

Regardless of how the specific approach is structured, reality usually makes it iterative, often at multiple levels. Each change I make is going to have rippling effects on the overall process. Each change is going to bring out more understanding in the obstacles. Even after I have a solution I am pretty sure will work, trying to get it into place and stable offers up a new set of problems. You haven’t solved the problem until the solution is in place as the new routine.

So even if you reach that initial or intermediate goal, there is probably more work to do. Go back to the top, review your understanding of the problem, re-confirm your understanding of the current condition (you may have to dig in again if you have been narrowly focused), develop a cause-and-effect on the CURRENT condition (not just the one you started with), and start working toward that – always anchoring changes are you go.

My Revised Hypothesis

To summarize, although my last post was trying to map DMAIC into the Improvement Kata steps, what I now think I am proposing is that all approaches to problem solving and improvement that work follow a similar underlying pattern. The mechanics may be different, the jargon is certainly different, but at the end of the way we are all trying to take a scientific, fact driven approach to gaining deep understanding before just twiddling knobs and changing stuff.

The Other Thing I Totally Missed

It is really easy to fall into the trap of thinking that the Improvement Kata is just another structure for problem solving. That is, honestly, because when we look at the Improvement Kata as a stand-alone process, it is. That is the other mistake I made.

But the Improvement Kata is not intended to be stand-alone. It is one side of a larger structure.

The thing that Toyota Kata brings in is that coaching is an inherent, embedded, part of the process.

Intended Outcomes

Going back to the origin of Six Sigma, before there were different colors of “belts,” the role of the “Black Belt” was that of the professional problem solver. They would find (or be assigned) a major problem to solve, and go through the process defining it, measuring it, analyzing it, proposing and implementing solutions, and leaving the stakeholders with a “control plan.” Yes, that is an oversimplification, but that is also what I have seen in the wild at a number of companies with active Sigma programs.

So I think the focus here is on how an expert practitioner goes about “solving the problem.”

This legacy goes back a lot further than Six Sigma – with industrial processes we can go at least as far back as Frederick W. Taylor’s (and others) work over 100 years ago. The structure of TWI Job Methods (which was heavily influenced by Frank Gilbreth who was, in turn, an acolyte of Taylor though he had some philosophical differences) is that of a supervisor working largely on their own to streamline the work.

Regardless of whether it is DMAIC or something else (even traditional kaizen events), the classic approaches to improvement don’t have active, daily, coaching conversations built into their very structure. YES, it is absolutely possible to introduce them, but those structures are not there by design – except where they are.

In his early research on Toyota’s culture, Steve Spear talks about them “creating a community of scientists.” Their day-to-day process of improvement goes beyond just soliciting ideas from everyone. There are structures to the process design, and structures in the conversations about improvement, that facilitate becoming a better problem solver.

Toyota Kata is the result of Mike Rother’s research into the nature of those conversations, and then (most importantly!), how other companies might structure THEIR conversations to learn to do this. (Toyota does not follow Toyota Kata! Nor has anyone (who knew what they were talking about it) every claimed they did. Toyota’s intrinsic, unseen routines were parsed out and turned into visible routines that others can learn by practicing the basics.)

What is Toyota Kata For?

Maybe the real question is who is Toyota Kata for?

The way the Improvement Kata steps are usually described in books and training material (mine included, at least up to this point) are as things for the learner (the problem solver; the improver) to do. And, yes, they are… but

This is still (somewhat) controversial within the Toyota Kata community, but I am continuing to reinforce my belief that the structure and specifics of the Improvement Kata are more for the primary benefit of the coach, especially someone who is just developing those coaching skills.


“Why don’t you go do a kata on that?” is good a way to assure that this won’t work any better than to say, “Hey, go do an A3 on that.” Those assignments are neither delegating nor empowering. They are more akin to abdication of any responsibility to develop the skills of the person you are asking to solve the problem.


It is the coach who asks the improver to use those Starter Kata tools. Here is my working example – drawing from my skiing metaphor, but this is true of any coach who is working to improve someone’s technical skill.

A long, long, time ago I took up skiing again after a 15 year hiatus. I quickly remembered why I had stopped – it was a real struggle. This time I resolved to get better and signed up for a half-day lesson at Whistler, BC.

The first thing the instructor (coach) had us do was ski down the hill and cut some turns while she watched. She was evaluating each of us against her internal reference standard of a “perfect turn.” But rather than offering general critique she gave each of us a specific drill – one thing to practice – that would help us get to the next level. Not to perfection, but demonstrably better than we started.

My working hypothesis is that she had a repertoire of those drills in her mind, and based on where she found our “threshold of knowledge,” she pulled one of them and assigned it to us to practice. Mine was a drill that forced me to keep my upper body facing straight down the “fall line” as my hips pivoted underneath me. I can say that, after about an hour of practice, it worked. I became a much better skier that day.***

What about a someone who is just learning to be a ski instructor? I imagine that part of their learning is going to be a baseline of those drills. “If you see this, then assign that.” It is enough to get them started as they learn and develop their coaching skills.

I’m looking at the Starter Kata within the Improvement Kata (the detailed steps of Grasp the Current Condition, the structure of the storyboard, the obstacle parking lot, the experimenting record to name most of them) through the same lens.

Those are structures that a beginning coach can use effectively to help their learner through the framework of improving a process through the rigor of learning and experimenting with scientific structure.

The whole goal is to get someone who is reasonably competent at using those improvement tools up to speed as coach who is, in turn, working to develop someone else to use them effectively.

And there is the key divergence of Toyota Kata. It isn’t just about solving the problem. It is about getting problems solved in ways that develop peoples’ problem solving skills. This is how we create this problem-solving culture that is so elusive in most companies.

We can’t do that by just showing people good problem solving. We have to teach it deliberately in ways that allow people to practice, with correction, the process of problem solving.

But, as I said last week, the Improvement Kata is actually neither prescriptive nor proscriptive about any particular Starter Kata.

So, if you want to use the tools from Six Sigma and DMAIC instead, go for it. But make sure you are doing so with the goal of teaching them, vs. expecting immediate competence! Be ready to work side-by-side with your learner, or break the task into smaller bits. If they are left feeling incompetent or put on the spot they are less likely to return for more learning.

This is how you can move from the culture of the “Black Belt” expert practitioner toward a culture where everyone is applying the basic structure to everything. Sending people to “Green Belt” classes isn’t going to do that on its own. There has to be structured practice using the logical structure until it is habitual. It isn’t part of the culture until (nearly) everyone talks that way.

The Coaching Kata

The “5 Questions” of the Coaching Kata are designed to give a minimum viable framework as a launching point for someone who is learning to coach in order to develop people’s problem solving skills.

That’s the key: This isn’t about the boss knowing the technical solution. It is about learning the mindset behind teaching and coaching someone else through discovering the technical solution. This is the part that is adaptive – the coach is often the stakeholder, and they have to adjust their behavior, assumptions, and maybe even values about what is most important for this to work well.

If they “coach” by leading with, “Why don’t you just…?” or “Have you thought about…?” they are disguising direction as curiosity.

A skilled coach is going to be patiently persistent, questioning the learner through deeper and deeper understanding, often having them go back for more understanding in the process. The coach has to know the point at which the learner starts speculating, and ask about how we are going to verify or confirm that.

If the coach sees the understanding gap, they can pull from their repertoire of things for the learner can use to gain more knowledge. That might be “build a block diagram, but let’s go watch the process so we can see what is really happening.” It might be, “Great data points, can we put them on a run chart so we can better see the patterns?”

You can’t do this in a conference room – once the threshold of knowledge is reached, the only place to get more understanding is back where things are actually happening.

But the whole point here is that we are working to establish patterns of conversation within the organization. We are working to build problem solving capability so that more problems can be solved, closer to the point of origin. This is, I think, fundamentally different than a parachuting in a professional problems solver to do the heavy lifting.

As a Change Agent

IF you are working to shift the organization’s normal patterns toward collaborative problem solving (not everyone is), then I think a Change Agent is better served by understanding (Grasp the Current Condition!) the existing problem-solving structure, and then adapting any adjustments you are thinking about to minimize the change you are asking people to make. Make those adjustments as deliberate experiments. Prepare yourself to be surprised when people respond differently than you thought they would. You can make a lot of change over the long arc, but the right now change should be based on improving something that already exists.

Contrast that with the new “Lean Program” or “Now we are going to do DMAIC” that takes everyone through classes, uses alien words with pedantic definitions. The message buried in that approach is, “You aren’t competent, and I am, so let me show you what I know.” My name for that is “Creating resistance as you go.”

If I adapt whatever terms they use, and start asking intensely curious questions that nudge things away from rote application, and deeper into actually thinking about what they are seeing and learning, then I am leveraging what they already know and building on it.

Big difference.


*Yes, for Kata purists, we have the “Planning Phase” and “Execution” (or “Striving”) phase. I’m expanding the “Planning Phase” into three “phases” each corresponding to one IK step.

**There are a few use cases where the outcome is binary. The one that came to mind was an investigation into the cause of a single incident. There isn’t necessarily a continuous metric as they converge on root cause and countermeasures in that case. Still, the underlying logical structure of that investigation is going to follow the same general pattern I am outlining here.

***What I just realized as I was reviewing this for publication is that in the years past I had been taught the basics to get a beginner skier going, but had not been taught anything else. Thus, I had been trying to apply those beginner drills in more challenging situations – without that coaching that would have helped me progress through each limitation as I pushed my abilities. In skiing terms, wedge turns don’t work on intermediate / advanced slopes. At least not very well. I was stuck as a beginner trying to use beginner’s techniques in more advanced situations.

This is an important lesson for the Toyota Kata community. The starter kata are just that. There are real-world situations that require more sophisticated tools to uncover what is actually happening. We (as coaches) have to be prepared to help if (when) a learner gets in over their head.

Toyota Kata: From Kaizen Newspaper to Experimenting / Learning Record

In a traditional kaizen event there is usually some kind of todo list for keeping track of progress implementing the ideas of the team. A common name for this form is “Kaizen Newspaper.” The below example is pretty typical. This is a real one from the early 2000’s.

Generic kaizen newspaper showing What, Who, By When, Status

This form reflects a bias in western (certainly USA) business to focus on getting stuff done. I think it might be helpful to reflect a bit on the assumptions that are built in to this structure.

One of my favorite quotes is from Grace Ng: “All customers have problems, all problems have solutions. But not all solutions have problems, and not all problems have customers.”

In the context of this form, the “What” or “Action Step” is usually a solution. We are going to do something. And once the “What” is decided, then the rest falls into place- Who is going to do it, by when are they going to get it done, and what is the current status? And it is all to easy to get pulled into the implement vortex without ever thinking about “Why?” are we doing this – what are we trying to accomplish? How will we know we have accomplished it?

This is also a typical structure for a management staff meeting, and even discussions about strategy – they devolve into “What are we going to do?” and often skip over “Why are we doing it?” In other words, “What problem are you actually trying to solve?”

The “Progress Wheel” tracking percent complete implies an assumption that there are multiple steps involved, and implies a conversation about what those steps are as that wheel is filled in. The quality of that conversation depends on the skill of the coaching and facilitation.

The “By When” or “Due Date” implies that days will pass before we expect this action to be completed. It might be tomorrow, but often is not in practice.

This means that we expect that we wouldn’t get everything done that week. These newspaper items frequently carry over and are supposed to get done as follow-up work after the kaizen week is over. In practice, these things often fall victim to the daily whirlwind and languish. The “newspaper” is now more of an archive. It isn’t about today anymore.

Here is form from another company in the same era. As an aside, this company added “Complexity” to their list of wastes, and perhaps we can see some of that reflected here. But it takes a step in the right direction by adding “Problem to be solved” and, through the “Target Reference” block tries to tie it back to an intended result. It also has a column for “Results” on the far right.

What neither of these forms does, though, is ask “What result do we expect? They depend on skilled facilitation and coaching to ask that question as the team is proposing the idea. One of the challenges we often face (again, in the West and especially the USA) is with our focus on action we don’t default to asking that question.

One exception I experienced in May 2001 was a Shingijutsu consultant (and I don’t remember who it was, unfortunately) who had us modify our kaizen newspaper that week to add a column that captured the cycle time we expected to save as a result of implementing that step. (I know the date because I did the modification on the original file and still have it in my archives.)

The idea was to make sure that we were implementing enough changes to deliver the cycle time target.

What it didn’t do, though, was capture the actual cycle time savings from the action.

What Are We Trying to Achieve?

A common assumption in many continuous improvement efforts is that if people participate in enough of these kaizen events they will experience a mindset shift. The challenge here is that the events themselves are usually focused more on results than on explicitly teaching and practicing the mindset1.

Don’t get me wrong – results are important, especially if you want to keep doing this. It is rare that any organization has infinite (or any!) patience for a lot of discussions around history, hypotheticals, or theory.

That means we have to actually solve real problems. We have to get stuff done. We have to at least look like there is a bias toward action if we want to survive as change agents in most organizations. The key is to solve the problems in ways that develop people’s problem solving skills.

That means making the mindset we want to teach more explicit.

This is the whole point of Toyota Kata.

Build the Coaching Into the Process

A highly skilled coach or facilitator brings teaching the problem solving / scientific mindset into the process, regardless of the forms and structure being used. But we can make this easier on both the coaches and the learners with adjustments to the structure.

While all of the artifacts of Toyota Kata are designed to do this, I want to avoid my tendency for scope creep and stay focused on one (really two) of them that fulfill the intended purpose of the Kaizen Newspaper in a way that develops peoples problem solving skills.

The Learning Record (aka the Experiment Record aka the PDCA Cycles Record aka the PDSA Cycles Record)

I call this form the “powered gear” that drives the entire process. Let’s look at the structure2. The form is structured in a way that turns action items into hypothesis tests.

The first, obvious, thing is that we aren’t just saying what we are going to do and by when. Each action, which we are calling a Step or an Experiment, has a specific predicted result or outcome. Separating the step being taken (the action) from the intended or predicted result helps people distinguish between the two. Allow me to elaborate.

I often see a result or outcome being listed as something that we are going to do. This can go as far as something like “Increase gross margin by 3%” as an action to take.

But that is an outcome (and an indirect outcome at that). It doesn’t say what we are actually going to do that we predict will produce that outcome.

One (the action) is cause. The other (the result) is the effect. Distinguishing between cause and effect is one of the core fundamentals we are trying to teach people who are making improvements or changes.

Explicitly separating what we are going to do from the result we expect helps people practice this mode of thinking. But the coach has to be prepared to ask good questions rather than just buying whatever is written in the boxes.

Taking this a step further, I have sometimes found it helpful to ask a learner to first decide what they want to learn, or the effect they are trying to achieve and write that in Box #2 first. THEN I ask, “What action are you going to take that you think will [ read what is in Box 2 ] ?” and write that action in Box #1.

I can also ask the learner to say, “I intend to [ read what is in Box #1 ] in order to [ read what is in Box #2].” For example, “I intend to rearrange the end of Alice’s work path in order to cut 3 seconds of walking from her cycle time.” If that sentence doesn’t make grammatical or logical sense, there is more thinking to do.

In general (this is a rule of thumb, not a hard rule) there are three kinds of actions that get listed here.

  1. A straight up hypothesis test – make a change with a predicted effect on the process, like the example with Alice’s work cycle above.
  2. Gathering more information – for example getting more detailed information about the current state of part of the process. This might be something like breaking down the cycle time of an individual operator into discrete steps. This could be where I learned Alice has 4 seconds of walking back to the start.
  3. Trying something in order to learn. For example, we have a target process that we can run, but we don’t have a good idea what the obstacles might be. The experiment would be something like “Run to the target process and carefully observe what actually happens” and the expected outcome would be “To learn what the obstacles are.” This is particularly effective for finding sources of process variation.

In general, and this is also more of a guideline, I want to see enough detail that we could give the sheet to someone familiar with the process and they could carry out the experiment from what was written. (This is just a thought experiment! DON’T actually do this. I can confidently predict that you’ll end up repeating the experiment because “what actually happened” won’t be what you thought – though that is an experiment in communication in its own right.)

The “Review / Coaching” line (yellow on this form) is the gate. We don’t cross that line until we have the coaching conversation, just to make sure everything I mentioned above is tight.

All we have at this point, of course, is a hypothesis. “If I do what is written in Box #1, I predict I will see (or learn) what is in Box #2.” Now we have to test that hypothesis. That is why we call this an experiment.

WAIT A MINUTE! Back up! What Obstacle Are You Addressing?

When you are running experiments, you are working to overcome some obstacle that is between you and your goal – your target condition. You want the process to operate in a new way (the target condition), but for [reasons] it can’t. Those reasons are obstacles.

This is different than the typical approach of just brainstorming a bunch of things to do and implementing them. We are targeting a specific way of operating (which is often an intermediate stage on the way to something more challenging).

We want our learner / improver to have an obstacle, problem, unknown of some kind, in mind. It may take – it usually takes – more than one experiment to learn enough to overcome that obstacle and move on to the next.

Address one obstacle at a time.

The Experimenting Record provides structure to reinforce this mindset by having the improver write the specific obstacle or problem in the space on the upper left corner before engaging any experiments. If they don’t know what the obstacles are, then write that as the obstacle, try to run to the new work pattern in order to learn.

“What problem are we actually trying to solve?” is a question that can often reign in an otherwise chaotic discussion about what to do.

The upper right corner has a space for a “process metric.” Without going off on another deep tangent, this is the attribute of the process result that we are trying to affect. The target condition should include a target value for the process metric so we can tell if we are actually making progress toward the target condition.

The process metric can be something like the cycle time of a particular operator; the minutes of exercise I am trying to achieve every day; the amount of variation in a process parameter we are trying to control. These are all things that we can immediately, directly, measurably affect by changing the process in some way.

Why did I address this part of the form second when it should be done first? Because it is very common to bleep over this part and just start writing experiments only to have the effort get diffused later.

Maybe my little digression was unexpected which might result in you remembering it a little better.

Now – Run Your Experiment

In the classic Plan-Do-Check-Act cycle we discuss “Do” and “Check” as sequential activities. In practice they are simultaneous, or nearly so. You should verify that the action you are taking is actually the action you planned to take. CHECK that your DO matches your PLAN.

If you ended up doing something different, you want to make a note of that, because you likely can’t say your plan didn’t work if you didn’t actually carry it out. What ACTUALLY happened? What did you experience? What did you see? What result did you actually get?

The things that we want to see written in Block #3 of the Experiment Record are objective facts. Please don’t just repeat what was in Block #1 in past tense. As a coach I want to see what you actually did as well as the actual outcome vs the planned outcome. And this includes outcomes that you didn’t anticipate. Sometimes those are good surprises – collateral benefit. Sometimes you learn that you need to pivot to a different idea.

Block #4 is subjective. What did you actually learn? There is usually more to this than what was simply in Block #2. This is also a good time to look at your obstacle list and make additions, deletions, and edits. Those are also things that you learned.

After Your Experiment

If you have had an impact on the current condition, update that. As I mentioned above, scrub your obstacle list and make sure it is up to date.

Have you achieved your target condition? If yes, awesome. Time to do a summary reflection, take a deeper look at your current condition, and establish a new target condition with new obstacles. (Same thing if you have reached the “achieve by date” without hitting the target condition.)3

If not, are you still addressing the same obstacle? If yes, then move to the next line on the experimenting record and fill in Block #1 and Block #2 for your next experiment.

In all cases, let what you have learned inform your next step. Notice how this is different than blindly executing a complex action item.

If you are addressing a new or different obstacle, then same thing, but please start a new form.

Why So Much Detail?

Our results-as-action-item corporate culture has a heavy bias to glossing over the details, and they are often not discussed or thought through. An action item might have a due date that is weeks in the future, and other than saying “It’s on track” not much will be discussed.

The Experiment Record is designed to have a small step every day (or nearly every day), discuss what was learned, and allow that to inform the next step so we aren’t blindly executing into something that has become irrelevant.

To be clear, a skilled, experienced coach can bring all of these questions out with a team using the traditional kaizen newspaper. The purpose of the Experiment Record is to make it easier for everyone, the coach included, to dig deeper into the kind of thinking we are trying to teach. It makes these questions explicit rather than relying on the experience and skill of the coach or facilitator.

Honestly, having these things explicit also establishes an expectation that the coach is going to ask about them. When a coach or facilitator starts pushing for more detail within the structure of a process that is overtly superficial they can, well, come across as a jerk. We call it “Socratic Teaching” but we have to remember what happened to Socrates. Better to have a process that makes the structure transparent to everyone.

Even outside of the Toyota Kata ecosystem, this process can bring a cadence of accountability to things as mundane as staff or project status meetings. The key is to not allow any step to go beyond the next scheduled meeting. “I can have that done in four weeks” becomes “What will we do before next Wednesday?” and “What result do we anticipate from taking that step?”

Back to the Kaizen Event

Try this experiment in your next kaizen event.

Throw away your kaizen newspaper.

Ask your team to list the problems that have to be overcome to achieve the goal for the week (which is really a target condition). Put those on a seperate sheet. You can use the Toyota Kata “Obstacle Parking Lot” but that is really just jargon. Call the problems whatever you want – just make sure they are problems and NOT actions to take, or things to implement. What is it about the process that makes it hard to change to the new way? What kind of issues come up that prevent the new way from working smoothly?

Then pick off one of those problems and start a rapid cadence of learning using the Experiment Record format. Keep those cycles quick. Can you do one every 15 or 20 minutes? Probably. The first experiment may well just be a simulation of sorts to learn if this idea is even worth pursuing. Cardboard, tape, holding things by hand to represent a fixture.

If you have a large team you might be tempted to work on more than one of these problems at a time. OK – but first convince me there won’t be any cross-talk between those problems or those experiments. It is really hard to learn when the conditions are changing under your feet because someone else is tugging on the other end of the rope.

At each major step you want to work to stabilize what you have before making the next change. Do this quickly, but incrementally. Doing otherwise is leaving a shaky process behind, and this is disrespectful to the people who have to deal with the aftermath.

At the end of the event celebrate, not so much the results, but what you have learned about making improvements. Wherever you are is where you should be.

Come Monday morning – here is the cool part – don’t stop. Maybe you only run one experiment a day vs. three or four every hour, but keep moving. Keep those coaching cycles running at least once a day.

Congratulations – you are now solving problems in a way that develops people’s problem solving skills.

What’s Next?

Did you find this helpful? Would you like me to go into similar depth on other pieces of the Improvement Kata, such as obstacles, process vs. outcome metrics, etc? Is there something specific you would like me to cover?

Leave a comment and let me know.


1 Another challenge is that most leaders only participate in these events a couple of times a year. The question, then, is what do they practice the other 48 weeks?

2 There are a lot of variations of this form, but those variations tend to be limited to phraseology. The fundamental structure remains the same.

3In a week long kaizen event you should really only have a single target condition to reach by the end of the week – if it is planned well – another deep digression I could go into.

Introduction to Toyota Kata

I recently did an “Introduction to Toyota Kata” session for Kata School Cascadia. The intent is to give an overview of my interpretation of the background, and how Toyota Kata fits into, and augments, your Continuous Improvement effort.

Here is a direct URL in case you can’t see the embed on your phone or pad: https://videopress.com/v/4vWvDZRe

In this presentation I go over what I mean when I say “culture” and then briefly discuss a “continuous improvement culture.” Then introduce the “why” of Toyota Kata as a way to start to nudge the culture in the direction we want it to go.

Finally I overview the structure of the Improvement Kata and Coaching Kata, then answer a couple of questions.

Why Are You Asking Questions?

When someone brings a problem to a leader, it is typical for the leader to begin asking questions. The intent of those questions can make a world of difference.

Diagnostic Questions

In what I would contend is the more typical case, the questions are diagnostic. The leader’s intent is to get more information so that he can then propose or direct a solution. I can certainly speak for myself that when I have knowledge in the domain it is really easy to just drop into this mode. Someone is asking for advice, and I naturally reflex to giving it.

Of course there are times when this is wholly appropriate. Think of a physician and a patient or an auto mechanic and a customer. The customer has a problem that they are not capable of fixing and is engaging an expert to fix it for them or at least tell them what they should do.

Development Questions

If the intent is to develop the expertise in people then the questions must be different. This isn’t about finding the answers, it is about teaching the questions. Here the leader is coaching. The questions are about helping the problem-solver find her threshold of knowledge and the next step to learn more.

In other words, rather than asking the diagnostic questions yourself (as the leader), it is about helping the learner determine what diagnostic questions she should be asking herself, and then going about finding the answers.

Click on the image to download a Toyota Kata coaching pocket card.

This is Harder and Takes Longer

In the short term, it is always easier to just give them the answers. We are all hard-wired to seek out affirmations of our competence. Equally, we are hard-wired to avoid situations that might call our competence into question. It is uncomfortable to be expected to know something we do not. This is part of being human. I would contend it is especially hard to resist showing what I know when I actually DO know (or think I do – though often I know a lot less than I assume).

It can also be frustrating for the learner, especially if they are used to just being told the answers. “Just tell me what to do” is a response that should clue you in to this frustration.

But if your intent is to develop the organization, you have to work a little harder.

Let’s Go See – and learn together

Even if I am asking diagnostic questions, I am likely to get to a point where I start hearing speculative answers or even a hard “I don’t know.” This is a great opportunity to shift gears from diagnostic to coaching with “Let’s go see so we can both understand what is going on.”

Now you can work together to help someone get deeper understanding of the current condition and the nature of the obstacles and problems being encountered. It is also a good opportunity to ask them to document what they are seeing in ways that help them explain it better.

This can take the form of a Toyota Kata storyboard, or an A3, or whatever other structure you are trying to teach and use for problem solving and improvement.

If done well, you will turn “What should I do?” into a learning and growth opportunity for everyone.

Toyota Kata: When to Switch Obstacles

Sometimes the situation arises where the learner has been beating her head against an obstacle with little or no luck overcoming it. The question comes up: When is it OK to give up and switch to something else.

The answer is, of course, a little situational. (Consultant speak: It depends…)

The natural progression of the Improvement Kata will provide an opportunity.

Improvement Kata steps by Mike Rother

As the learner is iterating against obstacles toward the Target Condition the clock is ticking because the Target Condition is always associated with an “achieve by” date. If the Target Condition is achieved OR we hit the “achieve by” date without achieving it, the learner should cycle back to the beginning and:

  • Verify understand of the direction and challenge. (The learner may well have gotten more clarity along the way.)
  • Get a complete grasp of the Current Condition. This is important because often while working toward a Target Condition the learner is only updating specific process and performance metrics, and may not be looking for collateral changes elsewhere. This is a time to take a step back, put up the periscope, and get a grasp of the complete picture.
  • Based on that new Current Condition, establish a new Target Condition, with a new “achieve by” date.
  • Now… identify the obstacles in the way of achieving that new Target Condition. Ideally they should wipe the obstacle parking lot clean and take a fresh look.

This process often helps clear the learner’s mind and see another way to get there, or see easier obstacles that were overlooked before.

This is also why it is important for the “achieve by” date to be relatively close (a couple of weeks) – because that date is a safety valve that forces a reset of the process if the learner is stuck.

If the learner asks if it is OK to work on a different obstacle, then the coach should become curious about the learner’s rationale.

Specifically, I want to understand why the learner thinks there might be an easier way vs. just saying this one is too hard. This may well require some more information gathering – a mini version of the reset I talked about above.

The key point here is to maintain the learner’s motivation. There is a fine line between struggling to solve a problem and getting frustrated. This might be a good time for the coach to engage in some empathetic questioning.

For example, name the feeling you are picking up to test your hypothesis: “It seems you are really frustrated by this…” Then listen. The learner will likely either agree, “yeah, I am.” or refute and give you more information, “No, I’m just trying to…” Then you might learn more about their threshold of knowledge with the process of problem solving.

That can open up a discussion for why the learner thinks it would be a good idea to try something else. Then use your judgement.

But as a coach, I don’t want to make switching obstacles too easy because there is a high risk of it becoming a whack-a-mole game. Some obstacles actually require digging and perseverance to overcome. Your job, coach, is to keep the learner in the game.

Sometimes, though, the learner gets fixated on a problem and doesn’t see another way. Even in this case, if the time to the “achieve by” date is short, I’d let it ride. But if that isn’t practical…

The coach may well have a broader perspective – in fact, this is part of the coach’s job.

If the learner is making progress on something I (the coach) consider a red herring, I generally let it go. There is always learning involved – so long as the effort doesn’t bog down progress.

Sometimes, though, the learner is getting frustrated and so focused that he just doesn’t see any other way.

This is time for gentle intervention with whatever questions might help the learner pause, step back, and see the bigger picture.

For example, perhaps something like “If this obstacle were cleared, how would the process operate?” This might not be the full target condition. I’m just trying to learn what “solved” looks like to the learner. Maybe just thinking about it will help them see the where they are trying to go and possibly another path to get there.

An interesting follow-up might be, “Hmmm, what’s stopping it from working that way now?”

“What would you need to learn to better understand what is going on?” might be another avenue to get the learner to look at his threshold of knowledge vs. the big ugly obstacle in front of him

It all depends on what you think will help the learner raise her head and take a different look at things.

But in the end, if you have a learner that is truly stuck, and after a few tries isn’t going to get unstuck, then, honestly, it’s time to go shoulder-to-shoulder with them and dig into things together.

What I would work very hard to avoid is direct intervention – “Why don’t you work on…” because this undermines the entire process by giving them the answers and can easily create a “what do you think I should work on?” expectation next time.

“A3” is an Obligation for the Coach

In Western business it is pretty typical for someone to be assigned to come up with a proposed solution to a problem, and then seek approval for that solution. In some companies that consider themselves more forward thinking, they might even say something like “bring me an A3.”

As a result I have seen a number of organizations that produce some kind of guideline for “how to fill out and A3.” They teach “problem solving” courses so people can learn to do this properly. I have developed, and delivered, a couple of those back when I was working in internal continuous improvement offices. We had case studies, exercises, all in an effort to teach people to be better problem solvers.

Similarly, a (very) long time ago, I recall an exchange on an online “lean” forum where someone had asked about Toyota’s “problem solving class.” The thought was that because Toyota has good problem solvers, that their course must be really good.

My response was that I have a copy of Toyota teaching materials for a problem solving course. It is good, but nothing magical. Because that isn’t how Toyota develops good problem solvers.

They do it with coaching.

What makes the “A3” process work isn’t the A3, or even the structure. It isn’t the instructions, guidelines, or the quality of the problem solving classes.

It is the almost continuous interaction between the problem solver and the coach.

The problem solver’s thinking is challenged. “What evidence do you have?” “Have you tested that assumption?” “How is that happening?” “Why do you think that is the problem?” “What are you planning for your next step?” “What do you expect to learn?”

And it is the coach’s stubborn refusal to give the problem solver the answer. Rather, they insist on following the rigor of the problem solving process using scientific thinking.*

The process is an application of the principle of “Challenge” followed by support to enable the problem solver / learner to meet the challenge. They have to bring perseverance to to the table, but the coach is there to make sure they actually learn to be better problem solvers in the process.

Likely (if you are reading this) you already know that. We knew that when we worked so hard to make those A3 guidelines and problem solving courses. But we did those things anyway.

Why? Because it is easier to develop and deliver those general class materials than it is to develop managers into coaches and leaders.

But the fact remains:

If you want to develop better problem solvers, what you need are better coaches.

The implications here are really profound for most organizations.

If you assign someone to solve a problem, to “do an A3” (or whatever structure you use), you are obligating yourself to coach them through the process.

This is far more than getting status updates. And it is far more work. Because you are teaching, not just supervising. If they fail, it’s on you, not them. “If the student hasn’t learned, the teacher hasn’t taught.”

In Toyota Kata world we have reduced those questions down to the critical few in the Coaching Kata. That, of course, is a start. Your job as a leader is to practice until the flow of the logic is second nature to you, until you can go beyond the script. Until your first-nature, reflexive response to anyone proposing to do something is “What problem are you trying to solve?” or “What are you trying to learn?” and then carefully listening to their logic and pushing them to the edge of their ability with the next step.

When you can take your own coaching training wheels off, you can then (and only then) ask someone else to ride a bicycle for you, because you will know how to teach them to ride – and that involves more than sending them to a PowerPoint lecture on “Riding a Bicycle.”

“Because knowledge is not understanding” – Destin Sandlin.

———

*Some years ago I worked briefly with a manager who had been one of the key players in Toyota’s initial startup of their plant in Kentucky (TMMK). He told me an interesting story. In the beginning, he noted, the U.S. managers would go to their coordinators (Japanese Toyota senior leaders there to advise the new team) and ask for advice.

Then one week all of the U.S. team went through the problem solving / A3 course. The following Monday, he went to his coordinator with a question, and the response was “Doug-san, where is your A3?” After that day, the coordinators would not engage unless there was an A3 that outlined, in writing, what the manager already understood about the problem, what he was seeking to learn, and how he proposed to go about learning it.

Think about that story vs. sending people to “problem solving class” or even a “Toyota Kata” class. When they return, do you insist that they apply what they have learned whenever it is appropriate from that day forward? If you don’t then you are wasting their time and your money sending them to that class. They will never develop the skill without practice, and it is always easier not to practice something we are not comfortable doing.

Daily Management for Improvement

I’m digging through old archives again, and came across this graphic I put together around 2006 or so. It depicts more detailed version of “Organize, Standardize, Stabilize, Optimize” showing the continuous comparison between “what should be happening” and “what is actually happening.” It is the gap between these two that drives improvement forward.

Like the pocket card in the last post, this is built on a foundation established by the work of Steven Spear, especially his PhD dissertation that is summarized in Decoding the DNA of the Toyota Production System. By the way, if you are in the business of continuous improvement, reading (and understanding) this breakthrough work is critical for you.

Other than generally sharing this, my other reason for putting this up is that in the Toyota Kata community there has been discussion for about a decade about whether or not the right hand loop – pushing for stability – is an appropriate use of the Improvement Kata.

I think that is an unfortunate result of some very early conversations about the difference between “troubleshooting” and “improving” a process. We get into semantic arguments about “problem solving” as somehow different from “root cause analysis” and how the Improvement Kata is somehow distinct, again, from those activities.

This makes no sense to me for a couple of reasons.

Scientific Thinking is the Foundation

Toyota Kata is not a problem solving tool. It is a teaching method for teaching scientific thinking, and it is a teaching method for learning to teach scientific thinking. In the books and most literature, it uses organizational processes as working examples for the “starter kata,” but exactly the same thinking structure works for such diverse things as working through quality issues, developing entirely new products and processes, working through leadership and people issues. The underlying sub-structures may change, but the basic steps are the same.

When I encounter an organization that already has a “standard problem solving approach” I do not attempt to tell them they are wrong or confuse them by introducing a different structure. Rather, I adapt the Improvement and Coaching Kata to align with their existing jargon and language, and help them learn to go deeper and more thoroughly into their existing process.

Stability is a Target Condition

I see a lot of pushback about working to “return a process to standard.” In reality, that is the bulk of the activity in day-to-day improvement. The whole point of having a standard in the first place is to be able to see when the actual process or result is somehow different.

Think about it: If there isn’t an active means of comparing “actual” vs. “standard” what is the point of having a standard in the first place?

Think of the standard as a target condtion.

What obstacles are preventing you from [operating to that standard]? You can guess, but the best way is to diligently try to operate to the target condition and see what gets in your way. That might not happen immediately. Maybe some time will go by, then BAM! You get a surprise.

This is good. You have learned. Something you didn’t expect has interfered with getting things done the way you wanted to. Time to dig in and learn what happened.

Maybe there was some condition that you could have detected earlier and gotten out in front of. Who knows?

This is all part of the continuum of Troubleshooting by Defining Standards.

You Cannot Meet a Challenge Without Working on Stability

As you are working to reach new level of performance – working toward a new challenge – there will be a point when the process works sometimes, so you know it is possible. But it doesn’t work every time because there are still intermittent obstacles that get in the way.

Nevertheless, you have to work diligently to see problems as they occur, respond to them, dig into causes (root cause analysis anyone?) and systematically protect your process from those issues.

The only real difference between covering this territory for the first time vs. trying to recover a previously stable process is that in the later case you can ask “What has changed?”

But, in the end, in both cases – stabilizing a new process vs. re-stabilizing an old one – you are dealing with conditions that are changing from one run to the next. That is why it works sometimes and not others. You don’t know what is changing. You are trying to figure it out by experimenting and learning.

What About Root Cause Analysis?

My challenge is still a stable process.

My current condition is my level of understanding of how the process works today, and the exact mechanism that results in a defect. Even defects are produced by a process – just not the process we want.

That understanding will be incomplete by definition – because if we truly understood what was going on we wouldn’t have the problem. So… what do I know (and can prove with evidence) and what do I not know.

What do I suspect? What evidence do I need to gather to rule out this possible cause, or keep it in play? Next experiment. What do I expect to learn?

I’ll write a more detailed post about this at some point. I think it is a topic worth digging into. Suffice it to say that I have absolutely used the Improvement Kata structure to coach people through finding the root cause of wicked quality problems.

It really helped that they were able to see the same underlying pattern that I had already been teaching them. It made things simpler.

Don’t Complicate a Simple Concept

It’s all “solving problems” (the term “problem solving” apparently has some specific form it needs to take for some people).

The underlying structure for all of it is scientific thinking. Some say it’s PDCA / PDSA. Same thing.

Splitting semantic hairs and saying “this is different” makes simple things complicated. Yes, there are advanced tools that you use when things get tough. But… addition and subtraction; basic algebra; advanced polynomials; basic differential calculus; advanced multivariate calculus – IT IS ALL MATH. You apply the math you must to model and solve the problem at hand.

DON’T apply more math than you need just because you can. That serves no purpose except, perhaps, to prove how smart you are… to nobody in particular.

Solving problems is the same. There are some cases where I need to develop a designed experiment to better understand the current condition – the interactions between variables. There are cases where other statistical tools are needed. Use them when you must, but not just because you can.

Use the simplest method that works.

The Perils of Weekly Toyota Kata Coaching

Outside of the actual operation, the default meeting schedule for most organizations is weekly.

This is OK when everyone understands what is expected and the default thinking and behavior is working for you.

With Toyota Kata, though, the intent is to practice a routine that is not default thinking or behavior. Yet many organizations fall into the default of a weekly coaching cycle.

What we have to remember is that the coaching cycle, and the learner’s preparation for the coaching cycle, are practice. The time(s) that you aren’t practicing you are engaging in the default, and if the default isn’t what you want it to be then it will easily overpower what you are trying to learn.

15 minutes a day is practice. 15 minutes a week is dabbling.

It is the same as a supervisor’s area experiencing one or two “kaizen events” a year. It is just dabbling with kaizen, not practicing it every day, and certainly not immersion. They aren’t going to learn to think differently with that kind of cadence.

Time spent on improvement vs. business as usual
Illustration courtesy of Mike Rother

Batch Production of Experiments

One of the reasons we want to drive toward one-by-one flow in production is so we can have one-by-one confirmation of products vs. waiting for a huge batch to be produced only to discover that they all have problems.

Breaking it down even further, we want one-by-one confirmation of operations so that we don’t keep working on something that is already unusable from something earlier.

Likewise, if a learner is running many experiments without checking in with a coach, he can get pretty far off track without realizing it. The coach can provide a valuable outside check to make sure the learner isn’t getting locked on to something that is distracting him from the bigger picture.

Remember: This is about developing people

Before you jump in and say “But I don’t have time…” consider the alternative.

How much time do you, as a manager, spend intervening in problems that you think people should be able to solve on their own? If you keep giving them the answers, they are going to keep brining those issues to you.

With a little bit of thinking, the Coaching Kata cycle can be easily spliced on to David Marquet’s “Ladder of Leadership” and guide your conversations away from intervention and toward creating able problem solvers.

But before you can do that well, you have to practice the Coaching Kata until asking those types of questions becomes second nature to you.

This isn’t all about the learner’s development! If you only practice coaching once a week, whatever your default is today will likely remain so tomorrow. Change requires repetition and practice.

Just some things to think about this week.

The Key to Innovation is Iterate and Test

Key points from this great TED talk by Joi Ito, the director of the MIT Media Lab.

You can’t plan the path, you can only set the direction. He talks about the “compass” guiding a project that followed a route which was totally unpredictable. There was no way to plan out the path to success from the beginning.

Instead, at each step, they asked “Where are we now?”

“What do we need to do next?”

“What’s in the way of doing that?”

“How do we deal with that?”

I’m paraphrasing here, of course, but the key is that once again we have an instance the Improvement Kata pattern in the wild.

Ghost Victories – an excerpt from Upstream by Dan Heath

Amazon affiliate link to book listing for Upstream by Dan Heath
The link to the image takes you to the Amazon listing for the book. If you happen to order it, I get a small kickback, no cost to you, Just FYI.

Dan Heath has just published a new book, Upstream: The Quest to Solve Problems Before They Happen.

I just got the book, and am reading it now. I think there is going to be a lot of good material to discuss here.

But this post is about a marketing email with an excerpt really resonated with me, and I want to discuss that. I wrote to Dan Heath, and got his permission to use pieces of the excerpt here. (Thank you, Dan)

Management By Measurement = “Ghost Victories”

I have talked about what I call “management by measurement” in the past. In that post I told a true story of a company that placed very heavy emphasis on reducing inventory levels without digging into how that performance was achieved. The net result was a an embarrassed CEO during a quarterly analyst’s call. Not good.

Dan Heath talks about the same thing in Upstream. He calls it “ghost victories.”

[when] there is a separation between (a) the way we’re measuring success and (b) the actual results we want to see in the world, we run the risk of a “ghost victory”: a superficial success that cloaks failure.

The most destructive form of ghost victory is when your measures become the mission. Because, in those situations, it’s possible to ace your measures while undermining your mission.

He goes on to describe a case in the U.K. where the Department of Health established penalties for wait times longer than four hours in the Emergency Departments. And it worked. Wait times were reduced – at least on paper. Then the facts began to emerge:

 In some hospitals, patients had been left in ambulances parked outside the hospital—up until the point when the staffers believed they could be seen within the prescribed four-hour window. Then they wheeled the patients inside.

In the old post I referenced above, I said:

If making the numbers (or the sky) look good is all that matters, the numbers will look good. As my friend Skip puts it so well, this can be done in one of three ways:

  • Distort the numbers.
  • Distort the process.
  • Change the process (to deliver better results).

The third option is a lot harder than the other two. But it is the only one that works in the long haul.

All of this ties very well to Billy Taylor’s keynote at KataCon6 where he talked about the difference between “Key Activities” and “Key Indicators.” It is only when we can get down to the observable actions and understand the cause-and-effect relationship between those actions and the needle we are trying to move that we will have any effect.

To avoid the “Ghost Victory” trap, Dan recommends “pre-gaming” your metrics and thinking of all of the ways it would be possible to hit the numbers while simultaneously damaging the organization. In other words, get ahead of the problem and solve it before it happens.

He proposes three tests which force us to apply different assumptions to our thinking.

The lazy bureaucrat test

Imagine the easiest possible way to hit the numbers – with the least amount of change to the status quo. The story I cited above about inventory levels is a great example.

I can make my defect rates improve by altering the definition of “defect.”

There are lots of accounting games that can be played.

This is one to borrow from Skip’s list – How can the underlying numbers be distorted to make this one look good when it really isn’t?

The “rising tides” test

What external factors would have a significant impact on this metric? For example, I was working at a large company where a significant part of their product cost was a commodity raw material. As the market price went down, “costs” went down, and bonuses all around. But when the market price went up, “costs” went up and careers were threatened and bad reviews issued.

Those shifts in commodity prices had nothing to do with how those managers were doing their jobs, the tide rose and fell, and their fortunes with it.

The question in my mind is “What things would make this number look good, or bad, without any effort or change in the process we are trying to measure?”

The defiling-the-mission test

Hmmm. This is a tough one. (not really)

And it is a really common problem in our world of quarterly and annual expectations. In what ways could meeting these numbers in the short term ultimately hurt our reputation, our business, in the long term?

For example, I can think of an ongoing story of a product development project that hit its cost and schedule milestones (what was being measured). But they did so at the cost of destroying their reputation with customers, their Federal regulators and the public (and, to a large extent, their employees). They now have a new CEO, but the deeper problem has origins in the late 1990s.

How long will it take them to recover? That story is still playing out.

In another case I was in a meeting with a team that was discussing a customer complaint. The ultimate cause was a decision to substitute a cheaper material to reduce production costs. But this is a premium brand. There was a great question asked there: “Which of our values did we violate here?” – so the introspection was awesome.

Next step? Ask that question before the decision is made: “Is this decision consistent with our values?” If that makes you uncomfortable, then time to look in the mirror.

Then there is this little incident from 2010:

Picture of burning Deepwater Horizon oil platform
BP Deepwater Horizon fire – Photo by USCG

The metric was cost and schedule. Which makes sense. But the behavior that was driven was cutting corners on safety.

Getting Ahead of Problems

The book’s subtitle says it is about getting ahead of problems. I am looking forward to reading it and writing something more comprehensive.