I had the same sandwich, prepared by the same worker each day.

Monday he put the mayo directly on the chicken salad, on his left.

Tuesday he put the mayo in the other piece of bread on his right.

Then I smiled at myself wondering why on Earth I even noticed that, all the while conversing about something unrelated.

Note to self: get brain checked and turn down the gain a bit. 

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

The Weird Stuff We Notice

Overproduction is a way to achieve the illusion of consistency in the face of inherently unstable operations. Your machines are unreliable? Run faster when you can run. Inconsistent quality? Make more stuff so you have enough good ones.

And you know what? If my machines are unreliable, I do run faster. I put in buffers of time and material. I have to, because at the end of the day, I need to satisfy the customer.

The difference is in what I am trying to do, and how I define “stable.”

If I were to define “stable” as “I don’t have to pay attention to this” then my natural reaction will be to bury the problem by building in accommodations – things I “have to do” because “the process isn’t stable.”

Once there are sufficient accommodations in place, I, as a manager, could shift my attention elsewhere.* We all know the downside of this – those problems accumulate, and eventually the system fails completely. But our brains are programmed to assign cause to recent events, even if they were simply the tipping point.

The reflex reaction, then, is to look at something that just happened, assume that was the problem (since everything was “fine” before), and find a short term fix to make it go away.

I see this quite a bit. That is why I am now quite… inquisitive about the ongoing process improvement efforts if I hear a target condition as some level of performance, and “the process is stable” as the current condition.

No problem is a big problem.

*I may very well put in a temporary countermeasure so I don’t have to deal with all of the obstacles and problems at once. It looks the same if you are touring the shop floor. The difference is intent.

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

Embracing instability

[before my arrival, the company] used Xxxxxx consultants to get their Lean effort up and running. 

They were given training modules that are 30-40 slides long and unbearable to sit through. 

They were taught a very rigid approach to kaizen that focuses more on strict standards than helping to improve performance. 

As a result there are deep divides between some of the groups here and the Lean team.  It’s unbelievably frustrating to see how much money was spent learning an approach to Lean that is outdated and ineffective.

Actually, it was worse than ineffective, it was detrimental in a lot of ways.  There are numerous areas we have to dig ourselves out of a hole that was created by events that absorbed substantial resources for zero long term gain.

He goes on to ask for a discussion on The Lean Thinker…

[…] about the event and tools based approach versus the daily problem solving approach.

And goes on to observe:

There is still a deep divide in the Lean world as to which is the best method.  It’s seems to me that there are more people on the event and tools side of the fence than there are on the daily problem solving side of the fence.

I included these quotes because this is a real perception from the real world. My friend recognizes the need to adopt daily improvements driven by line leaders.

What he sees, though, is that these kaizen events didn’t (in his view) transfer those skills, or that behavior, to the organization.

There is nothing unusual about the process described above. I was taught pretty much the same thing: A “kaizen event” is about a specialist workshop leader planning and conducting the event “to the standard.”

Who are you developing?

This approach does develop a skill in the organization.

A relatively small group of people (usually the promotion office staff) get pretty good at planning and running kaizen events following whatever standard is in place.

They get good at it because they are the ones who plan and run those events, over and over. In other words, they practice.

That, of course, begs the question: Who are you developing?

I’ve seen (and been in) a number of companies who strive to have “every team member participate in at least one kaizen event a year.” In a plant with 250 team members, at 8-12 of them participating in a typical kaizen event, that works out to something like 25 kaizen events a year, or a bit more than two a month. A typical promotion office staff in a plant this size might be able to keep up with that rate, but I have seen more struggle to do so than succeed.

So with this tempo of kaizen events, each team member gets to participate in an improvement activity roughly once a year.

Granted, a lot can get done over the course of that week. But the other 49 weeks are business-as-usual, so business-as-usual is what they are learning.

Put another way, if you want to get good at skiing, it is going to take more than one week on the slopes every winter.

More Important: What are you striving for?

This is really the same question I asked above, but in the context of the purpose of your kaizen events.

What was that consultancy striving to do with their client?

What was the client striving for?

My guess is both were pushing hard for rapid measurable results – an immediate and visible return on the investment.

But if you are striving to develop leaders, then the kaizen event takes on a completely different tone. (Note that when I say “leaders” I don’t limit myself to people in formal leadership position. I mean anyone who is willing and able to step up to a challenge, and enlist the help of others to meet it.)

There is also a very different expectation for what happens after a kaizen event. No longer do we have lists of actions to complete. Rather, we have the current obstacle we are working on, and the next experiment that is going to be conducted on Monday.

The key is that a kaizen event has to kick-start a change in the daily routine that goes above and beyond changing the work. I’ll go so far as to say that changing the work is secondary. If you can kick start getting improvement as part of the daily work, then the work itself will improve quickly enough.

Your measure of success, then, is not the results you get during the kaizen week. It is whether or not you can sustain the rhythm of improvement thereafter.

Just some things to think about.

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

Kaizen vs. Kaizen “Events”

Typically these efforts, if they catch on at all, become exercises in filling out a form.

Actually, that shouldn’t be a surprise, because they are often taught that way – as process of filling in boxes in sequence, with a “module” for teaching each step.

Worse, it is often taught as an intellectual exercise, and once you are done with the three day class, you’ve been “taught.”

The various classes mention PDCA as being a crucial part of this process, but nobody really practices it.

People are sometimes taught that this process should be coached, but the “coaching” they get is typically organized as management reviews via PowerPoint.

The “problem solving team” shows their analysis and their “implementation plan” that is a list of tasks, and a timeline to get them done. The meetings become status reviews.

Sometimes the “coaches” offer suggestions and speculation about the problem, symptoms, or actions that might be taken. They rarely (if ever) get into the quality of the PDCA thinking.

This is one of the challenges we have in the west (and especially in the USA) where our culture is more one of “go it alone then get approval” rather than true teamwork with the boss. This often turns the “A3” into an exercise of getting approval for a proposal rather than a learning process.

Worse, it does nothing to teach the problem solvers to be better problem solvers.

Note that sometimes an A3 is used for a proposal, but the process of creating it is still coached, and part of the process is the consensus-building that happens before there is any meeting. But here in the west, we still seem to like to spring these things on a leadership team without a lot of that background work ahead of time.

Mike Rother and the “Toyota Kata” community have been discussing this gap lately, and working to close it.

The latest iteration is this SlideShare that Rother sent around today:

He clearly points out what people have been missing: The “A3” is really just another method to document the “improvement kata.”

The “Implementation” box, rather than representing an action item lists, is where the problem solver captures her PDCA cycles, what is being tried, what is being learned, as she drives toward the target condition.

The other boxes are capturing her understanding of the current condition, the target condition, and the impact of various problems and obstacles in the way of closing the gap.

One thing that makes this extraordinarily difficult: We are talking about more than the mechanics of problem solving here. We are talking about shifting the default, habitual structure of the interaction between people. That is culture, which is notoriously hard to change. Not impossible, but unless people are up front that they are actually trying to change at this level, there are a lot of obstacles in the way. This can’t be delegated.

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

PDCA, A3 and Practical Problem Solving

Among other obstacles identified, the first assembly step was being done on a bench. This required the assembler to stabilize the main part with one hand, position the part being installed with another hand, and hold the tool with… you get the idea.

The idea was to design and build a jig that would hold the main part steady, in the right orientation, at a good working height.

Iteration 1: Mock up the concept.

Rodney (the lean manager) and Maegan (the line team leader) are showing their first iteration of concept.

But even before this, their real first experiment was to hold the part by hand and test where it needed to be stabilized. The cardboard mock-up was a confirmation.

Iteration 2:

They experimented with contact points and hold points and made a few adjustments…

Iteration 3: Have a more robust version made out of wood, try it with an actual part.

Learned: The part isn’t stable enough to work on.

Next experiment: Add a clamp, and mount it to a tool stand.

Then Maegan tries it out.

What did we learn?

It is difficult to get the tools behind the clamp bar.

Iteration 4:

Next experiment: Modify the fixture (quickly) to raise the part higher.

Which seems to have done the trick.

This, plus a couple of other changes, got the cycle time under the 15 minutes, so one person could do this job.

All of this happened over less than a couple of hours, and it was in production that afternoon with immediate results.  A far cry from the traditional tooling and jig design process.

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

Rapid PDCA

This area was picked for the initial focus because they were way, way behind, and it was getting worse.

The initial work was done in mid-April. The target was consistent output at takt time.

As the team looked at the process, and identified the sources of disruption and variation, “changeovers” surfaced pretty quickly as a main issue.

“Which obstacle are you addressing now?” was the changeover times on the output process, so the target condition for the area’s team was to get the disruption to output for a change over down to a single takt time vs. the highly variable (up to 10 takt times or more) disruptions they were seeing.

One big mindset change was the concept of takt time. There was a lot of perceived variation in the run times of these parts. But upon study, the team realized the variation was a lot less than they thought. Yes, it is there, but over any given couple of hours, it all evens out most of the time.

As the team studied their changeovers, one of them had an insight that “We can do a lot of these things before we shut the machine down.” And in that moment, the team invented the SMED methodology of dividing “internal” and “external” changeover tasks.

Once that objective was grasped, they went to town, and saw lots of opportunities for getting most of the setup done while the last part was still running.

Their lot sizes were already quite small, the core issue here was the disruption of output caused by the increased tempo of changeovers. So that time was put back into capacity, resulting in the results you see above.

They continue to work on their changeover times, have steadily reduced the WIP between process stages, and (as you can see) keep outrunning their goals for “past due hours.”

But the really important bit here is that this was largely the team leaders, the supervisor, and the area manager. Yes, there was technical advice and some direction giving by the VP and the Continuous Improvement manager, but the heavy lifting was done by the people who do the work every day.

Consistent Output

This is from another company, in a completely different industry. Their issue, too, was that they were always behind. In this industry, the idea of a takt time is pretty alien. Even the idea of striving for a fixed level of output every day is pretty alien.

The team’s initial focus was maintenance time. They perceived that equipment reliability was causing them to fall behind in production, and so were shipping product to a sister plant every week to fill in the gaps.

The first question posed to them was “How much time is needed for production?”

In other words, they needed to figure out how much production time was “enough,” so they could then assess how much time maintenance could have. That would establish their target.

But in answering that question, they developed a takt time, then measured output cycles vs. that takt. What they saw was lots of inconsistency in the way the work was being done.

If they could hold to something close to their demonstrated lowest-repeatable cycle times, they could then know when they were “done” for a given shift, or day, and actually plan on maintenance time rather than seeing it as a disruption to production.

The focus shifted to the work cycles.

What is cool about this team is that the team leader / “learner” (in Toyota Kata terms) was the maintenance manager.

He gained a real shift in perspective. “Production” were no longer the people who wouldn’t let him maintain the machine, they were his customers, to whom maintenance needs to deliver a specified, targeted, level of availability as first priority.

The teamwork developed about the end of Day 2 of this intense learning week, and they have been going after “sources of variation” ever since.

Here is the result in terms of “daily output:”

As you can see, not only is the moving average increasing, but the range is tightening up as they continue to work on sources of variation.

The big downward spike on the right is two days of unplanned downtime. In retrospect, they learned two things from that.

1. After foundering a bit, they applied the same PDCA discipline to their troubleshooting, and got to the issue pretty quickly. As a sub-bullet here, “What changed?” was a core question, and it turned out someone had known “what had changed” but hadn’t been consulted early on. Lesson learned – go to the actual place, talk to EVERYONE who is involved rather than relying on assumptions.
2. Though they sent product out for processing, they realized they could have waited out the problem and caught up very quickly (with no customer impact) had they had more faith in their new process.

All pretty cool stuff.

These things are why this work is fun.

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

Results

I saw this placard on a drill press in a factory this week.

They don’t build them like this anymore.

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

A Bit of Living History

One team was having problems getting past the initial “sort” phase of clearing out unused stuff. They struggled with setting up any kind of visual controls, for example.

A couple of months ago, we focused on their workflow for introducing the PDCA improvement cycle (“kata”) to the area supervisor.

We were using a combination of observation of the actual work, running tabletop simulations to develop things to try out, and live experiments in the work area as we ran rapid PDCA cycles throughout the days. We were after concentrated reps so they could practice.

They still struggled until we finally got the tabletop simulation to flow. The supervisor “got it.” She said “Oh…. I can see the big picture now.” She had been bogged down in the details, and hadn’t been seeing that they could improve their productivity dramatically by slowing down to the planned cycle time.

Once they had a target work cycle, they then tackled obstacles that were in the way of making real life work like what they had simulated, working them one by one.

Along the way, they saw a need to make “what to do” visual, and build it into the work area itself vs. just “telling then” or (probably worse) writing some kind of procedure.

Suddenly 5S had purpose. It was to help communicate what to do next, and to help see if “what is happening” is different from “what should be happening.”

The key learning is that this is really difficult if you haven’t thought through “what should be happening” first.

This team is now has the highest 5S score in the company… because 5S has a purpose.

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

5S and Workflow

I
My
Me
We
Our

Vs.
He / She
Him / Her
His / Hers
You
Your
They
Them
Their

Who owns the problem or removing the obstacle?

The “first person” group tend to be far more proactive, and successful, at dealing with issues; where the “second and third person” leaders are satisfied once they can assign an obstacle to something outside of their immediate, personal control. They are even disconnecting themselves from their own team (if you can call it a team in the first place).

The “first person” group are quicker to get into a mode of curiosity and learning.

The “second and third person” group are generally satisfied with a superficial understanding. I find this group most frequently in cultures where leaders are primarily concerned with being able to explain the reasons for problems.

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

Pronouns of Ownership

I’m obviously interested in your comments as I had some amount of input into the final product.

For that, I would ask that you actually download the SlideShare, print it out, parse it, discuss it with others, and really pick apart what it means.

There is a lot in here, more than you find in a typical LEI workbook.

But I’d also like to discuss what I think are important points made here.

Continuous Improvement is a Line Leader Job

Though it isn’t stated explicitly, the very structure of this example only shows the roles of line leaders. You don’t see anything about kaizen events or rapid improvement workshops led by staff specialists here. Each leader is directly responsible for getting the process to the next required level of performance.

Improvement isn’t “What Can We Do?” It is “What Must We Do?”

There is a business imperative underlying this entire effort. They didn’t just make a value stream map and ask “Hmmm… how much better could we make this by taking out some waste?” Nope, this is driven by a need to get a level of performance that, today, they cannot achieve.

As a sidebar, please note that the “kaizen bursts” are on the FUTURE state map (slide 28) … they represent the OBSTACLES in the way of getting there, not “opportunities” on the current state map.

If you look at the target condition for the changeover, it is 14 minutes. There is nothing sacrosanct about a 10 minute changeover, that is just from the name of a book. They need to get changeovers to 14 minutes to get the process performance they want. It’s math.

Added, thanks to a comment from Kris:

“Catchball” is More About “How” than “What”

You will notice there is some back and forth – what is commonly called “catchball” in the dialog between the various levels of coaching. But they are not discussing the overall business imperative. They are discussing the obstacles, targets, and approach that will be taken to get there.

This is an important point because, in the early days, “catchball” was taught by many consultants as a negotiation of the objectives.

But Nancy’s objective isn’t negotiable. What might be negotiable is how much of her lead time objective gets carried by gear machining vs. the unseen conversation with assembly, a cap-and-trade of sorts, but in the end, her group is on the hook to hit her target.

The Entire Chain is Fractal

When Nancy asks Steve “Which obstacle are you addressing now?” he responds with the long changeover… while that changeover is the target condition between Steve and Roger.

Steve is working with Roger to break that obstacle, to hit the 14 minute changeover, thus this is what he tells Nancy he is working on now. The presentation doesn’t go into the further details of their discussion (heck, it is already up to 80 slides…), but I’d venture to say that conversation is going to be as much about how well Roger is doing figuring it out and his learning conditions as it is the process itself. Why? If Steve did it himself, Roger wouldn’t learn anything.

Continuous improvement is about continuously improving people.

At the next level down, Roger is addressing obstacles one by one.

Roger’s target condition of a 14 minute changeover breaks down to obstacles that he thinks are in the way of getting there. Each of them has an unknown solution, and so must be broken down systematically. The terms change, but the process is just getting finer grained. We finally get down to individual experiments to test an idea and learn more about the process.

Improvement is a Team Sport

There are a lot of sports analogies, heck, “kata” itself is a sports analogy of sorts. But the key is that this isn’t just giving someone an objective and having them report progress. Though the “coaching kata” seems ritualized, there is a lot of nuance.

As I mentioned earlier, a lot of novice coaches, especially those whose normal work patterns are to delegate the details, fall into the trap of thinking they can just recite the coaching questions and they are coaching. It actually takes a lot of practice reading how far you can push your learner today, what he is struggling with, knowing when to give direction, vs. give a hint, vs. let her try something that the coach is pretty sure won’t work but will be a learning opportunity.

That means the coach has to be able to see things the learner or improver might miss. Sometimes those things can only be seen from an outside perspective. That is why expert Olympic-class athletes have coaches. There are some details that cannot be seen from inside.

Being with people in a supportive but challenging way so they can learn and develop is one of the key elements of respect for people.

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

Policy Deployment and the Coaching Chain