Category: Toyota Kata

Posted on

DMAIC and Toyota Kata

A lot of the organizations I deal with have a legacy with Six Sigma, or some x-Sigma variant. If they are now trying to incorporate Toyota Kata as a way to shift their daily behavior, questions arise about how it fits (or might fit, or whether it fits) with DMAIC.

This sometimes comes about when the impetus to embrace Toyota Kata comes from outside the organization, such as an initiative from the corporate Continuous Improvement office. In this case, unless integration with legacy approaches is carefully thought through, Toyota Kata (or whatever else is coming down the pipeline) can easily be perceived as “yet another corporate initiative” or “something else to do” rather than “a new (and hopefully better) way to do what we are already doing.”

My Background

First a disclaimer. My deepest exposure to Six Sigma was during my time as a Quality Director in a large company that had a long history with TQM and then Six Sigma. Thus, I dealt with the Black Belts and Green Belts in the organization, and paid a lot of attention to the projects they were working on.

In addition, every certification project for a new Black Belt came across my desk. Unlike a lot of managers in the chain (apparently), I actually read them, parsed them, and asked questions when I couldn’t follow the story line of the project. (Apparently nobody expected that, but it’s another story.)

I worked with the corporate Master Black Belt, made input into their programs, and did what I could to create a degree of cooperation, if not harmony, between the Six Sigma community and the lean guys.

Thus I am not claiming this is anything new or profound. Rather, this is sharing my own sense of connection between these two approaches in a world where I often find them competing for people’s mindspace.

The Improvement Process Flow

As I observed it, a Six Sigma project was typically organized and conducted as follows:

An area manager, usually a Green Belt, identifies something that needs improving. He assembles a team of stakeholders. He is coached by a Black Belt through*:

Defining the problem and establishing a charter for the team.

Establishing a Measurement that will define progress.

Conducting a thorough Analysis of the process, with a primary focus on sources of variation, especially those which are intertwined with quality issues.

Developing a list or set of Improvements and putting them into place, again focusing primarily on variation in methods, etc. that drive defects.

Establishing a standard to Control the process and keeping it running the new way.

Define, Measure, Analyze, Improve, Control. DMAIC.

In actual practice, it is very similar to the large single-loop “six step problem solving” process I was taught as “the problem solving process that came out of TQM.” That is probably not a coincidence.

DMAIC projects are typically targeted at measurable significant financial payback. Black Belts are trained to find and spend their time on high-payback projects. At least in the company I worked for, there was a minimum payback they had to achieve to get their certification. They also had to demonstrate knowledge of the various high-powered statistical tools.

It makes sense for people steeped in this methodology to ask how it fits in with “short cycles of experiments and improvements” that are the anchor for not only Toyota Kata, but kaizen in general (if you are doing it right).

And, put another way, if the organization is trying to establish a coaching culture using Toyota Kata, is Toyota Kata something different from DMAIC, or do they fit together? (I have actually been asked exactly the same question about Toyota Kata and kaizen(!), but that, too, is another story.)

To give credit where credit is due, this was the topic over lunch last week at a client site whose Six Sigma projects also follow the general structure I outlined above. Jazmin, the continuous improvement leader, was already working through this in her mind, and recognized the linkage right away.

Since the company has an active Six Sigma program, with dozens of projects ongoing, we wanted to find a way to integrate Toyota Kata thinking into what they were already doing vs. introducing yet another separate initiative. (It is easier to “embrace and extend” something you are already doing than bring something brand new into the domain.)

Relating DMAIC to the Improvement Kata

Here is how I relate DMAIC to the Improvement Kata.

Define the Problem =(more or less) Challenge and Direction. This is what we are working on, and why it is important.

Measure and Analyze = Grasp the Current Condition. Six Sigma has a host of powerful tools (which are often used just because they are there … so be careful not to make easy things complicated).

I would point out that if you follow the process in the Improvement Kata Handbook, you are also initially focused on variation in the process. Lean people tend to reduce all variation down to units of time, but in that noise are all sources of variation of the process. Defects, for example, don’t count as a delivery, and so introduce noise into the exit cycles. Machine slowdowns and stoppages, likewise, disturb the rhythm of the process. Like DMIAC, the Improvement Kata, as outlined in the handbook, steers you toward sources of variation very quickly.

Thus, a Six Sigma project team, and an improver following the Improvement Kata are both going to initially look for sources of instability. (Quality First, Safety Always).

At this point, the two diverge a little, but only a little.

Perhaps because DMAIC sounds like a single cycle, a fair number of teams tend to try to Implement a Single Grand Solution. They spend a fair amount of time brainstorming what it should look like, and designing it. Then, once they think they have a solution, they put it into place by establishing new “standards” (in this context, that usually means procedures), training people, and validating that it all works.

Again – a lot of kaizen events do pretty much the same thing, they just might do it faster if it is a classic five-day event.

A few years ago I was on a discussion panel at a conference in Chicago that was very Six Sigma centric. In the various breakout sessions, the Black Belts (who are mostly staff practitioners) universally complained about “management embracing the changes” and not enforcing the new processes. They were frustrated that once they were done, things slipped back.

In other words, once the energy input of the project itself stopped, entropy took over, and things regressed back to the original equilibrium.

And (once again) traditional kaizen events often have the same problem.

Blending Toyota Kata and Six-Sigma Coaching

Think of this conversation between the Black Belt coach and the Green Belt project leader in their daily meeting and check-in:

[preliminary social rituals]

“Just to review, what is the problem you are working on?”

[Green Belt reviews the charter and objective]

“Great, so what is the target condition you are striving for right now?”

[Green belt describes the next intermediate step toward the chartered defined state. He describes how the process will operate when key parts of it are stabilized, for example.]

The Black Belt is listening carefully, and may ask follow-up questions to make sure the target condition is clearly on the path toward solving the defined problem vs. chasing something interesting-but-irrelevant to the issue at hand.

“Good. Can you tell me the last step you took?”

[Green Belt describes a change they made, or some additional data they needed to collect and analyze, or a control measure they have experimented with, etc]

“What did you expect from that step?”

[Green Belt reviews the intent of the action, and what he expected to happen.]

“And what actually happened?”

[Green Belt describes what his data collection and observation revealed about the process, or how well his control measure worked to contain a source of variation, etc…. or didn’t.]

“And what did you learn?”

[Green Belt describes insights that have been gained, especially insights into sources of variation, or the effect of controlling them. He also describes what he might have learned about the tools, or struggled with in applying them.]

“Very good. So what sources of variation or obstacles do you think are preventing you from reaching the target right now?”

[Green Belt describes the current suspects for causes and sources of variation in the process, as well as other issues that may be impeding progress.]

“Which one of those are you addressing now?”

[The Green Belt may well still be working on the last one, or might have it effectively controlled and is now addressing a new one. If he has moved on to a new one, the Black Belt is going to be especially interested in the control mechanism for the sources of variation that has been “eliminated” so it stays that way.]

For example, a follow-up question might be “Can you tell me how you are controlling that? What countermeasures do you have to detect if that variation comes back into play?”

We aren’t limited to SPC of course, and actually would rather have a binary yes/no  need-to-act/don’t-need-to-act signal of some kind.

What we are going here is iterating through sources of variation, and establishing a positive Control on each of them before moving on rather than trying to stabilize everything in one step at the end.

Once he is satisfied that the project team hasn’t “left fire behind them,” then the Black Belt can move on.

“Great. Can you tell me the next step you plan to take, or experiment you’re going to run?”

[Green Belt reviews the next action to either learn more about a source of variation or attempt to keep it controlled.]

“And what result do you expect?”

[If the Green Belt is proposing using a specific Six Sigma statistical cool, the Black Belt is going to be carefully listening, and asking follow-on questions to confirm that the Green Belt understands the tool’s function and limitations, how he plans to use it, what he expects to learn as a result, and why he thinks that specific tool will give him the answers he is looking for.]

“OK, when do you think we can review what you have learned from taking that step”

This interaction is using the Coaching Kata script to develop the Six Sigma skills of the Green Belt project leader. We already have a coaching relationship, so all we are doing here is practicing a technique to make it more effective and more structured.

DMAIC is now more like:

DM [repeat AIC as necessary]

as the team works methodically through the sources of variation as they are uncovered.

The Master Black Belt

At the next level up is typically a Master Black Belt who is generally responsible for mentoring and developing the Black Belts. They typically meet weekly or monthly and review and share progress on projects.

Only now, let’s shift the discussion to reviewing and sharing progress on developing the problem analysis and solving skills of the Green Belts. Remember, the Green Belts are line management, and we want to get them thinking this way about everything.

“Lets review your learning objective for your Green Belt last week.”

“What did he do? What did you expect him to learn?”

“What did he actually learn? Did he make any mistakes?”

“Is he stuck anywhere? What is your plan to give him additional coaching or instruction?”

In other words, they are following DMAIC as well. Except that the “problem” is the skill of the Green Belt and how effectively he is applying that skill to solve his chartered problem.

 

I am really interested in hearing from Six Sigma folks out there about how this resonates, or doesn’t, with you.

————

*Sometimes I observed a Black Belt doing the same thing on his own initiative, leading the project himself. Occasionally I saw a Black Belt acting solo. I am not discussing either of those approaches here, however.

Posted on

Toyota Kata: Obstacles Are Not Action Items

Continuing my observations about old patterns that get in people’s way as they try to practice Toyota Kata…

“What obstacles do you think are preventing you from reaching the target?” (I also like to insert the word “now” in there sometimes to emphasize what I am writing about here.)

The intent (and to be clear, as I am interpreting it) here is for the improver / learner to give some thought to the things that have to change before the target condition can be reached.

It is not a list of stuff to do.

I am speculating here, but I suspect that there is a legacy from (mis)use of “Kaizen Newspapers” since, in actual practice, they often look similar to obstacle lists. (I believe the original intent of the “Kaizen Newspaper” was to function more like the Toyota Kata PDCA record, but that’s a topic for another post.)

Remember that there are two routines defined in “Toyota Kata,” the Improvement Kata and the Coaching Kata.

The Improvement Kata has four major steps, and the “five questions” that get the popular attention are actually part of the Coaching Kata.

Yes, it is the Coaching Kata that managers actually have to learn, but to be any good at it they (hopefully you!) need to fully understand the improvement kata so they can effectively coach a poor answer to one of the questions into a good answer. Without that baseline skill, the “5 questions” exercise turns into asking the question, waiting for the other person’s lips to stop moving, ask the next question. Doesn’t work (which is why I didn’t say “learner” – because no one is learning in this scenario).

Once the target condition is established, the improver / learner should then set back to the perspective of the current condition and assess what is keeping her from just moving directly to the target.

With all of that as an introduction, let’s look at Obstacles in context.

This is Mike Rother’s schematic of the Improvement Kata from the Improvement Kata Handbook (<– click on the link to download it from his web site).

image

In this model, “obstacles” are the things in the way of getting to the target condition. Saying the same thing, with more emphasis, “obstacles” are only the things in the way of getting to the next target condition.

But obstacles are not action items.

Obstacles are the issues, problems, etc. that you (as the improver) see at the moment. They are based on your current understanding of the current condition.

As you progress by running your experiments, or gaining more information, you are changing your understanding of the current condition.

That is why we ask “What is the actual condition now?” rather than “What was the condition you started from.

The current condition is just that. (Which is why, as a coach, you should insist that your improver / learner keep the current condition up to date.)

As your understanding changes, your view of what might, or might not, be an obstacle changes.

Obstacles are sometimes rendered irrelevant. You might have eliminated a troublesome process step entirely. Or solving one problem might have done “collateral damage” and taken out a couple of others.

As you advance your knowledge, you will likely change your understanding of the obstacles, reword them, clarify them, edit them. New ones might come into view (for the moment).

“What did you learn?” is often at least partially answered by pointing out changes in the obstacle list.

Obstacles are not action items because it is unlikely you will have to deal with all of them.

So… don’t worry about getting the obstacle list “right.” It’s just a reflection of your current understanding which can, and should change as you go.

Posted on

Where Toyota Kata Doesn’t Work

image

I’ll admit right up front that the headline is worded to attract search engines.

If that’s how you got here, be prepared to think.

Can You Prove That This Works

This is something I hear a lot:

“I can see where _____ applies to your example. But my process is __(different somehow) ___.

Fill in the blanks.

Other versions are:

  • “I can see how that works in manufacturing, but ____.
  • “How does this apply to _____?”
  • “Can you show me examples in (something that is an exact match to what I do)?

Anyone in the business of process improvement has heard versions of this excuse for years. It always comes up. “I can see how that works for cars, but we make ____.” is an older version.

One of my favorites came via a friend working with a Japanese supplier to Boeing. They told him “We can see how this would work in American culture, but we don’t think it works in Japan.” Yes, we were teaching Japanese management techniques to the Japanese, and they were telling us it doesn’t work in Japan.

So… this style of “Prove to me that this applies to my specific situation” is something we’ve all heard again and again.

Science

If you manage to read all the way to the bottom, you will see that I readily concede that I cannot prove that “Toyota Kata” or learning problem solving based on scientific thinking works to improve any process out there.

To be able to prove that, I would need knowledge of all processes, past, present and future, and have to make the case that, in each and every one of them, I have indeed established that it works.

What I do have is personal knowledge of application in a very diverse circumstances, which adds to the collective experience of thousands of people who are working to apply these methods and principles. So far, we haven’t found that case where it can’t work. We might someday, but haven’t yet.

The assertion that this thinking is universal is a refutable hypothesis. You can, with some effort, establish rigorous proof, through repeatable experimentation or direct observation of a counter-case that my theory needs modification.

But before we get to that part (at the end), let’s go through some more common instances of this line of thinking.

The Instance of Product Development

Here are a couple of things to think about.

Let me ask, “How do you do product development?”

Typically (HOPEFULLY!) I’ll get some version of:

  • Understand what we are trying to achieve – performance specifications, customer needs, etc. that today’s product cannot provide.
  • Assess the baseline capability and identify gaps between what we need to do, and what we can do with technology, manufacturing capability, etc.
  • Based on that, establish the first, or next, of what are likely a series of intermediate goals converging on the requirement.
  • Iterate through cycles of trials, tests, experiments, learning, etc. to converge on a design that meets the requirements.

Now, to be clear, there are LOTS of variations on this, and lots of ways to manage the execution of this thought process. Some are dramatically more effective than others, but at the core there is a rigorous application of the scientific method.

What is the alternative? Guess at something, build it, and hope it works? Even that approach is going to (hopefully) have you going back and assessing what you learned when it doesn’t work.

So what, exactly, is it about the methodology we are teaching with Toyota Kata that is any different from the above?

  • Understand the challenge and direction.
  • Grasp the current condition.
  • Establish the next target condition.
  • Iterate from the current condition toward the target condition using a rigorous scientific approach that drives learning.

Why wouldn’t you want to apply that method to R&D? What do you do, if you don’t do this?

And, to be even more clear, I think I can make the case that all of the exotic product development methodologies – “Production Preparation Process (3P),” “Agile” and it’s cousins, “Lean Start Up,” “Design for Six Sigma,” “Set Based Concurrent Engineering,” all of them, are simply methods to cycle through the this learning process faster, cheaper, and more robustly.

Toyota Kata is nothing more than a tool to teach the thought pattern. Don’t lose sight of that.

Here’s the kicker. What we are doing, in reality, is working hard to figure out how to apply robust product development thinking to production processes, not the other way around. This stuff started in R&D. The Wright brothers used this process between 1899 and 1903 and beyond to the first practical airplane in 1908. Wilbur’s diaries and letters are essentially a PDCA cycles record.

Scientific Process Engineering

In spite of the little rant above, most engineers take a lot of care to design the product. They study and understand the details of its function, and carefully make modifications in a controlled way so they can test the effects of what they are doing.

On the other hand, it is relatively rare to see the same rigor applied to designing the production process. Many times it is allowed to come together ad-hoc. There is often deep understanding of the core value-adding process steps – how to do machining, welding, painting, etc. But the design and management of the movement of material and information from one process step to the next? Not so much.

Why wouldn’t you want to learn how to apply the same rigor in designing the production system that you apply to designing the product itself?

What is the alternative? Actually I know what the alternative is. Set financially derived metrics, and a high-stakes rewards system for hitting them. Then leave it to managers to figure out on their own. While you’re at it, divide the system into functional areas and set those managers up to compete with each other’s performance. It is a robust system with a reliable, repeatable outcome. Maybe not the outcome you would seek intentionally, but reliably predictable nonetheless.

So how about giving a thought to applying scientific design principles to your production flows? It can’t make them any worse.

Back to Engineering

In a large engineering department, most of the activity isn’t research and design work that I discussed above. It is production work. The products are drawing changes, bills of material, quotes and estimates, CNC programs, engineering change notices, resolution of production problems. This is all vital engineering work, but it is production.

Each of those products is assembled from components. The “material” might be information, but if you decompose outputs into their constituent components, you see sub-assemblies coming together from smaller bits, and in turn, assembling into the bigger “thing” whatever it is.

This is a factory. It just makes useful information rather than hardware.

The irony is (1) There typically even less attention paid to how things are done, what struggles people have to get the information they should have gotten, but didn’t, etc. then there is in even the worst manufacturing floors. And (2) There is often little realization that even people sharing the same cubicle often are working to different interpretations of the requirement, much less methods of doing the work.

So here’s a question:

Are you (as a manager) expected to improve the lead time, quality of output, productivity… any of those things… in your department?

If the answer is “No” then great. I’m glad to hear that things are working perfectly for you… though you might want to spend more time understanding what people are really dealing with, because “No Problem” is often a BIG problem.

For most, though, the answer is “Yes.” They are expected to deliver some improvement in throughput, quality, productivity, etc. Note that these are all production system measurements. That makes perfect sense, because, as I said, these processes are production.

OK… you’re on the hook to deliver improvement of some kind.

How are you going about improvement in your process?

Indulge me a bit, and let me ask a couple of questions.

  1. What you are trying to achieve with your improvement?
  2. How is your process performing today in comparison to that? Do you know what it is about the process that is driving that current performance?
  3. What are you working toward, right now, as the next step to reach your goal?
  4. What kinds of things are you going to have to fix or change to get there?
  5. Which of them are you working on now?
  6. Can you share a bit about what kind of things you are trying in your improvement effort? How are they working for you?

I realize that Toyota Kata might not apply, but if you are actively working to improve anything, you likely have answers to some form of those questions (hopefully).

Of course, those are a variation on the Toyota Kata coaching questions, aren’t they?

It’s just that we usually don’t ask and answer questions like this explicitly. Maybe the effort would be a little more focused and clear if we did. Because all we are trying to do with Toyota Kata is make the scientific thought process more explicit so it is easier to teach. The idea is to get more people learning and understanding how to think that way, which I believe is generally a good thing. Most people would agree, at least with that last part.

I Still Need A Specific Example

Here’s where I sometimes scratch my head, especially when I get this question from someone with a technical education, and often a graduate degree on top of it.

When you went to those universities, did they teach you with examples that exactly matched the job you are doing today? Likely not. Yet you have figured out how to apply those principles to what you are doing.

In those classes, seminars, case studies, they used problems and examples to help you understand the principles.

Then they expected you to take the specific instance of those principles from the examples they used, turn them into a general case, then figure out how to apply those general principles to a different problem, case, or set of circumstances.

In the end, that is really all they were teaching you: How to figure out how to apply a general principle or theory to a specific case or problem. They likely didn’t accept an exam answer that said “You didn’t show me an exact example of this problem.”

It’s Still Science

I will totally concede that there may well be specific instances where the general principles of scientific thinking wouldn’t work to improve a particular type of process. And in those cases, there is certainly no benefit to working to learn how to apply, and teach, scientific thinking.

I say that because I believe in the scientific method, therefore my assertion that “These principles are universally applicable” is a refutable hypothesis.

I welcome the discovery of a specific case where they don’t apply. But the other side of the scientific method is I cannot prove the non-existence of that case.

If, on the other hand, you can establish that you indeed have the proverbial “Black Swan” on your hands, let’s take a look. The burden, though, is on the person suggesting to refute the hypothesis to provide compelling evidence.

Can you please explain what it is about your specific process that defies application of scientific thinking to understand it better, and improve it? What specific characteristics would a process have that makes it so unique that you are stymied in any attempt to apply what you have been educated and trained to do as a scientist or engineer?

I am really curious, and welcome exploring that together, and perhaps modifying my theory to adapt to any true anomalous situation.

That’s science.

Posted on

Often Skipped: Understand the Challenge and Direction

I’ve been practicing, teaching (and learning) the Toyota Kata for about four years now, and I’m seeing some pervasive patterns that are getting in people’s way of making it work.

The one I’d like to address today is skipping over “Understand the Direction.”

As designed by Mike Rother, the Improvement Kata has four basic steps:

image

Graphic © Mike Rother  (click on the graphic to download the Improvement Kata Handbook)

This fact (that there are four steps) is often lost on beginning practitioners. They tend to associate “Toyota Kata” only with the “Five Questions” of the Coaching Kata, which guide Step 4 (above). On the surface, that is understandable, because we hear the coaching cycles a lot more frequently, and they are a hallmark of the kata principle.

But we (hopefully) wouldn’t think of jumping right into the Five Questions until the answer to “What is your target condition?” is something more definitive than “To improve this process.”  (We only used to do that, right? hmmm.)

One of the reasons to set a clear target condition is to get away from general “waste safari” improvement efforts, and focus the improver’s attention on what must be done to get to the next level.

Without a sense of direction, it is easy for the improver to see every improvement opportunity (or none of them), and get locked up trying to find a way to fix them all.

It’s frustrating for everyone, because little progress is made, and those improvements that are made have a tough time finding their way to any higher level meaning.

Someone, long ago, pointed out to me that the geometric figure “frustum” seems to have the same Latin root as “frustration.” This is the graphic that comes to mind:

image

Though the concept of a clear target condition is fairly easy to get across, organizations seem to get locked into a cycle of Steps 2, 3 and 4 without ever going back to Step 1, except in the most general terms.

Here’s what I think happens:

When an organization is just getting started, we’ve commonly told them to pick an area to practice, based on quick cycles and other practice criteria, and get to learning the improvement kata, striving toward a general challenge like one-by-one flow.

That pattern of seeking improvement opportunities gets engrained, and it is hard to shift off it and start to set clear direction and challenges. Further, it is very similar to the “old way” of planning kaizen events where the goal is to “implement lean tools” … like one-by-one flow.

Setting that direction also seems to run counter to the idea of empowered workers are in the best position to know what to work on. (It doesn’t, in fact direction is required for this to really take hold.)

In another sense, though, the Challenge for one level is, in reality, the Target Condition (or at least a major obstacle) for the level above. If I am asking the VP-Operations what his target condition is, I am going to hear things that sound a whole lot like a Challenge for the next level down.

And if the senior leaders don’t have a clear sense of where they are trying to take the organization next… what is their scope of their responsibility?

What to do differently?

(It might help if the leadership team themselves got a coach.)

1) Be clear that your initial sessions are practice drills. You are not yet playing the game, or even a scrimmage. You are flipping tires. Be conscious that this is a transitory learning stage.

2) Establish a target condition for proficiency you are striving for in your practice. Check it weekly against your current condition. This is the job of the advance / steering team.

Challenge Light

For the first pass, it isn’t necessary to dig headlong into hoshin planning, and in many cases, you can issue a compelling challenge with a theme.

Look at what is bugging your customers about your current operation, and challenge yourself to fix it.

For example, one client had lead times and response times that were getting longer and longer, so the challenges issued by the leadership team revolved around lead time and removing “sources of delay.”

Another company had rework and quality escapes going out of control. Their first step was to “grasp the current condition” and identify where these problems were happening.

image

Each dot represents the origin of a defect or rework. (The colors don’t mean anything, they ran out of red, then orange, then yellow dots.) (You can see exit cycle run charts taped up there as well.)

This gave them a quick picture of where to focus their attention, and which leaders they needed to challenge, and then coach, through the process of improving their quality.

Note that for these guys, integrating the flow of material and information though the plant isn’t a target condition, or even a challenge yet. It is in the vision, but the first priority is simply to ship what the customer ordered, and then to only make the product once to do so.

By the way, profit is measurably up, rework instances have been cut by about 3/4 from the starting point, and they are well on their way.

Posted on

Competence and Clarity: Toyota Kata at Sea

A friend, and reader, Craig sent a really interesting email:

As I was practicing the coaching Kata with one of the First Mates on the factory trawler, whenever an issue arose (usually with the leader blaming an employee) he began asking factory and engineering leadership “what needed to be communicated?” or “what needed to be taught?” He found it encompassed every problem on the vessel and I loved that he made it his own and communicated in manner to which lifetime fishermen could relate.

What I found really cool about this is how it is exactly the same conclusion reached by David Marquet, both in the sketchcast video I posted earlier, and the titles of two chapters in his book. The reasons leaders feel they must withhold authority, remain “in control” ultimately come down to competence – what must people be taught, or clarity – what have we failed to adequately communicate. Maybe it’s being at sea.

In other words, if people know whGiveControl.pngat to do (clarity), and know how to do it (competence), then leaders generally have no issues trusting that the right people will do the right things the right way.

The Improvement Kata  is a great structure for creating and carrying out development plans for leaders (or future leaders) in your organization.

The Coaching Kata is a great way to structure your next conversation to (1) ensure clarity of intent: Does their target condition align with the direction and challenge? and (2) develop their competence, both in improving / problem solving, but also in their understanding of the domain of work at hand.

 

 

 

Posted on

Toyota Kata “A3 Problem Solving”

Over the years, I’ve been exposed a number of efforts to “implement A3 problem solving” in various companies. I worked for some of those companies, I’ve observed others.

The results are nearly always the same.

Here are a couple of examples. Let me know if any of these match up with experiences you have had.

Example 1: The company had put many people through “Practical Problem Solving” training and was (ironically) trying to measure how many problem solving efforts were underway.

I was watching a presentation by one of these problem solving teams to management. Their A3 was on a computer, projected onto the screen. They were reporting their “results.” Yet there were large discontinuities in their problem solving flow. The actions they were taking simply did not link back (through any kind of identifiable cause) to the problem they were solving.

The management team listened carefully, applauded their efforts, and moved on to the next topic of their meeting.

Example 2: A different company had a form to fill out called an “MBF” or “Management by Fact.” From the labels on the boxes, it was clearly intended to be structured problem solving. By the time I worked there, however, “MBF” had become a verb. It was a solo activity, filling out the form at the desk, and reporting on it in a staff meeting.

Example 3: Well-meaning former Toyota team members, now working for a different large company wanted to “train everyone in problem solving.” They put together a “class” that presented the purpose of each block on their A3 form with the expectation that people would adopt the process.

All of these efforts had something in common.

They didn’t work.

Over the last few days, I’ve been privileged to be included in an email exchange about the relationship between A3 and Mike Rother’s Toyota Kata. My small contribution was apparently enough to get my name onto the cover, but I want to give a real nod in the direction of a Jenny Snow-Boscolo for instigating inspiring a really good exchange.

The result is here. I think this presentation does a really good job of summing up the relationship between Toyota Kata and Toyota A3. Thanks to Mike Rother for taking the initiative and putting it all together (more below)

One of the difficulties with gaining insight into Toyota’s management processes is that they really aren’t codified. This shouldn’t be a surprise. Look at your own company, and ask how much of the culture – the reflexive way things are done and interactions are structured – is written down.

(In fact, if it is written down, I would contend it is likely your actual culture has little resemblance to what is written about it. Those things tend to be more about what they wish the culture was.)

Culture, any culture, is learned through daily interaction. This is all well and good in cases where people are immersed in it from the beginning.

But the rest of us aren’t operating in that problem solving culture. Rather, we are trying to create it. And as the former Toyota Team Members from Example 3 (above) learned, it isn’t a simple matter of showing people.

Rather than two different things, we are looking at a continuum here. At one end is the culture described on Slide 9. There isn’t any formal structure to it, the process for teaching it isn’t codified. It is learned the same way you learn the way to get the job done in any company. They just learn different things than you did.

But in another organization there is no immersion. If there is anyone who is steeped in The Way, they are few and far between.

In these cases, we want to start with something more overt. And that is the purpose of having a rote drill or kata. It isn’t something you implement. It is a structure, or scaffold, to learn the basic moves. Just as mastering the musical scales is only a prelude to learning to play the instrument, the kata is the foundational structure for learning to apply the underlying thinking patterns.

So… if you are working on kata, it is critical that you are reflecting on your thinking patterns as much (or more) than you are reflecting on your improvements. It might seem rote and even busywork at first. But it is there to build a foundation.

Posted on

Mike Rother Overview of Toyota Kata

This is a 5 minute edit of the presentation Mike Rother made at the UK Lean summit.

It is a succinct summary of interaction between a coach (leader) and learner (someone working on improving a process).

My thoughts are below the video…

OK – here are some things I have learned with these methods “in the wild.”

Most organizations I have been working with can’t take on 1-3 year challenges and stay the course for that duration. The horizons are too far for them to see what is possible within that kind of time frame and stay the course.

I have been trying 3-4 month time horizons for initial challenges in organizations where everyone is learning the basics at all levels. That gives them an opportunity to practice with a horizon that is less likely to be derailed by a sudden change in direction during that time. Eventually, as they develop capability, they can extend the time horizon and morph these practice challenges into something more formal, linked to the business plan.

Middle managers like to leap onto the coaching questions much too early – before they are capable of actually coaching. The coaching questions are seductive because they are written down and structured.

The PDCA process is much more nuanced, but it must be mastered before attempting to coach. Why? Because the coaching process is application of PDCA toward the learner’s development.

While it is OK to round-robin coaching and actual process improvement, everyone has to work together to reflect and learn.

In addition, those middle managers tend to try to leap into coaching before they have an internally set non-negotiable sense of “True North” – driving toward better and better flow.

When a middle manager is taking on the role of the “learner” there is a great temptation for him to delegate tasks to others, and get reports. This is status quo, and does nothing at all to develop capability.

Like everything else we do in the West, or at least in the USA, we try to get there fast by skipping the basics.

Make no mistake – you don’t “implement Toyota Kata.”

You use it as a structure to build foundational capability and new thinking patterns.

Those patterns are only developed through practice, and deliberate reflection on the management process itself.

I have also seen an organization that is “getting it” pretty quickly. The difference is that they are all overtly in “we are just learning this” mode, and willing to make mistakes and learn from them vs. trying to appear to be competent from the get-go.

Mike Rother has other videos on YouTube as 734Mike.

Posted on

TSA Kata

Robert Heinlein observed (through the HOLMES IV computer character in The Moon is a Harsh Mistress) that “humor” often centers around the misfortune of others. I’ll make this little story topical by hypothetically applying the “coaching kata”…

This wasn’t me, just something I witnessed. If only people would apply PDCA to real life… If I were coaching this guy, it might go something like this:

“What is your target condition?”

“To get to the gate for my flight.”

“What is your current condition now?

“In the TSA security checkpoint.”

“What obstacle are you addressing?

“The TSA wants to do a secondary screen on me, delaying my passage through the checkpoint.”

“What was your last experiment?”

“I raised my voice and became indignant, accusing them of not knowing what they were doing.”

“What result did you expect?”

“That they would understand they were wrong, and let me pass.”

“What actually happened?”

“A lot more TSA agents showed up, along with a police officer.”

“What did you learn?”

I think the trajectory is pretty clear from this point…

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…