But according to this article on Time’s “Time Ideas” site by Anne Murphy Paul titled “ Why Floundering is Good,” that isn’t the best way to teach.

In fact, it can hinder learning.

The key point is summarized at the end:

… we need to “design [teaching] for productive failure” by building it into the learning process. Kapur has identified three conditions that promote this kind of beneficial struggle. First, choose problems to work on that “challenge but do not frustrate.” Second, provide learners with opportunities to explain and elaborate on what they’re doing. Third, give learners the chance to compare and contrast good and bad solutions to the problems.

Right now we are (hopefully) in the midst of a paradigm shift in how lean practitioners and teachers go about what we do.

Traditionally, a lot of us have simply given people the answers, or at least strong suggestions. Given the time constraints and overly ambitious targets of a typical 5 day event, that is understandable.

But now we are starting to see these events as skill building, which means learning, which means the teams need time to muddle through.

I have been structuring my approach quite differently for about a year now. I’ll be the first to admit that I, too, am figuring it out, reinforcing what works well, altering what needs to work better. These days I am far more comfortable letting things move through this struggle in order to set up deeper understanding once the light does come on.

The trick is to let them fail small, and not let them fail big. The problem has to have a solution that is within reach, or they will only come away frustrated.

Thus, teaching is becoming a matter of judging the knowledge and skill threshold and making sure they don’t take on too much at once. That is part of respect for people.

One problem at a time. Single factor experiments.

A great deal of the power in the “ Coaching Kata” is turning out to be the question “Which *one* [obstacle] are you addressing now?” as it rules out working on everything at once.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Struggling to Learn

• 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.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Toyota Kata Seminar, Day3

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 listen to the presentation. (Yes, it has a sound track, to be sure to hit the “Play” arrow rather than just flipping through the slides.)

Note: Some browsers (Firefox?) have had problems loading from the embedded link. If that happens to you, here is the direct URL:  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) has not been as clear in Rother’s work up to this point.

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.

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.

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 or 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.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Bill Costantino: Toyota Kata “Unified Field Theory”

The most common approach is some kind of database (either online or on paper) that documents the various “best practices” solutions to various problems.

They might, for example, show the before and after of the development of a work cell, how their visual controls are set up, or a particularly clever tool or gadget they developed.

Perhaps not so surprisingly, these bits of information turn out to be far less useful than people think they should be.

Why is that?

Let’s back up a bit and look at a larger scale.

Toyota, and other companies that are doing these things well, have all been pretty open about letting people come on and see what they are doing.

Other companies seeking to benchmark these companies then want to find one that faces similar types of problems, say “low-mix / high-volume production” or similar process flows.

Our community has developed a sense of what a “lean system” looks like. We express it in terms of the solutions to problems that have been developed.

Work cells.

Kanban.

Clever tools or gadgets.

But we also (hopefully) know that seeing examples of these things with the intent of copying them doesn’t really help that much.

Oh, they can be copied… but the track record for sustaining is pretty poor.

Nope, we know (again, hopefully) that it is not about the solutions, but about the process of solving the problem. In other words, it is the method used to develop the solutions that is important to grasp. Seeing the solutions after the fact actually gives very little insight into how to develop the skills required to do it yourself, or sustain it yourself.

OK, back to the original topic.

IF we know that copying another company’s solutions doesn’t work very well, and that we need to instead get a grasp of the thinking process that resulted in those solutions, then what should we be sharing internally, and how should we be sharing it?

The classic way to share is with a single page that says “Before Kaizen” on one side, and “After Kaizen” on the other. There might be a space for “problem” but when it is filled in, the words are usually pretty superficial. 85% of the space is devoted to a couple of pictures.

Even if it does state the problem clearly, it still doesn’t get into the process used to solve the problem.

Nor does it get into what was learned about the process of solving problems.

Now… before you leap in and say “Sure, that is what an A3 is for!” I will agree with you. Except that unless an A3 is written with that specific purpose in mind, most of the ones I have seen tend to do little better than the Before-and-After pages. Or they are so full of charts and graphs that they are really impossible to follow.

In other words, they are too complicated to convey the message, because the intended message wasn’t clear when they were developed..

It really comes down to intent.

If you are trying to share, be crystal clear on what you are sharing. What are you trying to communicate?

I believe it would be far more valuable to depict where your problem-solving process was faulty, what mistakes you made, where you went back and corrected yourself, and what you want to pass along about problem solving.

That would be a far more useful for the next person to come along.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

What Are You Sharing? What Are You Learning?

Limitations are challenged, possibilities are expanded.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

3P Works

In my company we are working with the developing people concept. Our objective is to make ourselves redundant, but it is hard. What are the best ways of developing people? How do you do it?

How do you do it indeed?

I don’t know the specific situation he is facing, but I can ask some questions that are pretty universal.

What, exactly, are you striving to achieve with your people development? What do you want people to be able to do that they are not doing now? What would that look like if you were to observe it? How would they be interacting with the process, with each other?

If you observe today, what do you actually see? How does that differ from what you described above?

What is the gap between what you want and what you have?

I ask these questions because often we talk about “developing people” but we don’t get specific about what we expect as a result. It is easy to set objectives for kaizen of processes, quality, output, cycle time, etc. But when we talk about people, we get squishy about it.

But the process of improvement remains the same, no matter what (or who) you are trying to improve. And the first step is to know two things:

• The direction you are trying to move – the ideal, the True North.
• The next target you are trying to hit now which will move you in that direction.
• When you expect to be there.

Once you have that, it is time to take a look at what you are actually doing and ask how, exactly, that effort is expected to advance you toward your target.

If the answer to that question is not crystal clear, it is time to step back and reassess your approach. Likely your approach is general and broad-brushed, rather than focused.

What never works is telling people about improvement and expecting them to get excited enough by that message to fill in the details on their own. The idea that “once they grasp the true vision they will engage on their own” is a common one.

But consider this analogy. We all know that mathematics is a wonderful tool. I can tell you all about the great discoveries and engineering feats that mastery of mathematics has enabled. I can show you dozens of examples, even take you through demonstrations of how others have used mathematics to solve problems.

At the end, you might be fired up about math, but you still can’t do it. I may have motivated, but I have not developed anyone.

If I want you to actually use mathematics, I have to assess where their current skills are, establish the next step for them, and construct a situation where they must practice and struggle a bit, but not too much, to “get” the next understanding.

That is called “practice.”

So – back to the original question.

You want to develop people.

What are you having them practice for a little while every day?

How are you providing them immediate feedback on success or failure, and coaching them?

How are you checking your results against the results you intend? What are you doing to develop and improve your own process of people development?

PDCA

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

People Kaizen

Outside consultants (some style themselves as “sensei”) can be a good way to bootstrap this process by bringing in existing experience so you can develop your own more quickly. (Full disclosure here – Right now I am one of those consultants, though I have played on both sides of the game and learned a lot from others.)

But it is important to use them the right way.

The way that doesn’t work is to bring in an outside consultant to lead improvement for you. Typically this means that the company assembles a working team, delegates the improvement to that team, and hires a consultant to lead them.

Once the event or activity is over, it might be repeated again with a different group of people, on a different project, even with a different consultant.

Though this can be somewhat effective at dealing with individual issues, the company’s capability to do this themselves is never developed.

Learning might occur within the company, but it will be a random event.

On the other hand, if the client company puts together a team that has an internally designated leader, and that leader is also charged with capturing knowledge, and there is some continuity from one event to the next, then a working relationship develops.

In my opinion, this is a legitimate role of a Kaizen Promotion Office, and is likely why a lot of consultants (at least the ones with the clout to impose conditions on their clients) insist on the company forming one.

The people in the KPO have two roles.

• To capture and internalize the cutting edge of skill and knowledge for the company.
• To practice that skill and knowledge by teaching others.

I have personally experienced both situations – where I am asked to be a substitute leader, and where I have the opportunity to develop people in the company. I can tell you that the later is a lot more fun, and the former is mostly frustrating.

I also see a difference in follow-up. Where there is no internal leadership, it is much tougher for the team to stay on the game and push the changes to a point where they are ingrained and sustain.

If you are interested in some expanded thoughts on this topic, I invite you to read the white paper “ Getting the Most From Lean Consultants” on the “ Resources Page.”

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Internalizing Outside Knowledge

Every coach in the world gives some form of this advice to her students. This is true for athletics, for music, for any skill we are trying to develop.

Yet when planning kaizen events, we tend to forgo this advice, and push the team to produce huge “results” for the Friday report-out.

Getting those results is actually pretty easy. Any facilitator with a little bit of experience with the tools can push the team to rearrange a layout, get some basic flow, and turn in some really good numbers in a few days.

But what skills has the team developed in this process?

Maybe how to see a similar opportunity and copy the layout there.

Maybe how to close out an action item list, but that is still just rote implementation.

What processes and systems have to be in place to sustain those results? What skills are needed to use those processes and systems effectively. When, during the course of these five days, did your team practice those skills, or for that matter, even learn what they need to learn?

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Learning Kaizen

The most visible characteristic of 3P, the Production Preparation Process, is the idea of creating quick and dirty mock-ups of the product and the process. These mockups are often constructed of wood, cardboard, PVC pipe – materials at hand.

The idea is to be able to quickly and cheaply try out, and experience, a process (or product) so that problems can be surfaced, opportunities for improvement can be seen, and the PDCA cycle can be turned far more rapidly than would otherwise be possible.

The purpose of the mockup is to create a gemba of sorts, where you would not otherwise have one. Now, rather than doing an abstract analysis, you have something that people can see, touch, and interact with. Doing so forces details to the surface that are simply invisible in abstract models in computers or on paper.

Some companies use the process to design their products as well as the processes that are used to manufacture them.

Last week one of my clients took their first steps into this process. The photo above has been pixelated so as not to reveal details about their product design.

They had done pretty extensive analysis using traditional industrial engineering methods, and had a CAD drawing of the proposed layout. That was the starting point.

The first step, then was to create that layout in real-size. That took the team about 90 minutes.

They assembled some tables, got some boxes and cardboard, and represented the machines, the work positions, the material and people flow.

Even as they were doing this, some of the team members saw things that they questioned, such as an ergonomically awkward operation. Others simply had questions. Why? Because in translating the drawing into the real world, even a superficial one, details already had to be resolved.

Once they had the starting condition mocked up, the team took prototype parts of the product and went through the motions of a team member trying to assemble it.

This felt a little awkward at first, but they began to see more opportunities, and resolve more detail.

We did a little coaching, pointing out motions that could be eliminated, others that could be consolidated. We talked about the smooth flow of people’s work, and looked for opportunities to better match the work flows to the takt time.

In the next couple of hours the team went through dozens of small PDCA cycles, each time adding a little more detail, adding a physical control, or a visual control. They found “knacks” that enabled quicker assembly with less adjustment.

They identified exactly how and where parts should be presented to the assembler.

They discovered small design and packaging changes that could make a big difference in the assembly time and quality. It did not hurt that the design engineer was trying to work out the details of one of the more awkward elements of the assembly.

They found key points that were critical to quality, examined the vulnerability to simple mistakes, and worked on how to make those more clear.

They identified characteristics that would help the machines better support the work flow. How do parts move in, move out? Where do the hands go to start the machine? How does the location of the controls support (or hinder) the work steps that come before and after?

As they looked at test operations, they started working out what they wanted to happen when there was a problem. They started to work out a line stop protocol and added andons to those machines, so they could signal an abnormal result.

Curious visitors, some senior managers, others just happening by and wondering what was going on, were enlisted as test subjects. Is the work cycle simple and clear? Is it easy to teach? Is the layout intuitive?

What can we do to make the visuals more clear, and to lay things out to guide the correct process sequence? Which “knacks” have to be taught? How quickly can a “new operator” be brought up to speed and make the takt time?

Over three days, the details came into sharper and sharper focus.

In the end, the team had constructed a full size model of their target condition. They are clear how the process needs to operate to give them the performance they want; and they are equally clear about the next problems that must be solved to get there.

They can specify their equipment with far more insight, and many of the details of how to guide the product and people through the process are now much better understood.

And, as a side benefit, this cross functional team has communicated far more than they would have otherwise with meetings and email. They have spent three days embedded in a joint project to envision what they want this to look like.

To be clear, a lot of work remains, and many more details remain to be worked out. But over three days this team now has a much more clearly aligned concept of what they are striving to achieve.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Rapid PDCA with 3P

The key point is that people learn what they practice. And if you practice kaizen every day, you learn kaizen. But if you practice something else every day, you learn that. If kaizen is only an occasional “special event” then it never becomes engrained as “the way we do things.”

From the article:

The truth is, when everybody practices status quo behavior almost every day,that is what is sustained. If employees are not practicing the new way every day, by default they are practicing the old. Practice makes permanent.

Mike illustrates this principle well in his presentation Introduction to the Improvement Kata.

In reality, rather than days between events, the experience of the team members is more often like weeks or months. Some companies set a goal of getting every team member through one or two kaizen events in a year.

While this may spread the effect wide, it ensures that nobody has more than superficial experience. It is build on an expectation that once a process is “leaned out” that it should stay that way until there is an opportunity to come back around and “fix it again.”

Of course it actually begins to erode right away because the daily habits have not changed, and it is those daily habits that put the waste into the process to begin with.

The traditional model for kaizen is firmly anchored in Fredrick Taylor’s concept of separating experts from workers. Even though we solicit worker’s input during kaizen events, the process of kaizen itself is still largely the domain of technical experts. They are the ones who own the process.

Some companies go so far as to not allow kaizen to be done by people who are not “certified” in some way.

What we have to do is shift the role of those kaizen experts from one where they plan, conduct and lead special improvement events to one where they are on the shop floor every day teaching and coaching the line leaders. This is the only way (that we know of) that will actually transfer the knowledge.

Only when those line leaders are, themselves, teaching and coaching can the effort let up a bit and move on.

The “ship may be turning” because this idea is beginning to find its way into the mainstream discussion in the lean community. This will not happen overnight, however. There is huge inertia in the expert-as-implementer mode across all approaches to improvement. But if we (the lean practitioners) want to know why the results do not sustain, a large part of the answer is in the mirror.

“If the worker hasn’t learned, the teacher hasn’t taught.”

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

What Do You Teach and Practice Every Day?