Category: Toyota Kata

Posted on

Toyota Kata Seminar, Day3

The key points addressed today (Day 3) at the Toyota Kata seminar were:

  • The PDCA cycle – small experiments that the “learner” develops to advance toward the target condition.
  • The coaching cycle (or kata) – an introduction to the role of the coach, and how coaching is structured in practice.
  • A fairly brief discussion on the current experience with the implementation path for an organization.

Roles

Even though the book and course material are quite explicit, a couple of people in the room weren’t readily grasping this until today.

Who Is Being Coached?

In the Kata model, the first level of “learner” is the first line leader who has direct responsibility for the process, and the people who work in it.

On a production floor, this would be the area supervisor.

The core material of the course is how to plan and execute continuous improvement in your work group. This is called the “Improvement Kata”

The “Coaching Kata” is covered and demonstrated (quite well), but it is not the prime topic this week.

Who is doing the coaching?

The coach is nominally the direct supervisor of the person being coached.

To learn how to coach, one must first learn the game. Thus, no matter your role in the organization chart, you come to this seminar gain awareness of the role of your first line leaders.

Then you go home and practice the role some more. Once you have lived in their shoes, then you can turn around and expect them to do the same.

What is absolutely critical to understand here is that this is not a “kaizen event” model. This is a daily improvement model. The coaching cycle happens for a few minutes every day between front line supervisor and the immediate manager. It is a process for developing better supervisors. It cannot (or at least should not) be delegated.

Here is the crucial difference: In many kaizen events, the specialist staff workshop leader is the one directing the actions of the team. The area supervisor may be a member of the team, but she is often not the one actually guiding the effort. In this model, there is no “learner” because there is no deliberate process to improve the problem solving and leadership skills of the supervisor.

If the course has a weak point it is that we “learners” are organized in a way that LOOKS more like a traditional kaizen team, which shifts the instructor / coach more into a role that LOOKS like that of the traditional kaizen workshop leader. Thus, it is easy for a participant to slip into a well-engrained mindset about kaizen events. We have all “practiced” the kaizen event pattern many times. The “kata” pattern is new.

This is the nature of the instructor coaching a group of “learners” rather than the 1:1 that is designed to happen in reality.

So, advice if you decide to attend: Be explicitly conscious that the structural limitations of the course, and deliberately work to overcome them in your mindset. This will help you grasp the material that you are there to learn.

That being said, I have a very explicit picture now of how I want shop floor supervisors to behave and lead. I have a pretty good idea of how to help them get there.

I’ve got an early flight, more later.

Posted on

From The Toyota Kata Seminar

I am taking the Toyota Kata seminar this week in Ann Arbor. There are two programs offered:

  • A one-day classroom overview of the concepts in Toyota Kata.
  • The one-day classroom overview followed by two days of practice on a shop floor, for a total of three days.

I am taking the three day version.

Impressions of Day 1

There are about (quick count) 36 participants, a big bigger group than I expected considering the premise. I don’t know how many are not going to be attending the shop floor part, but most people are.

I suppose the ultimate irony is the slide that makes the point that classroom training doesn’t work very well for this.

Realistically, I can see it as necessary to level-up everyone on the concepts. The audience runs the gamut of people who have read, studied, written about, made training material from, and applied the concepts in the book; to people who seem to have gone to the class with quite a bit less initial information.

That being said, everyone had some kind of exposure to lean principles, though there was a lot of “look for waste” and “apply the tools” mindset present. Since one of the purposes of the class is to challenge that mindset, this is to be expected.

You can get a good feel for the flow and content of the material itself on Mike Rother’s web site. He has a lot of presentations up there (via Slide Share).

Like any course like this, the more you know when you arrive, the more nuance you can pull out of the discussion.

Since I have been trying to apply the concepts already, my personal struggles really helped me to get a couple of “ah-ha” moments from the instruction.I arrived with a clear idea of what I wanted to learn, and what I thought I already knew. Both pre-disposed me to get insight, affirmation, and surprise learning from the material.

I would not suggest this for anyone who was looking to be convinced. Classroom training in any case doesn’t do that very well, and this material isn’t going to win over a skeptic. You have to be disposed to want to learn to do it.

At the end of the day, the overall quality, etc. of the presentation was pretty typical of “corporate training” stuff – not especially riveting, but certainly interesting. But we don’t do this for the entertainment value, and the learner has a responsibility to pull out what they need in any case.

Insights from Day 2

Day 1 is intended, and sold, as a stand-alone. The next two days are available as follow-on, but not separately.

The intended purpose was to practice the “improvement kata” cycle in a live shop floor environment. Today was spent:

  • Developing our “grasp of the current condition.” There is actually a quite well structured process for doing this fairly quickly, while still getting the information absolutely necessary to decide what the next appropriate target is.
  • Developing a target condition. Based on what we learned, where can this process be in terms its key characteristics and how it performs, in a short-term time frame. (A week in this case)

Key Points that are becoming more tangible for me:

The “Threshold of Knowledge” concept.

I elaborated on Bill Costantino’s (spelled it right this time) presentation on this concept a while ago. In the seminar, I am “groking” the concept of threshold of knowledge a bit better. Here is my current interpretation.

There are really three thresholds of knowledge in play, maybe more. First is the overall organization. I would define the organizations’ threshold of knowledge as the things they “just do” without giving it any thought at all.

For example – one company I know well has embedded 3P into their product design process to deeply that the two are indistinguishable from one another. It is just how they do it.

They still push the boundaries of what they accomplish with the process, but the process itself is familiar territory to them.

Likewise, this company has a signature way to lay out an assembly line, and that way is increasingly reflected in their product designs as 3P drives both.

It wasn’t always like that. It started with a handful of people who had experience with the process. They guided teams through applying it, in small steps, on successively more complex applications until they hijacked a design project and essentially redid it, and came out with something much better.

Another level of knowledge threshold is that held by the experienced practitioner.

Today I walked into a work cell in the host company for the first time, and within a few minutes of observation had a very clear picture in my own mind of what the next step was, and how to get there. My personal struggle today was not in understanding this, but in methodically applying the process being taught to get there. I knew what the answer would be, but I wasn’t here to learn that.

An extended threshold of knowledge in one person, or even in a handful of people, is not that useful to the company.

But that is exactly the model most kaizen leaders apply. They use their expert knowledge to see the target themselves, and then direct the team to apply the “lean tools” to get there.

They tell the team to “look for waste” but, in reality, they are pushing the mechanics. You can see this in their targets when they describe the mechanics as the target condition.

The team learns the mechanics of the tools, but the knowledge of why that target was set remains locked up in the head of the staff person who created it.

So his job is to set another target condition: Expanding the threshold of knowledge of the team.

He succeeds when the team develops a viable target themselves. It might be the same one he had, but it might not. If he framed the challenge correctly, and coached them correctly, they will arrive at something he believes is a good solution. If they don’t he needs to look in the mirror.

So the next level of knowledge threshold is that held by the team itself.

If enough teams develop the same depth, then they start to interconnect and work together, and we begin to advance the organization’s threshold. Now what was previously required a major “improvement event” to develop is just the starting baseline, and the ratchet goes up a bit.

None of the above was explicitly covered today, but it is what I learned. I am sure I’ll get an email from a certain .edu domain if I am off base here. Smile

There is no Dogma in Tools

This is the third explicit approach I have been taught to do this.

The first was called a “Scan and Plan” that I learned back in the mid/late 1990’s. It was more of a consultant’s tool for selecting a high-potential area for that first “Look what this can do” improvement event.

Though I don’t use any of those forms and tools explicitly, I do carry some of the concepts along and apply them when appropriate.

Then I was exposed to Shingijutsu’s approach. This is heavily focused on the standard work forms and tools. Within the culture of Shingijutsu clients, it would be heresy not to use these forms.

The “Kata” approach targets pretty much the same information, but collects and organizes it differently. I can see, for myself, a of better focus on the structure of establishing a good target. I can also see a hybrid between this method and what I have used in the past. Each form or analytical tool has a place where it provides insight for the team.

One thing I do like about the “Kata” data collection is the emphasis on (and therefore acknowledgement of) variation in work cycles. (All of this is in the book by the way. Read it, then get in touch with me if you want some explanation.)

Now, I want to be clear – in spite of the title of this section, when I am coaching beginners, I will be dogmatic about the tools they use. In fact, I plan to be a lot more dogmatic than I have been.

I am seeing the benefit of providing structure so that is off the table. They don’t have to think about how to collect and organize the data, just getting it and understanding it.

What I can do, as someone with a bit more experience, is give them a specific tool that will give them the insight they need. That is where I say “no dogma.” That only applies when the principles are well within your threshold of knowledge.

The real ah-ha is that, unlike the Shingijutsu approach, we weren’t collecting cycle times at the detailed work breakdown level. Why not? Because, at this stage of improvement, at this stage of knowledge threshold for the team, the work cell, that level of detail is not yet necessary to see the next step.

I will become necessary, it just isn’t necessary now.

Target Conditions and PDCA Cycles

One place where my work team bogged down a bit this afternoon was mixing up the target condition that we are setting for a week from now, and what we are going to try first thing in the morning.

The target condition ultimately requires setting up a fairly rigid standard-work-in-process (SWIP) (sometimes called “standard in-process stock) level in the work cell.

There was some concern that trying that would break things. And it will. For sure. We have to stabilize the downstream operation first, get it working to one-by-one, and make sure it is capable of doing so.

The last thing we want to do while messing with them is to starve them of material.

So – key learning point – be explicitly clear, more than once, that the Target Condition is not what you are trying right away. It is the predicted, attainable, result of a series of PDCA steps – single factor experiments. You don’t have the answers of how to do it yet. So don’t worry about the SWIP level right now. That will become easier… when it is easier.

More tomorrow…

Posted on

Bill Costantino: Toyota Kata “Unified Field Theory”

Mike Rother and Bill Costantino have shared a presentation titled “Toyota Kata Unified Field Theory.”

I think it nicely packages a number of concepts in an easy-to-understand flow.

I want to expand on a couple of points but first take a look at the presentation.

This is a direct URL to the original SlideShare version: http://www.slideshare.net/BillCW3/toyota-kata-unified-field-theory

Challenges and Campaigns

First of all, this presentation differentiates between a “challenge” and the target condition. That is important, and (in my opinion) had not been as clear in Rother’s original book.

I have been advocating setting a challenge, or campaign if you well, for some time. This is where we address a class of problems that are a major issue. Things like:

  • Too much cash tied up in working capital. (Which can be expressed a number of ways, such as improving inventory turns.)
  • Poor schedule performance – “on time delivery” becomes the theme.
  • Quality issues (too much rework, scrap, etc.)
  • Our nurses don’t have time to prepare rooms for the next patient.
  • Of course, safety can come into this arena as well, as can other issues that impact the organization’s health.
All of these things are not really problems in the sense that they can’t really be solved. These are the aggregated symptoms of lots of smaller underlying problems that accumulate into things on this list.

Setting a specific challenge doesn’t mean you ignore the other stuff. You have been coping with it and working around it for years. But you know you haven’t had time to fix everything, so stop believing that you do.

The point here is to galvanize the effort.

Chip and Dan Heath address the importance of setting the challenge in their book Switch (which I have reviewed here). They emphasize the importance of “scripting the critical moves” and “pointing to the destination” so that people have a good grasp of what is important.

Once the challenge is addressed, say “on time delivery,” it can be broken down into target objectives that are both local (large organizations need to have things broken down to what the local group is expected to work on) as well as those which cut cross-functionally. The scope of the effort is really defined by the depth of the organization’s skill at addressing the issues at this point.

Bill Costantino correctly points out that setting the vision, and deciding the theme or campaign, is a leadership function. This can’t be done by your “lean team” in a way that sticks. The discipline required here is for the leaders to maintain what Deming referred to as “consistency of purpose.”

Simply put, to say “this is the challenge” and then continuously ask about other stuff jerks people around and serves only to paralyze the organization until the leaders decide what people should spend their limited time on.

The good news is that it really doesn’t matter. If the organization can focus on One Big Thing long enough, their efforts will eventually touch on the other stuff anyway.

Jim Collins uses different words to make the same point in Good to Great with the “Hedgehog Concept.”

The Path to the Target Condition

One place where I think we can still use some more clarity is in the illustration of the path to the target condition.

This is the illustration from Slide 20 in the Slideshare version of the presentation:

The presentation (and Rother’s coverage in Toyota Kata) is quite clear that navigation through “the grey zone” is a step-by-step process (kind of like driving off-road at night where you only see as far as your headlights).

But the “plan and execute” paradigm is very strong out there.

My experience is that people in the field see this illustration, and fully expect the green path to be set out, and the “dots” identified, along with a time line and resources required to get there. It becomes a “project.”

This is a strong symptom of the “delegate improvement” paradigm that we should all be actively refuting.

Let’s look at how I think this process actually plays out dynamically.

Initially we know where we are, we have target condition, so we know the direction we need to go to get there.

We are still inside the red line of the “current knowledge threshold.” Solving these problems is generally application of things we already know how to do, perhaps in new ways.

And having solved one problem, we now identify the next known barrier:

Once that one is cleared, we see a couple of choices. Which one?

All other things being equal, pick the easiest, and move on. (As we said when I was learning rapid maneuver tactics in the Army – “haul ass and bypass.”)

Up to this point, we have been operating inside the “current knowledge threshold.” Our efforts are better focused by pursuing a clear target objective, but we aren’t really learning anything new about the process. (Hopefully we are becoming better practiced at problem solving.)

Pretty soon, though, we reach the edge, and have to push out the red line. Why? Because we can’t solve a problem we don’t understand. As we approach the boundary, things get harder because we have to do a better job assessing, and extending the knowledge threshold around the problem.

This is the essence of the problem solving process – If you can’t see the solution, you need to better understand the problem.

The process becomes one of progressively solving problems, identifying the next, and expanding our understanding. Once there is sufficient understanding to anchor knowledge and take the next step, do so. Step and repeat.

Putting the whole thing in motion, it looks like this:

The key is that the “green path” isn’t set out as a predictable trajectory. It is hacked out of the jungle as you go. You know you are going, are confident you can get there, but aren’t sure of exactly what issues will be encountered along the way.

Let me apply my “Project Apollo Test” to this process.

Vision: “The USA will be the undisputed leader in space exploration.” Vague, a long way out there, but compelling.

Challenge, Theme: “…before this decade is out, […] landing a man on the moon and returning him safely to the Earth.” In 1961, a serious challenge, but considered do-able based on extrapolating what we knew.

At this point, though, space exploration was exploring a lot of different things. Building a space station, reusable launch vehicles, pretty much the whole gamut was being explored by someone, somewhere. The effort wasn’t focused. The “man on the moon” goal focused it. Every thing was pretty much dropped except solving the problems that were in the way of making Lunar Orbit Rendezvous work.

There were four target conditions that had to be cleared.

Build and test the Big Honkin’ Rocket called the Saturn V plus the infrastructure to launch them in rapid succession.

And they had to answer three questions:

  1. Can people spend two weeks in space without serious physical or psychological problems?
  2. Can we build a space suit that lets someone operate outside the protection of a space craft?
  3. Can one space craft maneuver, rendezvous and dock with another?

Of course each of these objectives, in turn, had lots of smaller challenges. NASA’s effort between 1962 and 1966 was focused on answering these three questions.

In doing so, the threshold of knowledge expanded well beyond the immediate issues.

Yup, I’d say this thinking works, and it scales up.

Why did I go through this little exercise? Because if this thinking can put people on the moon, it is probably powerful enough to move your organization into new territory.

Back on Earth, a company undertaking “lean” needs to really grasp that they need to be committing to embracing this process. There are clear things that leaders need to do to make it work, and those things go beyond “supporting” or “sponsoring” the effort. We’ll get into some details on the next few posts as we continue to build on Rother’s and Costantino’s work.

 

 

Posted on

Firefighting Kata

27 months ago I wrote a piece about a “firefighting culture” where I described the actual process used to fight fires – following PDCA.

I have learned a few things since then, and I want to tighten my analogy a bit.

What is the core thinking behind true firefighting? This is actually closer to home than you may think. Many companies have situations that are on fire – in that they are destructively out of control.

I recall Mr. Iwata lecturing a group of managers in a large aerospace company in Seattle. He listened patiently to their grand plans about how the transformed operation would look. Then his remarks cut to the chase.

“Your house is on fire. This is not the time to be thinking about how you will decorate it.”

The question is – does urgency force a change in the thinking or approach?

I say it does not. However urgency does stress people’s skills and capabilities to deal with the situation to the limit – and beyond. Thus, it is best if those skills are thoroughly developed before there is a crisis, when the stakes are not so high. This is how high-risk professions train. They work to develop ingrained habits and skills for handling chaos before it is real.

So let’s go to our hypothetical burning building and look at what happens – as a matter of routine – even though every situation is different.

The target condition is a generally a given: The fire is extinguished, things are cooled down enough that there will be no re-ignition.

What is the current condition? Yes, the building is on fire. (doh!) But there is more to it than that.

What is stopping us from putting this fire out right now?

What is the layout of the building? Its construction? Where are the air shafts, sources of fuel, oxygen? Are there hazards in the building? Is there a basement under the main floor? Is there anyone inside?

Because they are (hopefully) skilled and practiced, gaining this information is routine, and hopefully they are getting most of it on the way.

The fire chief on site is going to develop an overall strategy for attacking the fire, and deploy his forces accordingly.

One thing they do not do – they don’t go creating action item lists, they don’t go hunting for fires, and they don’t just go into reaction mode.

Neither do they have a detailed “action plan” that they can blindly follow. Simply put, they are in an vague situation with many things that are still not known. These things will only be revealed as they progress.

What is the first problem?

The initial actions will be more or less routine things that help the effort, and gain more information. They are going to ventilate the roof to clear smoke, and they are going to first work to rescue any people who are trapped.

This is their initial tactical target condition.

As they move toward that target, they will simultaneously gain more knowledge about the situation, decide the next objective, and the actions required to achieve it.

Cycle PDCA

As they carry out those actions, either things will work as predicted, and the objective will be achieved or (more likely) there will be surprises. Those surprises are not failures, rather they are additional information, things that were not previously understood.

Because this is dangerous work, if things get totally strange, they are going to back-out and reassess, and possibly start over.

As they go, they will work methodically but quickly, step by step, never leaving fire (unsolved problems) behind them, always having an escape path.

And, at some point along the way, what must be done to accomplish the original objective, put out the last of the fire will be come apparent.

Why are they so good at this?

Simple. They practice these things all of the time, under constant critical eyes of trainers. Every error and mistake is called out, corrected, and the action is repeated until they routinely get it right. Even though they are very good at what they do, they know two things:

  1. They can get better.
  2. Their skills are perishable.

So, although each fire is different, they have kata that they practice, continuously – from basic drills to training in more complex scenarios. They are putting these things to use now that there is real urgency.

What about the rest of us?

In business, we tend to assume that crisis will either not occur, or when it does will be within our domain of being able to handle it… but we often get surprised and our problem solving skills are stretched to the breaking point.

Why?

Because we have never really practiced those skills, and if we have, we have not been critical enough of how we went about solving routine problems, and we are sloppy.

When there is no urgency, we can get away with being sloppy. When method is not critical, anything more or less works. But when things are complicated, messy, and right now, there isn’t time to practice. “You go to war with what you’ve got.” What that really means is that, however ill-prepared you are, you now have to deal with reality.

Problem solving is as important to a business (and I include any human enterprise, profit or not in this) as it is to the firefighters. Business has technical skills, as firefighters have handling hoses, operating their equipment, etc. But no matter how competent firefighters are at their technical tools, they are lousy firefighters if they have not practiced quickly solving problems related to putting out fires.

Likewise, no matter how good you are at keeping your books straight, managing your order base, scheduling production, whatever routine things you do, if you have not practiced problem solving skills on a daily basis, you are likely not very good at it. Daily kaizen is practice solving problems. The side-benefit is your business gets better as a result.

The difference is that firefighters know it is important, so they practice, subject themselves to the critical eye of professional trainers and coaches. In business, nobody teaches “problem solving” except in the most vague way.

 

“All we do is fight fires.”

Hopefully you wish you were that good.

Posted on

Toyota Kata: Avoid Pareto Paralysis

A great key point comes out on page 124 of Toyota Kata by Mike Rother.

…a Toyota person once told me to focus on the biggest problem. However, when I tried to do this I noticed a negative effect: We got lost in hunting for and discussing what was the biggest problem. When we tried gathering data and making Pareto charts, it took a lot of time and the biggest problem in the Pareto chart was usually “other” which put us back into debating options. By the time we decided what the biggest problem was, the situation at the process had changed. This effect is called Pareto paralysis, and I encourage you to avoid it. Pareto paralysis delays your progress as people try to determine the “right” first step to take.

[…] it matters more that you take the first step than what the first step is.

I have seen this many times with my own eyes. It is a common problem when “problem solving” is taught as “application of the seven tools” and “correct” use of the tools becomes more important than understanding the problem or making actual progress.

Hirano, I believe, has been quoted as saying:

Waste often comes disguised as useful work.

That is what is happening here. The team thinks they are working to solve the problem when, in reality, they are still trying to decide what problem to work on. The gridlock may be driven by fear of working on the wrong problem. But in reality, there is no wrong problem, there is only the one that is in your way.

Here is something else I commonly see. When they discover “problem solving” many organizations want to immediately undertake large projects that involve “stretch goals” and breaking down complex issues. They look at operational metrics that are actually aggregated – total inventory, total lead time, productivity of the entire factory, total defect rates, total lead time through the system. While those metrics are nice to gage progress, they do not give you any actionable information.

Even worse is using averages. Averages aggregate even more, and “bad” tends to be countered by “good” in many average calculations. What is important is to look at each instance vs. an external, discrete, and objective standard or specification. Average defect rates tell you nothing at all about what to work on. But this unit had this defect, or this part dimension was this amount out of specification DOES.

Put another way, there are very few big problems. Big “problems” are the aggregated symptoms of many small problems.

This is good news and bad news.

The good news is that small problems can usually be understood, cleared and sometimes solved fairly quickly. The bad news is that it takes work to do this. The other bad news is that there isn’t any other way that actually works.

Doing a good job working on large complex issues requires engaging across the organization, time, and a high level of skill at understanding the situation, framing the problem, getting to causes, working on solutions, testing understanding, etc. Doing it well requires a mentor who is intimately familiar with the thinking behind problem solving.

This skill can not be gained in a “problem solving” or “A3” class, at least not one that simply walks the team members through the process once or twice. Skill comes from practice, and effective practice comes from starting simple, working in an environment where it is safe to experiment and to be wrong. This means working on shop floor issues that can be isolated from one another, the effect of a test or simulation can be seen immediately. The factory and production organization that Steven Spear describes in his research about Toyota is actually designed deliberately to facilitate this kind of work.

Another common mistake is setting up performance targets too early. If the processes are inherently unstable – if there is no sense of takt time, you are having problems with consistent quality or delivery, the first goal is simply to get to the point where you actually know how things are performing against an indicator of stability. Again, this is usually much simpler than setting a high level target and then trying to break down and stratify all of the issues out there. Set that stability target, study the process, and take on the disruptions as you see them. If there is a debate about which one to start with, then start with the simplest one so you can improve your capabilities.

In the end, it is about taking on problems as they come up, where they come up. That thinking is facilitated by the way you structure the flow, the work, and the organization itself. Get to the shop floor, stand in the chalk circle, and ask “What is stopping this team member from being successful right now.”