Lessons from Driving a Forklift

The spring and summer of 2000 were a long time ago, but I learned some lessons during those months that have stayed with me. In fact, the learning from that experience is still happening as I continue to connect it to things I see today.

I was a member of a team working hard to stand up a new production line of a new product. The rate pressures were very high, the production, production control, and quality processes were immature.

At a high level, the parts flow was supposed to work like this:

Steel parts are fabricated and welded, based on the production schedule for various configurations.

Unit sets of parts were sent to outside paint. (We didn’t have our own paint system yet.) In reality, unit sets would be broken up as some parts went to sister plants, others went to outside vendors, each with their own lead times and flow times.

Parts return from outside paint. Because of the different vendors and lead times, different parts arrive on different days.

On assembly day, kits are built for the parts required at each entry point on the assembly line. Those kits are delivered based on a pull. The assembly line had a number of entry points and feeders, so for each takt time cycle, though only one “unit’s worth” of parts were actually delivered, those parts were for different units, as feeders had different lead times into the main line.

image

The innocuous challenge was to develop the kitting process (in red) that broke down the parts into  kits and got them delivered to the line.

I got pulled in on Thursday of a “kaizen event” that was supposed to develop this process. What had actually happened, though, was analysis paralysis, a lot of theoretical discussions, a lot of drawings on a white board, but nothing had actually been tested or tried. My assignment was simple: Organize this and get it going on Monday.

I had four people working for me, though they were not officially direct reports. They were an eclectic mix of personalities and styles.

A few things became apparent very quickly:

The process of scheduling which parts needed to be fabricated and welded to be sent through painting on any particular day was broken. Result: What was needed wasn’t necessarily what got sent to paint.

The processes of keeping parts organized during the various outside paint operations was broken. Result: Unit sets got mixed together, parts went missing.

As a result this is what my days looked like:

I came in before a hint of dawn at 4:45am to prepare for the assembly line starting at 5:40. I would go out into the parts yard with the day’s production schedule and a flashlight. My goal was to answer a simple question:

What units on this list can I build with the parts that are here?

I would re-sequence the production schedule to front-load the units that looked like we had everything we needed. (This caused all kinds of problems with serial number sequences and engineering change control, but that is a different story.)

We would start pulling in those parts, and breaking them down into the kits. We set up FIFO lanes for each entry point on the assembly line, and worked as fast as we could to build up about a three hour backlog. Why? Because it took about three hours to expedite a missing part through paint. Once we had that queue built up, as we discovered shortages (or parts painted the wrong color!), we had a chance to get the situation corrected and have a shot at not creating a shortage on the line.

We were working 10 hour shifts, I was typically there for 12-14 hours. Even though I was a “lean guy” my daily work was orchestrating all of this chaos, expediting and delivering parts, and I spent at least six of those hours every day driving a forklift. I got really good at forktruck operation that summer.

At the end of the day, I might sit and chill for a little while, then would get in my truck, go home, and do it all again tomorrow. One of those days as I went to back out of the parking space, I hit the turn signal to put my stick-shift truck into reverse – because that’s how the forklift controls worked.

What I Learned

I actually continue to learn. But here are a few things that have stood out for me.

Shop Floor Production Supervisor is a really hard job. I wasn’t a supervisor, but I was doing many of the things that we asked supervisors to do. Making my people take their breaks. Slow down on the pallet jack. Listening to a frustrated guy who was ready to quit – understanding his paradigm, and helping him re-frame his experience. Constant radio calls to places in whatever building I wasn’t in at the time. Operating within a system that functions only with continuous intervention.

I totally knew how to set up a workable, stable process. I knew how to get all of these processes linked together to pull everything through. I knew how to build in effective quality checks.

What I was able to do was spend a few minutes at the end of my day, or during my lunch breaks (instead of eating) trying to implement some kind of simple visual control that mitigated against repeating a mistake we had just made. We attached a tag with a production sequence number (000 through 999, repeating) to each kit. That let us, and the people on the line, see if we had delivered something out of sequence.

Then, after I had delivered a yellow painted kit to go onto an otherwise blue painted unit (oops) we made a board with the production sequence numbers and the associated colors for the major components.

Then… after I had delivered (note the theme here) the wrong size of a major component to the line, we added that information to the board AND tagged those components so we could quickly distinguish one from the other.

But I was never able to address the upstream issues that were delivering short kits to us in the first place. All I could do was add steps, add time, add inventory to protect myself from those things and do my best to fix it before the main line got stopped.

We had a saying in the Army: “When you are up to your a$$ in alligators, it is hard to work on finding the best way to drain the swamp.”

Thus:

It is unreasonable to expect systems improvements when everyone is scrambling to make the system function at all. It isn’t that they don’t want to make improvements. It isn’t that they don’t know what to do. It is that there is barely time to breathe before the next problem needs to be stamped down.

And finally: A five person job requires five people. I had four people working for me. That wasn’t enough. Guess who had to fill in the rest of it? I tried my best to handle the problems so they could get into some kind of cadence on the stuff that wasn’t a problem. But (Routine+Problems) = (or greater than) 5 people in this case, and it took all of us just to navigate the rapids without dumping everyone out of the boat. If everything was running smoothly, it was probably a three person job. If we could have set up a sequenced pull from assembly all the way back through weld, it would have been a two or even one person job.

Reflection

That forklift key is still on the keyring in my pocket as a reminder of that time. What follows are some of the bigger-picture things that come to mind as I continue to construct, tear down and reconstruct my own thinking.

Attribution Error

There is a strong tendency among us humans to attribute our own failures to a poor environment, but to attribute other’s failings to individual character or capability. Yet in many cases, simply changing the venue or circumstances can allow a previously low-performer to blossom. We see this (and the opposite) all of the time in professional athletics.

Making this error is easy when we are talking about “they.”  If only they… Why don’t they… They don’t get it… “They” are people who are likely doing the very best they can within the context of the system they are in. And, as I pointed out above, changing the system from the inside is hard.

Actually that isn’t quite accurate. Changing the system is hard work.

The Pace of Change

The organization I was describing above was experiencing circumstances at the time that outpaced their ability to experiment, reflect, and adapt. Every organization has a rate at which they are able to change.

Just to make things more complicated, it is possible to learn what must be done much faster than those things can be put into place. This frustrates a lot of change agents. They see the technical changes that must take place, but often struggle against cultural barriers and obstacles. These things take much longer, and it is pretty much impossible to put them on a fixed timeline or project plan. Thus, we frame them as “resistance to change.” We know what must be done, but “they” don’t do it.

Organizations Under Stress

When an organization is under stress, there is fear of complete breakdown. People become very conservative and avoid the uncertain and unfamiliar. If they become overwhelmed just trying to get their task done, they are going to shut out any information that isn’t relevant right now. Horizontal communications break down, and the feeling of isolation increases.

At this point, all coordination has to funnel upward and then downward through the vertical linkages, as cross-functional coordination largely isn’t happening.

Now the higher leader gets overwhelmed, feeling she has to micro-manage every detail- because she does. “Why don’t they talk to each other?” Well, the structures for that were probably very informal, and now have broken down.

This Isn’t About “Them”

As I mentioned above, it is really easy to attribute the perception of dysfunction to individuals. And as people become isolated within their own task-worlds, avoiding a mistake becomes the dominate motivation. This happens even in organizations with the most benign intentions.

If you are a leader, pay attention to the emotions. If people are snippy, are pushing back on ideas as “just more work” then that saturation point may well have been reached. Pushing harder isn’t going to make things go faster, it is going to slow them down.

image

How Does the Teacher Learn?

In my last post, If the Student Hasn’t Learned…I made the point (again) that sometimes trying too hard to impose a formal structure on a learner can impede their progress.

Since writing that, I have been doing a bit of reflection on my own development as a coach, and I need to give credit where it is due.

As any regular reader knows, I have been an enthusiastic student and practitioner of Mike Rother’s Toyota Kata since I first read the book. I have written extensively about it in this forum. And I have made my own modest contributions to the practice. It has been over this time, and countless cycles of guiding beginning (and intermediate, and expert) learners through The Five Questions that I can hold the structure in my own head while not imposing rigidity onto others.

I will always default to using the formal structure because I think, in the vast majority of cases, it sets a better foundation. And even in those cases where I have to let go of the structure, that is a temporary countermeasure.

Once my learner is comfortable with the meta-patterns, then the structure follows, and makes sense to them. Some people learn that way, and I have to be able to pick that up.

I may have been an OK coach before all of this, I likely overestimated my ability at the time. Today, though, thanks to the Toyota Kata structure, I am becoming more comfortable with… not letting go if it, for I hold it in my own mind, but maybe withholding the framework and letting the learner fill it in more fluidly.

As we are boring down on the 10th Anniversary of Toyota Kata, and the 5th KataCon, we have a great opportunity to look at how the pattern that Toyota Kata teaches reaches far beyond process improvement and problem solving.

I will be speaking on the topic of Developing Leaders for Continuous Improvement on Day 1, and yes, we can use the same meta-patterns. Craig Stritar and I will be taking a much deeper look into the same principles in our Experiential Workshop. If you want to get a hands-on, reflective look at meeting your challenges as a change agent, come join us there.

In reality, the teacher learns by sharing and swapping experiences with others. I am not going to try to list everyone you will, and should, meet at KataCon here because I would surely leave someone’s name off my list by accident. But look at the presenters and speakers. I know most of them and were I not presenting my own workshops and breakouts, I would be hard pressed to decide which ones to attend. You can’t make a mistake here.

 

 

KataCon4–Notes along the way: Part 2

One of the things Menlo does (and I am sure they are not the only ones in their business who do) is create user personas – a biographical profile of a fictional person who represents a category of potential user for the software they are developing.

In Joy, Inc, Rich Sheridan describes the often contentious process of then forcing the customer to pick a single persona as the primary user – the persona whose needs will drive all decisions about optimization. That person goes in the center of their three rings.

image

They allow two personas in the 2nd ring, and three in the 3rd ring.

image

As they make design decisions about their code and user interface, they always defer to the innermost rings. That doesn’t mean that someone in a ring further out won’t have their needs met, but they will meet those needs in ways that don’t compromise the process for personas closer to the center.

Persona Mapping for KataCon

In the spirit of being a temporary Menlonian, I worked paired with Craig (over the phone, and in a shared Google Doc) and we developed a persona map for KataCon. Of course, had we done this correctly we would have gone back in time to the previous KataCon, gotten the profiles from the attendees lists, interviewed people, and put together profiles for “typical” people who attend.

Since we couldn’t do that, we pushed past our threshold of knowledge and combined experience with a bit of speculation. I did confirm some of our assumptions via a phone call to Dwayne at Lean Frontiers who graciously answered my questions as he was driving across Indiana.

This process forced us to actually think about who was in the audience, and why they were there – what they were seeking from their participation in the conference. As Rich and I talked about his message, and later on as Craig and I worked on our “Experiential Workshop” we used the names of these “people” rather than generic terms like “participant” or “audience.” I found that really focused our conversations.

Who Do You Optimize Your Process For?

This really begs the general question: Who is your process optimized for?

Is it optimized for the person doing the work?

For the customer’s specific experience? And if so, who is the “customer persona” you are optimizing THAT for? For example, for an ideal retail experience, a mom with two kids in tow would be a different customer than a single guy. You likely get both, but if you have do something that slightly compromises one in order to optimize the other… who is in the center ring?

Next up: Target Conditions as User Stories

Toyota Kata and The Menlo Way

I have been telling everyone who will listen to read Rich Sheridan’s book Joy, Inc. ever since I came across and read it in the fall of 2015.

Fast forward to earlier this year when Lean Frontiers sent out their request for suggested keynote speakers for KataCon. I wrote to Mike Rother and asked him “Do you think we could get Rich Sheridan?”

Skip ahead a bit more, and I spent four days last week at Menlo Innovations in Ann Arbor – two days “in the chalk circle” paying close attention to the actual day-to-day work there, and two days working (pairing) with Rich Sheridan to work out the key beats for his KataCon keynote.

 

The “So What?” Test

Menlo is well known as a benchmark for a great working culture. But the question you may be asking (and, honestly I hope you ARE asking it) is “What does Menlo Innovations and agile software development have to do with Toyota Kata?”

If you visit Menlo (and I really hope you do!) here is what you won’t see:

  • Learner storyboards.
  • “5 Questions” coaching cycles.
  • Obstacle parking lots.
  • Experiment Records (PDCA Records)

In other words, you won’t see the explicit artifacts that characterize an organization using Toyota Kata to learn how to think about improvement scientifically. In that sense, Menlo isn’t a “Toyota Kata” benchmark.

OK… and?

You don’t see those things at Toyota either. You don’t go to Toyota to see “Toyota Kata.”

The Underlying Thinking Pattern

What you will see (and hear… if you pay attention) at Menlo Innovations is an underlying pattern of scientific thinking and safe problem solving in everything they do.

Let’s review what Toyota Kata is really all about.

Rather than re-writing something elegant here, I am going to quote from my part of an email exchange between Mike Rother, Rich Sheridan and me:

Going back to Mike’s original research premise, we knew that Toyota has this pretty awesome culture thing, but didn’t really understand the “secret sauce” of the exact structure of their interactions. Put another way, we saw and understood all of the artifacts, but copying the artifacts doesn’t copy the culture.

Mike’s research was really the first that dug deeper into the interactions that the artifacts support.

Once he extracted that “secret sauce” he then boiled off all of the other stuff, and what remained at the bottom of the pot was the Improvement Kata steps and the Coaching Kata steps.

In practice at Toyota, those things are deeply embedded in the artifacts. Sometimes they aren’t even spoken.

My informal hypothesis was that if I spent time paying attention to, not just the artifacts, but the way those artifacts guided interactions at Menlo, and then boiled off the other stuff, what would remain at the bottom of the Menlo pot would also be the Improvement Kata and Coaching Kata steps. And, though I didn’t do this formally, and yes, I had confirmation bias working here, I believe I can safely say “I have no evidence to contradict this hypothesis.”

For example:

In our conversation on Friday, Mike pushed back a bit on “just run the experiment,” [context clarification: Experiments to randomly try stuff, without a clear target condition rarely get you anywhere] but the reality I observed and heard was that “purpose” (challenge and direction) and “current condition” are deeply embedded in the day-to-day interactions, and “just run the experiment” is, indeed, working on a specific obstacle in the way of a target condition of some kind.

[…]

“What problem are you trying to solve?” is Menlo jargon that I overheard many times just listening to people talk.

Within Menlo, that term is contextual. Sometimes it is about the higher-level direction and challenge.

Sometimes it is about an intermediate target condition.

Sometimes it is about an immediate problem or obstacle.

As we say in Kata world, it is fractal. It is truly fractal at Menlo as well, to the point where the words don’t change at various levels.

The words DO change at various levels in Toyota Kata’s jargon, but we can’t get hung up on the terms, we have to look at the structure of problem solving.

Menlo’s co-founders already had this thinking pattern, and deliberately sought to embed it into the culture of the company they were starting. There wasn’t really any need to explicitly teach it because they weren’t trying to change the default behavior of an organization. New Menlonians learn the culture through the interviewing and on-boarding process and adopt very quickly because the very structure of the work environment drives the culture there.

In fact, spend any time there even just hanging out, and it is very difficult NOT to get pulled into The Menlo Way. Like everyone else, Rich and I were in the daily stand-up as pair-partners, reporting our work progress on his keynote.

image

What About Toyota Kata?

Menlo has had hundreds (thousands, actually) of visitors, and those who are “lean savvy” all ask if Menlo is “using lean” as their guideline. The answer is “no, we are just trying to solve problems.” While they have certainly incorporated most of the artifacts of “agile software production,” the purists push back that they aren’t “really doing it” because they didn’t copy those artifacts exactly. Nope. They used them as a baseline to solve Menlo’s problems.

When we see an awesome problem-solving culture, it is tempting to try to reverse engineer it by copying the physical mechanics, such as heijunka boxes (work authorization boards), kanban, “standard work” and the like.

But we have to dig down and look at the routines, the behavior that those artifacts and rituals support. When we do, we see the same patterns that Toyota Kata is intended to teach.

You need to begin with the thinking pattern. Use Toyota Kata to learn that.

As you do, take a look at your artifacts – the procedures, the policies, the control mechanics of your work. Reinforce the ones that are working to create the kind of culture you want. Challenge the ones that are getting in your way. Do both of those things as deliberate experiments toward a clear vision of the culture you want to create.

That is the benefit of studying companies like Menlo.

I hope to see you all at KataCon, hear what Rich has to say to our community, and establish a link between these two communities that have, up to now, been separate.

katasummit.com

Looking at some old notes…

I am cleaning out some old notepads. One page has the notes I took during a 4pm production status meeting during my first “get to know you” visit to this company.

In a box on my notes page it says:

image

“More information is not going to help until you begin to define how you expect things to run.”

What I had observed is their focus on the previous 24 hours metrics, with lots of speculation about “what happened” to account for the lost production. They were focused on incidents and, honestly, assigning those incidents as causes. Where they came up short, they were seeking more information about lost production incidents.

But everything I have written is just to give you a little context for the scribbled box on my notes a few years ago.

Today? They fixed it. This was one of the most dramatic culture shifts – from “find who to blame” to “let’s solve the problem” I have ever witnessed.

Reflection:

What are your daily meetings like? Are they focused on the stuff that went wrong yesterday? Or are they focused on where you are trying to go in the near future?

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.

The Lean Plateau

Many organizations trying to deploy lean get great results for the first couple of years, then things tend to stall or plateau. This is in spite of continued effort from the “lean team.”

image

We Still Don’t Have a Lean Culture

This was the comment by the Continuous Improvement director of a pretty large corporation. They had been running improvement events for several years, everyone had pretty much been through one.

Each of the events had made pretty good strides during the week, but the behavior wasn’t changing. Things were eroding behind the events, even though everyone agreed things were better.

It was getting harder and harder to make more progress. They had hit the plateau.

What Causes the Lean Plateau?

While it might not be universal, what I have seen happen is this:

The implementation is led by a small group of dedicated technical experts. They are the ones who are looking for opportunities, organizing the kaizen event teams, leading workshops, and overseeing the implementation of lean techniques.

While this works in the short term, often the last implemented results begin to erode as soon as the lean experts shift their attention elsewhere.

At first, this isn’t noticed because the implementation is proceeding faster than the erosion.

However the more areas that are implemented, the faster the erosion becomes. There is simply more “surface area” of implemented areas.

At some point, the rate of erosion = the rate of implementation, and the lean team’s efforts start to shift from implementing new areas to going back and re-implementing areas that have eroded.

The lean team’s capacity becomes consumed re-implementing, and they spend less and less time going over new ground. They are spending all of their time “spinning the plates” and no time starting new ones.

Key Point: The lean plateau occurs when the level of implementation effort and the rate of erosion reach an equilibrium.

In the worst scenario, sooner or later financial pressures come into play. Management begins to question the expense of maintaining an improvement office if things aren’t getting significantly better on the bottom line. What they don’t see is that the office is keeping things from getting worse, but they aren’t called the “maintain what we have office” for a reason.

Breaking the Lean Plateau

When I was a lean director in a large company, we were confronting this very question. We had a meeting to talk about it, and quickly started blaming “lack of management commitment.”

Leaders Weren’t Stepping Up

In any given area, after education and planning, our last step was always to have a major effort to put flow production into place. Since the performance of the area would be substantially better, we expected the leaders to work hard to continue that performance.

What actually happened in an area was “implemented,” was the line leaders in that area – supervisors, managers, senior managers – weren’t working to look for erosion and correct it.

Instead, when a problem was encountered, they were making some kind of accommodation that compromised flow. The effect of the problem went away, but things had eroded a bit.

What we thought we learned: The weren’t “supporting the changes.”

What we really learned – though it was only realized in hindsight: This is the mechanism of “erosion.”

Flow production is specifically designed to surface small problems quickly. If there is no mechanism to detect those problems, respond, correct, and learn, then the only thing leaders can do is add a little inventory, add a little time, add an extra operation.

As Hirano put it so well decades ago:

All waste is cleverly disguised as useful work.

But Our Current Condition was Incomplete

There were outliers where it was working.

As we talked, we realized that each of us had experience with an outlier – one or two areas that were actually improving pretty steadily. Trying to understand what was different about these bright spots, we looked for what they all had in common. Surprisingly:

  • They were areas with no dedicated improvement teams.
  • They ran few, if any, 5-day kaizen events.
  • They were geographically close to one of us (senior “Directors”).
  • One of us had decent rapport with the area management team.
  • We each had an informal routine with them: We would drop by when we had time, and walk the work area with the area leader. We could discuss the challenges they were facing, how things were operating, go together to the operations concerned, and look at what was happening. We could ask questions designed to “sharpen the vision” of the leader. Sometimes they were leading questions. Most of the time they were from genuine curiosity.
  • By the time we left, there was generally some action or short term goal that the leader had set for himself.

Even though we “lean directors” had never worked together before, our stories were surprisingly consistent.

The Current Condition (Everywhere Else)

aka Dave’s Insight

The next logical question was “If that is what we do, what happens everywhere else? What do the lean staff people do?”

Now we were trying to understand the normal pattern of work, not simply the outcome of “the area erodes because the leaders don’t support the changes.”

Dave confidently stood up and grabbed the marker. He started outlining how he trained and certified his kaizen leaders. He worked through the list of skills he worked to develop:

  • Proficiently deliver the various topical training modules – Waste vs. Value Add; Standard Work; Jidoka; Kanban and Pull;
  • “Scan” an area to find improvement opportunities.
  • Establish the lean tools to be deployed.
  • Organize the workshop team.
  • Facilitate the “Vision”
  • Manage the “Kaizen Newspaper” items
  • etc

and at some point through this detailed explanation he stopped in mid sentence and said something that brought all of us to reality (Please avert your eyes if you are offended by a language you won’t hear on network TV):

“Aw… shit.”

What we realized more or less simultaneously was this:

Management wasn’t engaged because our process wasn’t engaging them.

Instead, our experts were essentially pushing them aside and “fixing” things, then turning the newly “leaned” area over to the supervisors and first line managers who, at most, might have participated in the workshop and helped move things around.

Those critical front line leaders were, at best left with a to-do list of ideas (kaizen newspaper items) that hadn’t been implemented during the 5 days.

There was nothing in the structure to challenge them to meet a serious business objective beyond “Look at how much better everything runs now.” The amount of improvement was an after-the-fact measurement (or estimate) rather than a before-we-begin imperative.

So it really should be no surprise that come Monday morning, when the inevitable forces of entropy showed up, that things started to erode. The whole system couldn’t have been better designed for that outcome.

Why the Difference in Approach?

In retrospect, I don’t know. Each of us senior “lean directors” had been taught, or heavily influenced by, Toyota-experienced Japanese mentors, teachers, consultants.

When we engaged the “outlier” areas, we were following a kinder, gentler version of what they had taught us.

On the other hand, what we were teaching our own people was modeled more on what western consultants were doing. Perhaps it is because it is easier to use forms and PowerPoint for structure than to teach the skills of the conversations we were having.

Implement by Experts or Coached by Leaders

That really is your choice. The expert implementation seems a lot easier.

Unfortunately the “rapid improvement event” (or whatever you call them) system has a really poor record of sustaining.

Perhaps our little group figured out why.

There are no guarantees. No approach will work every time. But a difficult approach that works some of the time is probably better than an easy path that almost never works.

Output vs. Takt Time

The team’s challenge is to reach steady output of 180 units per hour.

Their starting condition was about 150 per hour. Their equipment and process is theoretically capable of making the 180 per hour with no problem.

They calculated their takt time (20 seconds) and established a planned cycle time of 17 seconds.

Some time later, they are stuck. Their output has improved to the high 160s, but those last 10-12 units per hour are proving elusive.

This is the point when I saw their coaching cycle.

Looking at their history, they had set a series of target conditions based on output per hour. Their experiments and countermeasures had been focused on reducing stoppages, usually on the order of several minutes.

“Does anybody have a calculator?”

“Divide 3600 seconds by 180, what do you get?”

“20 seconds.”

“Do you agree that if your line could reliably produce one module every 20 seconds that you would have no trouble reaching 180 modules per hour?”

Yes, they agreed.

“So what is stopping you from doing that?”

They showed me the average cycle times for each piece step in the process, and most were at or under 15 seconds. But averages only tell a small part of the story. They don’t show the cumulative effect of short stoppages and delays that can cascade through the entire line.

The team had done a lot of very good work eliminating the longer delays. But now their target condition had to shift to stability around their planned cycle time.

Performance vs Process Metrics

This little exercise shows the difference between a process metric and the performance metric.

Units-per-hour is a performance metric. It is measured after the fact, and tells the cumulative effect of everything going on in the process. In this case, they were able to make a lot of progress just looking at major stoppages..

Stability around the planned cycle time or takt time (you may use different words, that’s OK) is a process metric.

It shows you what is happening right now. THIS unit was just held up for 7 seconds. The next three were OK, then a 10 second delay. It’s those small issues that add up to missing the targeted output.

The team’s next target condition is now to stabilize around their planned cycle time.

Since they averaged their measurements, their next step is to (1) take the base data they used to calculate the averages and pull the individual points back out into a run chart and (2) to get out their stopwatches and go down and actually observe and time what is really going on.

I expect that information to help them clarify their target condition, pick off a source of intermittent delay, and start closing the remaining gap.

Interesting Question about Cycle Time

An interesting search landed someone on the site recently. Here it is:

a machine is producing 55 parts in one hour. what is the cycle time for each part.

Likely this is someone Googling his homework question, but I’d like to take apart the question and discuss it. If this is a homework question, I would contend that the likely “correct” answer is wrong.

Take a pause and think about it for a second. How would you reflexively answer this question?

 

 

Someone encountering this question is likely to simply divide the 55 parts of output into the 60 minutes of elapsed time. Doing that, we get something just over 65 seconds per part.

Which is interesting, but it isn’t the cycle time per part. It is the average rate of production, but it isn’t the cycle time.

I contend you don’t have enough information to answer the question. To really do that, you need to get your safety glasses and hearing protection, go down to the machine with a stopwatch (I’d suggest one with a lap function) and click off the elapsed time interval between each and every part as it come off the machine.

Why?

Well… let’s say that the machine is actually running at a cycle of 55 seconds / part when it is actually operating, but there are frequent jam-ups that the operator has to clear.

Isn’t that a completely different story than running smoothly with one part coming off every 65.45 seconds?

Think about it.

A Tale of Two Sites

With apologies to Charles Dickens, but the opening line is just too good to resist…

The Best of Times

In this plant, the advance team is chaired and actively led by the most senior manager on the site. He is actively coaching, he is actively being coached. He is questioning his own learning, seeking council, and acting on it.

They are clear that, while there may be general guidelines, they must learn by trying and experimenting. They cannot simply deploy a roadmap because they can only see the next mile on a 1000 mile journey.

They see it as a method to shift their culture away from its “tell me what to do” legacy and toward one of an empowered workforce that takes initiative and works on the right things, the right way.

There is no doubt among the leadership team that this is the path forward.

They are starting to apply the language of the Improvement Kata informally in their meetings and discussions.

Overall, it seems a bit messy. But learning is like that.

The Other Site

The “implementation of Toyota Kata” is a directive from the corporate Continuous Improvement team.

The corporate team spends much of their energy developing and deploying templates, PowerPoint presentations, setting standards for the forms and the layout, lettering and colors on the improvement boards, and setting milestones.

They have published a step-by-step procedure for a site to implement Toyota Kata, based on their assumptions of what ought to work. None of them has actually led a change like this.

They are, in turn, working through the site continuous improvement team who is expected to execute to these standards.

The site leader receives weekly reports on progress. Training the managers and “implementing Toyota Kata” is the responsibility of one of the site’s continuous improvement staffers. The site leader questions him using the 5 Questions each week, and issues direction in response to the answers.

It is the continuous improvement practitioner who is responsible for motivating the members of the management team to challenge their own processes and develop their improvement boards. A significant number of them are questioning the need or purpose of this exercise.

Thoughts

Unfortunately I run into the second case far more often than I see the first. But the story is decades old. That is how we did Six Sigma, kaizen events, Theory of Constraints, Total Quality Management. In each case we have separated the deployment of a core change in the way we manage operations from the responsibility for actually managing.

It

doesn’t

work.

This TED talk by Tim Harford actually sums up the difference pretty well:

But beyond what works, and what doesn’t, we also have to ask “Which approach is respectful of people?”

What are the underlying assumptions about the people at the gemba when “standards” are established thousands of miles away, published, and then audited into place?

Why do they feel they must tell people exactly what to do?

What do they feel is lacking on the site?  Competence? or Clarity?