KataCon 2017: Day 0

KataCon officially starts tomorrow as I write this but today was a couple of pre-events and I learned a few things worth sharing. These are from my notes.

Common failure modes for continuous improvement / kata:

Note that these titles and words are not necessarily what I heard in the presentation. They are my notes and interpretations, along with my own similar experiences.

Resistance from a support organization.

The presenter talked about a case where a manager was having great success applying the Toyota Kata thinking pattern, and improving quality in the process. However the corporate quality department didn’t see the records, paperwork, etc. in the format they expected and caused a lot of problems.

I have actually seen this myself in the case of a factory in a multi-plant company. A plant manager figured out good flow pretty much on his own and got there without kaizen events, and without the direct participation from the corporate “lean promotion office.” Very senior people from the LPO engaged in a subtle (and not subtle) campaign to discredit the success. Ultimately the plant manager ended up leaving the company for elsewhere.

In another case I counseled a local C.I. manager in a larger company to “make what you are doing look like what the corporate C.I. office expects to see.” By renaming some forms and using their jargon to describe what he was doing (even though it was a little different), he was able to protect his approach.

SHOULD anyone have to do this? NO!!! But sometimes it is necessary.

Key Point: Understand the political environment and develop countermeasures just like you would for any other obstacle. It doesn’t help to get made about it. Just deal with it.

Consultant as Surrogate Leader

In this “Fail” the external consultant was chartered to provide coaching to a couple of junior-level managers by the owner of the company who did not participate. Needless to say this can result in political problems as well, especially for the managers being trained when they start doing things differently than what the owner is used to seeing. (What did he think was going to happen?) Again: If you are a practitioner / consultant (internal OR external) be aware of this kind of situation.

Spotlight Showed Problems

The improvement effort begins with a deep look at the current condition. This inevitably makes issues visible that were previously hidden. Again, if the culture / politics of the organization are not friendly to revealing problems, the ground work needs to be laid first.

The Guru Model

The “Guru Model” is pretty common – actually relates to everything above, especially the first topic. If you are working on developing these skills in the line leadership, it can dilute the status of the experts – who may or may not be as truly competent as they claim. We are seeing a shift away from a model of doing what the expert tells us to, and toward a model of learning to figure it out ourselves. The second model is far more flexible and works in almost any situation. We need to let go of the idea of seeking “the answers” from Gurus, and embrace that we need to learn how to figure them out.

“Doing Lean” with a challenge of “Getting Lean”

Don’t be a solution in search of a problem. The traditional approach has been to have “lean program” that pushes deploying tools and models that resemble a snapshot of a benchmark company such as Toyota. That implementation becomes an end unto itself. In the example discussed, the target company was doing fine in the eyes of its owner, but the consultant was trying to sell him on “lean” to “eliminate waste.” Even if there is a lot of possible upside, if the owner isn’t feeling the need to do something different, you are probably not going to get very far.

Note: If you are an internal practitioner, it is even harder. Ultimately it is managements job to set a performance challenge for the organization that can’t be met by tweaking the status-quo. “The challenge is often challenge” came up a number of times – organizations are typically pretty bad at establishing challenges that actually… challenge anything.

The Value of a “Model Line” as a “Demonstration of the Power”

This was an interesting discussion. Traditional thinking, for decades, has been that those who want to implement a change find a single area to transform in order to demonstrate what is possible. The idea is that once management sees the power, they will want to spread the same approach across the organization.

This effort could be taken on by an outside consultant, such as an MEP, or even an internal centralized improvement office (which may technically be “internal consultants” but they are “outside” to the other departments in the organization.

In either case, there is a lot of time and effort required, with no real assurance that even dramatic success will be seen in the light intended. My thoughts are there are at least two other equally plausible scenarios:

  • The one I discussed earlier: The success is discounted as an special case that can’t be replicated. This is what happened in the company where the company lean office that was the primary detractor.
  • Possibly worse: Management sees how great it is, and puts together a mass training / deployment plan to standardize the “new process” and rapidly spread it across the organization as a project – an approach that is doomed to fail.

Better, perhaps, to use a simple, short, mass-orientation exercise such as Kata in the Classroom to introduce the concept to as wide an audience as possible. Then see who is interested and help them learn more. You can’t force this stuff upon anyone. Ever.

Other Notes

Developing capability in the organization requires covering both technical and social (people relations, leadership) skills with leaders.

———-

Target conditions and experiments means “you don’t have to boil the ocean or solve world hunger.” My thoughts: I have seen executives reluctant to accept or commit to a challenge because they did not know ahead of time exactly what would be required to reach it. The point of breaking down the challenge into target conditions, and further into obstacles, and addressing obstacles one-by-one makes the challenge seems less overwhelming.

———-

The first group to get training needs to be the senior leaders. They learn by doing on the shop floor: Making actual improvements on actual processes. If the execs aren’t willing to learn, you probably aren’t going to get far. Further notes: This doesn’t mean you can’t do anything without full participation from the top. But you will reach a limit to what is possible.

———-

Kata Ideas vs. “Suggestions” or simply soliciting ideas for improvement. A traditional suggestion program solicits any idea that the team member things might help. When there is a supervisor-as-learner working against a specific obstacle, striving to achieve a specific target condition, the ideas are much more focused.

Supervisor to team: “I’m trying to figure out how to solve this problem. Does anybody have any ideas we can test?” Then test them one by one as experiments.

———-

“Real” scientists often don’t do true “single factor experiments.” They do mess around and try changing things up to see what happens. But if they see something interesting they then go back and run controlled experiments to isolate variables to understand what is happening.

This is totally different than the common approach of implementing a bunch of changes and hoping the problem goes away. If the problem does go away, and you don’t then rigorously investigate why, you have learned little or nothing. Now you are stuck in the position where you can’t risk changing anything at all because you don’t actually know what is important.

——-

Measuring the success of “Toyota Kata”

We emphasize that you don’t “implement Toyota Kata.” Instead, you use the Improvement Kata and the Coaching Kata as practice routines to embed a new way of thinking into the organization’s daily habit of the way things are done.

The key is the thinking pattern that remains and self sustains. In companies that are very advanced, you sometimes see few, if any, “Toyota Kata boards” because the thinking pattern is embedded in every conversation they have.

Just as we say “Lean is NOT about the tools” – it isn’t about the physical artifacts, neither is Toyota Kata.

However (my current thinking) (THIS IS CRITICAL) – the artifacts are what provides the initial structure that lets you get that thinking started, allows people to practice it, and lets you observe how they are doing. My thought: DO NOT TAKE THIS DOWN until you are confident that someone new just joining your organization is going to learn it simply by picking it up from the way people talk to them every day.

These are just raw notes and some thoughts about them. If any of this sparks interest, leave a comment and I can expand on it with a more formal post.

People to Meet at KataCon

KataCon is a couple of weeks out. If you are considering going you are probably looking at the keynote speakers and KataGeekYellowbreakout workshops.

The other reason to attend KataCon is to meet other people and share experiences with them. I’d like to introduce you to two of those people.

imageHal Frohreich is the Chief Operating Officer of Cascade DAFO in Ferndale, Washington. Their product is custom pediatric foot / ankle orthotics that help kids walk. Yup, custom. Every one is different.

Since taking the position, Hal has been using Toyota Kata as a mechanism to develop the leadership and technical skills of the supervisors and, in doing so, make fundamental shifts to the culture of the organization. For you TWI folks, he has also deployed TWI, especially Job Instruction, along side the Toyota Kata for much more consistency in the way work is performed.

 

 

imageHal provides support to his Production Manager, Tim Grigsby. Tim coaches 4-7 kata boards every day and covers diverse areas including people development, I.T. issues, R&D, and production. Tim views his job as seeing that each work team has the time, education, direction, space, tools and help to improve their work. Toyota Kata provides the structure that he uses to help them develop critical thinking and clarity in their target conditions, obstacles, and their PDCA cycles.

Each afternoon the COO and CEO walk the floor and review the target conditions, obstacles and next steps. This helps keep things aligned as well as ensure nobody is “stuck” on a problem that is outside of their scope to fix.

 

I believe, and teach, that Toyota Kata is a mechanism for driving culture change, and this is the philosophy that Hal and Tim have embraced. While the performance of the organization has dramatically improved by every measure you care to ask about, that is not the real result of this work.

The real outcome has been to create a cadre of front-line leaders that are taking initiative and applying creative solutions vs. just getting through the day doing what they are told.

Come to KataCon and find these guys. They are worth talking to.

KataCon 2017 Keynote: Joe Ross

Joseph P. RossLast year I nominated Joe Ross, the CEO of Meritus Health in Hagerstown, MD to be a keynote speaker at the 2017 KataCon. I did so because I think Meritus has a compelling story.

Like many organizations, Meritus had engaged in several years of staff-led improvement focused on events and things like “A3 Training.” And like many organizations, while the individual events seemed successful, the actual long-term traction was limited.

A little over a year ago Meritus started exploring Toyota Kata as a possible way to change the cultural dynamic. The 2017 KataCon will be on the anniversary of our first training session.

In the meantime, Meritus also applied the same thinking to how they did their senior leader rounding, as well as applying the thinking shifting the way the staff interacts with patients and each other.

Joe’s talk will cover these key points and the lessons they have learned along the way.

I hope you will be there to hear his message and meet him as well some of his key people.

image

Learning = Extending the Threshold of Knowledge

“My computer won’t boot.”

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

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

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

Working hypothesis: It’s something on the motherboard.

Start with the simple stuff that challenges the working hypothesis:

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

image

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

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

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

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

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

Done.

The Threshold of Knowledge

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

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

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

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

image

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

But this wouldn’t be the case for everyone.

The Threshold of Knowledge is Subjective

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

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

Coaching To Extend the Threshold of Knowledge

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

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

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

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

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

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

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

General Application

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

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

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

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

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

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

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

_________

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

The Lure of Rapid Lean Transformation

image

Lean In A Box

I can see where the promise of a rapid “lean transformation” is appealing. We shop around, listen to presentations, read proposals, and find someone with a good “solution.”

For the next few weeks, maybe a couple of months, things move in a flurry. Lines are connected, visual inventory controls are established, your team is taught about the lean tools with simulations demonstrating the power of flow. Thus convinced, the team is expected to buy into the changes being made.

At the end, with much hoopla and pizza, we are done, and the new system is running.

The Grass is Greener – For a While

Now let me tell another story. It isn’t my story, I heard it during a presentation by Jim Sorensen in Seattle. I’m sure he tells it much better than I will. Jim talks about his neighbor who has a fantastic, immaculate lawn. Jim recounts that, one day as he was chatting with his neighbor, shared a little envy – “I wish my lawn looked as good as yours.” The neighbor’s response was “Jim, if you had a lawn like mine, in three months it would look like your lawn does now.” His neighbor works on his lawn. The immaculate appearance was important to him. For Jim? He chose to spend his time doing different things, which is fine. But at the same time, he, we, shouldn’t expect an immaculate lawn to stay that way unless we are willing to do the work.

Likewise with these rapid implementations. To continue to metaphor, we rip out your old grass, put down beautiful fresh sod, take the photos, and move on to the next house. But if you don’t fundamentally change the way you maintain that new lawn, by the end of the year, it will look like your old one.

You Are Transforming Your Culture

Continuous improvement as “the way we do things” is a fundamental shift in the way people think, and the way they spend their time. There is no “set it and forget it.” Your processes are either improving or eroding. You must exert continuous active control by the people who are closest to the work just to keep up with the entropy. Their “buy in” is not even close to being enough to make it work. They need different leadership.

Many years ago I was interviewing at a Big Household Name Company that looking to accelerate their “lean deployment.” They already had a guy with incredible qualifications working very hard to teach the things they needed to understand.

Every person that talked to me asked “How can we go faster?” My reply was “Listen to what [your lean director] says and do it. He knows what he is talking about.” Unfortunately, he was telling them that there were no easy shortcuts, and that they had to begin thinking about production in a fundamentally different way. My feeling was they were looking for someone to tell them there was an easier way to do it.

I run into that a lot. An organization wants the results, they want the immaculate lawn, but they want someone else to do the work to make it that way, then they want the outcome.

The problem is you can’t outsource your own thinking.

It’s “What must we learn?” not “What should we do?”

Darren left a great question in the Takt Time-Cycle Time post:

Question… Which system is more efficient, a fixed rigid Takt based production line or a flexible One Piece Flow?

In terms of designing a manual based production line to meet a theoretical forecasted ‘takt time’, (10 fixed workstations needs 10 operators), how do you fluctuate in a seasonal business (+/-25%/month) to ensure you don’t end up over stocking your internal customer?

Would One Piece Flow be more efficient on the whole value chain in this instance due to its flexibility?

That was a few weeks ago. Through its evolution, this post has had four titles, and I don’t think there is a single sentence of the original draft that survived the rewrites.

I started this post with a confident analysis of the problem, and the likely solution. Then I realized something. I don’t know.

My brain, just like every other brain on the planet (human and others) is an incredibly efficient pattern matching machine. I got a little bit of information, and immediately filled in a picture of Darren’s factory and proceeded to work out a course of actions to take, as well as alternatives based on other sets of assumptions.

NO, No, no!

Our Reflex: Jumping to Solution

This graphic is copied from Mike Rother’s presentation material. It is awesome.

image

It is likely that at this point you know that it doesn’t say “JUMPING TO CONCLUSIONS” under the little blue square, and of course you are right.

image

But in spite of the fact that you know the truth, it is likely you still read “JUMPING TO CONCLUSIONS” when you look at the first graphic. I know I do, and I present this all of the time.

Our brains are all wired to do this, it is basic survival. It happens very fast. Think about a time when you have been startled by something you thought you saw, that a few seconds later you realized it was nothing.

That pattern recognition triggered the startle. It was seconds later that your logical brain took over and analyzed what was really going on. This is good. We don’t have time to figure out if that movement in the grass was really a leopard or not. We’ll sort that out after we get away.

Our modern brains work the same way with learned patterns imagebut we are usually very poor at distinguishing between “what we really know” and “what we have filled in with assumptions.”

This is the trap that we “lean experts” (whatever that means) fall into all of the time. We take limited information, extrapolate it into a false full understanding, and deliver a diagnosis and treatment.

Boom. Done. Next?

What’s even worse is we often don’t hang around to see if the solution worked exactly the way we expected, or if anomalies came up.

In other words, everything comes down to takt, flow and pull, right? Kinda, but kinda not.

Some Technical Background

All of the above notwithstanding, it really helps to understand how the mechanics of “lean” tie together to create the physical part of an organic/technical process.

What I mean by “really helps” is this understanding gives you a broad sense of how the mechanics help people learn. Someone who only understands the mechanics as “a set of tools” is committing the gravest sin: Leaving out the people.

One Piece Flow

One piece flow is not inherently efficient. It is easy to have lots of excess capacity, which translates to either overproduction or waiting, and still have one piece flow.

This is the people part: One piece flow makes those imbalances very obvious to the people doing the work so you can do something about them, if you choose to. Many people think the goal is one piece flow. The goal is making sure the people doing the work can see if the flow is going smoothly or not; and give them an opportunity to fix the things that make flow less than smooth.

A pull system is designed to throw overproduction (or under-production) right into your face by stopping your line rather than allowing excess stuff to just pile up. Again, it is a tool to give the people doing the work immediate visibility of something unexpected rather than the delayed reporting of inventory levels in a computer somewhere.

Flexibility

Any given level of capacity has a sweet spot for efficiency. Even “inefficient” systems are most efficient when their capacity (usually defined by a bottleneck somewhere) is at 100% utilization (which rarely happens).

If other process steps are capable of running faster (which is the very definition of a bottleneck), they will, they must either be underutilized or build up work-in-process. This is part of the problem Darren is asking about – flooding his downstream operation with excess WIP to keep his line running efficiently.

If your system is designed to max out at 100 units / day, and you make less than, that your efficiency is reduced. If the next operation can’t run at 100 units / day and absorb your output, then it is the bottleneck. See above.

Now, let’s break down your costs of capacity. In the broadest sense, your costs come down to two things:

  • Capital equipment. (And let’s include the costs of the facility here.)
  • Labor – paying the people.

The capital equipment cost is largely fixed. At any rate of production less than what the equipment is capable of holding, you are using it “less efficiently” than you could. Since machines usually operate at different rates, it is you aren’t going fully utilize anything but the slowest one. It doesn’t make sense to even try.

People is more complicated. In the short term, your labor costs are fixed as well. You are paying the people to be there whether they are productive or not.

When the people are operating machines, your flexibility depends on how well the automation is designed. The technical application of “lean tools” to build flow cells pushes hard against this constraint. We strive to decouple people from individual machines, so the rate can flex up and down by varying the work cycles rather than just having people wait around or over produce.

At the other end of the labor spectrum is pure manual work, like assembly. We are striving for that same flexibility by moving typically separated operations together so people can divide the labor into zones that match the desired rate of production.

All of these approaches strive for a system that allows incrementally adjusting the capacity by adding people as needed. However this adds costs as well, often hidden ones. Where do these people come from, and frankly, “what are they doing when they aren’t working for you?” are a couple of questions you need to confront. The people are not parts of the machine. The system is there to help the people, not the other way around. This is people using tools to build something, not tools being run by people.

Handling Seasonal Production Efficiently

“Our demand is seasonal” is something I hear quite a bit. It is usually stated as though it is a unique condition (to them) that precludes level production. In my nearly 30 years in industry, I haven’t encountered a product (with the possible exception of OEM aircraft production and major suppliers) that didn’t have a seasonal shift of some kind.

Depending on the fluctuations and predictability of future demand, using a combination of managing backlog and building up finished goods is a pretty common way to at least partly level things out for planning purposes.

That being said, I know of at least one company whose product is (1) custom ordered for every single unit and (2) highly seasonal (in fact, they are in their peak season as I write this). They don’t have as many options.

Solving the Problem

With all of that, we get to Darren’s specific question.

The short answer is “I don’t know, but we can figure it out.”

There isn’t a fixed answer, there is a problem to solve, a challenge to overcome.

Challenge

I am interpreting the challenge here as “Have the ability to flex production +/- 25% / month without sacrificing efficiency.”

Just to ensure understanding of the challenge, I would ask to translate the production capacity targets into takt times. What is the fastest takt time you would need to hit? What is the slowest?

In other words, the +/-25% makes me do math, even if I know the baseline, before I really know what you need to be able to do. Let’s get some hard numbers on it so we will all agree when we see it, or don’t.

Remember, takt time is simply a normalization of your demand over your production time. It is a technique for short-term smoothing of your demand. It doesn’t mean you are operating that way.

Current Condition

We need to learn more, so the next questions have to do with the current condition.

While this post is too short to get down to the details, there are some additional questions I would really need to understand here.

Known: There are 10 fixed workstations with 10 operators.

Assumed to be known: The high and low target takt times (from the challenge).

How are the workstations laid out?

What are the cycle times of each operation?

What is actually happening at each of the workstations?

What are they currently capable of producing in relation to the takt times we want to cover in our +/- 25% range?

A good way to start would be to get exit cycles from each of the positions, and from the whole line. What is the current cadence of the operation? What are the lowest repeatable cycle times? How consistently is it able to run? What is driving variation?

Since we are looking for rate flexibility, I am particularly concerned with understanding points of inflexibility.

I would be looking at individual steps, at distance between the workstations, and how easily it is to shift work from one to another. Remember, to be as efficient as possible, each work cycle needs to be as close as possible to the takt time we are striving to achieve this season. Since that varies, we are going to need to create a work space that gives us the smoothest transitions possible.

What is the Next Target Condition?

I don’t know.

Until we have a good grasp of the current condition, we really can’t move beyond that point. While I am sure Darren knows much more, I am at my threshold of knowledge: 10 workstations, 10 operators. That’s all I know.

However I do know that it is unlikely I would try to get to the full challenge capability all at once. Even if I did have a good grasp of the current condition, I probably can’t see the full answer, just a step that would do two key things:

  • Move in the direction I am trying to go.
  • Give me more information that, today, is hidden by the nature of the work.

For an operation this size, (if I were the learner / person doing the improvement here) I would probably set that target condition for myself at no more than a week or two. (This also depends on how much time I can focus on this operation, and how easy it is to experiment. The more experiments I can run, the faster I will learn, and the quicker I can get to a target.)

Now… I will re-state the target condition to answer this question:

“We can’t… [whatever the target condition is]… “because ________.” as many times as I can. That is one way to flush out obstacles.

Another way is just to tell the skeptics we are going to start operating like this right away, then write down all of the reasons they think it won’t work. Smile

Then the question is “OK, which of these obstacles are we going to address first?”

Iterate Experiments / PDCA to learn.

Once I know which obstacle I am choosing to address first, I need to know more about it. What do I want to learn, or what effect do I want to have on the process? Those things are my expected result.

Now… what do I need to do to cause that to happen? That is my next experiment.

And we are off to the races. As each learning cycle is completed, your current condition, your current level of understanding, changes. As you learn more, you better understand the obstacles and problems.

When you reach a target condition (or realize you are at the deadline and haven’t reached it), then go back to the top, review the challenge, make sure you understand the current condition, and establish a new target. Lather, rinse, repeat.

This Isn’t About “The Answers.”

imageA long time ago, when I first started this blog, I wrote a post called “The Chalk Circle.” I told the story of one of my more insightful learning experiences in the shadow of one of the original true masters, the late Yoshiki Iwata. My “ah ha” moment finally came several years later, and a year after his death. He wasn’t interested in the answers, he was teaching me the questions.

We don’t know the answers to a problem like “How do I get maximum efficiency through seasonal demand changes.” The answer for one process might give you something to think about, but copying it to another is unlikely to work well. What would work for Darren’s operation is unlikely to work in Hal’s. Even small differences mean there is more learning required.

When confronted with a problem, the first question should never be “What should we do?” Rather, we need to ask “What do we need to learn?”  What do we know? What do we not understand? What do we need to learn, then what step should we take to learn it? Taking actions without a learning objective is just trying stuff and hoping it works without understanding why.

What works is learning, by applying, the thinking behind sound problem solving, and being relentlessly curious about what is keeping you from moving to the next level.

I have come a long way since my time with Mr. Iwata, I continue to learn (lots), sometimes by making mistakes, sometimes with unlikely teachers, at times and in ways I least expect it. Sometimes it isn’t fun in the moment. Sometimes I have to confront something I have hidden from myself.

One thing I have learned is that the people who have all of the answers have stopped learning.

Darren – if you want to discuss your specific situation, click on “Contact Mark” and drop me an email.

More Cycle Time Questions from Search Results

A couple of more exam questions showed up in search results.

4. what can happen if the cycle time is much shorter than the takt time

The searcher didn’t even bother typing this one – just cut and paste the entire thing, including the question number.

Fortunately the answer is really easy:

Raiders of the Lost Ark warehouse

If you keep this up, you’ll need another building.

OK, here’s one that is a little more subtle:

185 units in 14 hours is what cycle time

Hmmm. My first thought is to go back to Who is Grading the Questions?

think whoever wrote this question is looking for something like 14 hours  (840 minutes) / 185 units = 272 seconds / unit (more or less). But that’s an average, it isn’t a cycle time.

The Average Rate of Output is not “Cycle Time.”

The average doesn’t give you any more information than the original question. This is simply a rate of output: 185 units in 14 hours. Cycle time is the measured time to complete one cycle.

There might be a single cycle that produces a batch of 185 units. Let’s say, for example, in a cure oven process that takes 14 hours to load, run and unload. Then the cycle time is 14 hours.

If the pieces are moving in a sequence of operations, but in a lot (which is different from a batch), where Operations 1 is completed on all 185, then Operation 2 is completed on all 185, etc. and maybe that all takes 14 hours? I have no idea what the cycle time(s) for the operations are. Most of the time the units are waiting in queue for the other 184 items to be done at each operation.

If we have true one-by-one flow then I have at least 185 cycle times. Hopefully they are all about the same, but likely that isn’t the case.

Are we measuring exit cycles (the cadence of output at the end of the process), or operator or machine cycle times?

By taking the average we are obscuring all of this information. Calling the average the “cycle time” just makes it worse because it gives people the impression that they are the same.

Cycle time is not calculated. It is measured. You cannot determine cycle time by applying mathematical operations on numbers. You have to go observe with a stopwatch.

And finally:

within each four hours worked, workers can take a total of 48 minutes in allowance (so allowance factor is based on workday). if the observed time is 6 minutes, and performance rating is 95%, what is the standard time (in minutes; give three significant digits after the decimal point)?

Even if I could understand the question, down to thousandths of a minute? Seriously?

</rant> <!– Until next time –!>

 

 

Toyota Kata: Reflection on Coaching Struggling Learners

The “Five Questions” are a very effective way to structure a coaching / learning conversation when all parties are more or less comfortable with the process.

The 5 Questions of the Coaching Kata

Some learners, however, seriously struggle with both the thinking pattern and the process of improvement itself. They can get so focused on answering the 5 questions “correctly” that they lose sight of the objective – to learn.

A coach, in turn, can exacerbate this by focusing too much on the kata and too little on the question: “Is the learner learning?”

I have been on a fairly steep learning curve* in my own journey to discover how modify my style in a way that is effective. I would like to share some of my experience with you.

I think there are a few different factors that could be in play for a learner that is struggling. For sure, they can overlap, but still it has helped me recently to become more mindful and step back and understand what factors I am dealing with vs. just boring in.

None of this has anything to do with the learner as a person. Everyone brings the developed the habits and responses they have developed throughout their life which were necessary for them to survive in their work environment and their lives up to this point.

Sometimes the improvement kata runs totally against the grain of some of these previous experiences. In these cases, the learner is going to struggle because, bluntly, her or his brain is sounding very LOUD warning signals of danger from a very low level. It just feels wrong, and they probably can’t articulate.

Sometimes the idea of a testable outcome runs against a “I can’t reveal what I don’t know” mindset. In the US at least, we start teaching that mindset in elementary school.

What is the Point of Coaching?

Start with why” is advice for me, you, the coach.

“What is the purpose of this conversation?” Losing track of the purpose is the first step into the abyss of a failed coaching cycle.

Coach falling over a cliff.

Overall Direction

The learner is here to learn two things:

  • The mindset of improvement and systematic problem solving.
  • Gain a detailed, thorough understanding of the dynamics of the process being addressed.

I want to dive into this a bit, because “ensure the learner precisely follows the Improvement Kata” is not the purpose.

Let me say that again: The learner is not here to “learn the Improvement Kata.”

The learner is here to learn the mindset and thinking pattern that drives solid problem solving, and by applying that mindset, develop deep learning about the process being addressed.

There are some side-benefits as the learner develops good systems thinking.

Learning and following the Improvement Kata is ONE structured approach for learning this mindset.

The Coaching Kata, especially the “Five Questions” is ONE approach for teaching this mindset.

The Current Condition

Obviously there isn’t a single current condition that applies to all learners. But maybe that insight only follows being clear about the objective.

What we can’t do is assume:

  • Any given learner will pick this up at the same pace.
  • Any given learner will be comfortable with digging into their process.
  • Any given learner will be comfortable sharing what they have discovered, especially if it is “less than ideal.”

In addition:

  • Many learners are totally unused to writing down precisely what they are thinking. They may, indeed, have a lot of problems doing this.
  • Many learners are not used to describing things in detail.
  • Many learners are not used to thinking in terms of logical cause-effect.
  • The idea of actually predicting the result in a tangible / measurable way can be very scary, especially if there is a history of being “made wrong” for being wrong.

Key Point: It doesn’t matter whether you (or me), the coach, has the most noble of intentions. If the learner is uncomfortable with the idea of “being wrong” this is going to be a lot harder.

Summary: The Improvement Kata is a proven, effective mechanism for helping a learner gain these understandings, but it isn’t the only way.

The Coaching Kata is a proven, effective mechanism for helping a coach learn the skills to guide a learner through learning these things.

For the Improvement Kata / Coaching Kata to work effectively, the learner must also learn how to apply the precise structure that is built into them. For a few people learning that can be more difficult than the process improvement itself.

Sometimes We Have To Choose

A quote from a class I took a long time ago is appropriate here:

“Sometimes you have to choose between ‘being right’ or ‘getting what you want.’”

I can “be right” about insisting that the 5 Questions are being answered correctly and precisely.

Sometimes, though, that will prevent my learner from learning.

Countermeasure

When I first read Toyota Kata, my overall impression was “Cool! This codifies what I’ve been doing, but had a hard time explaining.” … meaning I was a decent coach, but couldn’t explain how I thought, or why I said what I did. It was just a conversation.

What the Coaching Kata did was give me a more formal structure for doing the same thing.

But I have also found that sometimes it doesn’t work to insist on following that formal structure. I have been guilty of losing sight of my objective, and pushing on “correctly following the Improvement Kata” rather than ensuring my learner was learning.

Recently I was set up in the situation again. I was asked to coach a learner who has had a hard time with the structure. Rather than trying to double down on the structure, I experimented and took a different approach. I let go of the structure, and reverted to my previous, more conversational, style.

The difference, though, is that now I am holding a mental checklist in my mind. While I am not asking the “Five Question” explicitly, I am still making sure I have answers to all of them before I am done. I am just not concerned about the way I get the answers.

“What are you working on?” While I am asking “What is your target condition?,” that question has locked up this learner in the past. What I got in reply was mostly a mix of the problems (obstacles) that had been encountered, where things are now, (the current condition), some things that had been tried (the last step), what happened, etc.

The response didn’t exactly give a “Target Condition” but it did give me a decent insight into the learner’s thinking which is the whole point! (don’t forget that)

I asked for some clarifications, and helped him focus his attention back onto the one thing he was trying to work out (his actual target condition), and encouraged him to write it down so he didn’t get distracted with the bigger picture.

Then we went back into what he was working on right now. It turned out that, yes, he was working to solve a specific issue that was in the way of making things work the way he wanted to. There were other problems that came up as well.

We agreed that he needed to keep those other things form hurting output, but he didn’t need to fix them right now. (Which *one* obstacle are you addressing now?). Then I turned my attention back to what he was trying right now, and worked through what he expected to happen as an outcome, and why, and when he would like me to come by so he could show me how it went.

This was an experiment. By removing the pressure of “doing the kata right” my intent is to let the learner focus on learning about his process. I believe I will get the same outcome, with the learner learning at his own pace.

If that works, then we will work, step by step, to improve the documentation process as he becomes comfortable with it.

Weakness to this Approach

By departing from the Coaching Kata, I am reverting to the way I was originally taught, and the way I learned to do this. It is a lot less structured, and for some, more difficult to learn. Some practitioners get stuck on correct application of the lean tools, and don’t transition to coaching at all. I know I was there for a long time (probably through 2002 or so), and found it frustrating. It was during my time as a Lean Director at Kodak that my style fundamentally shifted from “tools” to “coaching leaders.” (To say that my subsequent transition back into a “tools driven” environment was difficult is an understatement.)

Today, as an outsider being brought into these organizations, my job is to help them establish a level of coaching that is working well enough that they can practice and learn through self-reflection.

We ran into a learner who had a hard time adapting to the highly structured approach of the Improvement Kata / Coaching Kata, so we had to adapt. This required a somewhat more flexible and sophisticated approach to the coaching which, in turn, requires a more experienced coach who can keep “the board” in his head for a while.

Now my challenge is to work with the internal coaches to get them to the next level.

What I Learned

Maybe I should put this at the top.

  • If a learner is struggling with the structured approach, sometimes continuing to emphasize the structure doesn’t work.
  • The level of coaching required in these cases cannot be applied in a few minutes. It takes patience and a fair amount of 1:1 conversation.
  • If the learner is afraid of “getting it wrong,” no learning is going to happen, period.
  • Sometimes I have to have my face slammed into things to see them. (See below.)
  • Learning never stops. The minute you think you’re an expert, you aren’t.

__________________

image* “Steep learning curve” in this case means “sometimes learning the hard way” which, in turn means, “I’ve really screwed it up a couple of times.”

They say “experience” is something you gain right after you needed it.

Who is Grading the Questions?

Once again the search terms have revealed an interesting test question. Let’s parse it and see what we can learn.

2. the cycle time to complete a final step on an assembly line is normally distributed, with a mean of 4 minutes and a standard deviation of 1 minute.1) at the end of an 8-hour shift, how many units will have been assembled on average?

The question is about exit cycles – the cadence at the output of a production process of some kind, in this case an assembly line.

Measuring and plotting the variation of exit cycles at the customer end of your production process is a great way to get a handle on how much variation there is.

This question, however, reveals a level of simplistic understanding in the mind of the person who wrote the question of how these things work.

Answering the Question

First, we have to assume that this assembly line (which implies manual work) takes no breaks during their 8 hour shift. We have no information that suggests otherwise.

That means we have 8 hours x 60 minutes = 480 minutes of working time.

Intuitively, if the exit cycles are normally distributed (which implies the distribution is symmetric), with a mean of 4 minutes, then we should be able to simply divide to get the average number of units built during each shift.

480 / 4 = 120 units

Which in the long-haul is close, though it will take a lot of iterations to converge on that. Running about 65 iterations of a random number set with a mean of 4 and standard deviation of 1, I got an average daily production of 120.1, a high of 127 units, and a low of 115.

But Exit Cycle Times Aren’t Normally Distributed

This is a problem with a lot of the “statistics” I see being kicked around today.

This is a histogram of 36 actual exit cycle times from a real production line.

image

The “Cycle Time” bucket numbers on the horizontal axis represent the top of the range. So the high bar says there were 10 cycle times between 25 and 30 seconds.

The mean of the data set is 42, which is actually one of the less frequent values.

The first thing that jumps out is that this data set might have two peaks (be bimodal). I would want a lot more data before I drew this conclusion, however let’s assume it is for the discussion because this is quite common.

A bimodal distribution implies there are two different processes running. If we looked at a run chart of individual cycles, we would probably see one of two things:

  • Clusters of longer times spaced between clusters of shorter times. This would be the case if the line is running lots or batches, then switching over.
  • A repeating cadence like “short-short-short-long, short-short-short-long” which would indicate really good production leveling.

But all of that is a sidebar. The real issue I have with this “homework question” simple: Cycle times are (almost) never normally distributed.

There is a minimum time that can elapse between the completion of one unit and the completion of the next, but there is no theoretical limit on the length of delay. These distributions (almost) always have a tail to the right.

So once again, be very careful about blindly using averages (arithmetic means) unless you understand the whole story.

The Test Question Misleads the Students

And this is my problem with questions like this on exams and homework, especially in classes that purport to be teaching how factories run. Even when using a distribution, the problems almost always default to a symmetric distribution when real world factory-related data sets are rarely symmetrically distributed.

You are teaching your students a simple solution that won’t work in the real world without explaining why.

Team Member Saves

image

Now and then one of your team members makes a great save. They catch something that could have caused a defect, an accident, or done harm in some way.

Often we celebrate these saves, sometimes informally, sometimes formally. And that is well and appropriate.

But let’s make sure we are celebrating for the right reasons.

The save isn’t what should be celebrated.

Rather, the celebration should be a big THANK YOU for finding a gap in your process.

Somehow the process is capable of producing a defect, resulting in an accident, or doing harm. Your team member noticed that.

We usually just celebrate correcting the immediate problem.

But What is preventing exactly the same thing from happening tomorrow?*

image

That front-line customer-facing team member is your last line of defense.

They only get an opportunity to make a “save” when every other point in the process has failed to detect the  problem.

Given enough “shots” at this front line team-member, sooner or later, one is going to get through.

What happens then? Is the inverse logic applied? “You should have caught that.”

Perhaps, but where in the process was the problem actually created?

Somewhere, long before this diving catch, there is an instant when the process went from operating safely and defect free to creating an opportunity, an opening, for a problem to pass undetected.

Where and when was that moment?

Or is that how the process normally operates, and we are just lucky most of the time?

Dig in, think about it.

And thank that team member for saving you, but don’t count on it every time.

———-

*Thanks to Craig for this great way to sum up the question.