Tag: People Development

Posted on

Embracing instability

Kaizen is largely a drive toward stability – that is a more consistent operation, producing a more consistent result. The key is the definition of “consistent.”

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.

Posted on

Kaizen vs. Kaizen “Events”

I got an interesting email from a friend a while ago, and am finally finishing up this post about it. Some months ago, he joined a new company and wrote about his impressions of some of the legacy he was walking into:

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

Posted on

PDCA, A3 and Practical Problem Solving

Over the years, I have been party to at least three corporate-level efforts to bring “A3” or “Practical Problem Solving” into their toolbox. Sometimes it has other names, such as “Management by Fact” or such, but the approaches are all similar.

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.

Posted on

Results

Past Due Hours

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.

hours-past-due-sm

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:”

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.

Posted on

Policy Deployment and the Coaching Chain

Gosh, I guess it is a couple of weeks ago now (I’ve been up to my eyeballs in work), Gerd Aulinger posted this presentation up on the Lean Enterprise Institute’s “Kata” page:

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.

 

 

Posted on

Mike Rother Overview of Toyota Kata

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

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

My thoughts are below the video…

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

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

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

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

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

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

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

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

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

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

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

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

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

Mike Rother has other videos on YouTube as 734Mike.

Posted on

Constraints Push Innovation

This Ted Talk by Amos Winter is about a fantastic project to develop an inexpensive, rugged, rough-terrain wheelchair for people in countries with much less infrastructure than we take for granted in the U.S. and Europe.

Though they didn’t follow the traditional “3P” approach, their project did reveal a few key elements. More below the video.

What Winter talks about as constraints:

  • Cost < $200
  • Parts readily available
  • Repairable by local trades (bicycle shops)

we could also talk about as a “target condition.”

Winter describes an iterative design process where the first two attempts failed once they got them into the hands of actual users. A valuable lesson – the only true “voice of the customer” is the customer!

The “Marshmallow Challenge” (in the link back above) describes the power of an iterative process within a constrained design space as well – though the most rapid learning occurs in a group that may surprise you.

A company I worked for got a challenge from Mr. Nakao of Shingijutsu: “Make your next year of aggressive growth with:

  • No more people.
  • No more space.
  • No more money (capital).

In other words, squeeze it out of the waste that is all around you. That was a year of intense learning for all of us, but even today that company has one of the highest value-add per unit of area I have seen in any plant, with operations reaching inventory turns in mid-to-high double digits.

The experience of “constraints driving innovation” also plays out in a client project I have been involved with. They set out a challenge for themselves that was very aggressive – an order of magnitude difference from their current baseline. Then they set out to meet that challenge.

Past history (they tell me) has been to routinely break the “constraints” in these projects, but this time around they are sticking to their own rules.

What has emerged a large wall covered with major sub-goals, each with its criteria (the target condition), the current level of performance, the gap, the next trial they expect to run, the expected result.

They have been working hard to try to reduce the cycle time of those experiments: What can we do with what we have; What can we do for free or cheap rather than waiting until everything is here?

The key point here is that a well focused challenge can align people’s efforts and keep them focused on the objective.

The best challenges are the ones that come from within.

What are you striving for?

Posted on

Finding Patterns

“What is your target condition?”

“One-by-one flow, meeting an 11 minute planned cycle time, with two people.”

“What is your current condition now?”

“We are making rate, but our lowest repeatable times add up to 28 minutes, and with that and the 32% variation we are seeing, we need 3 people on the line to do it consistently.”

“Where is all of that variation coming from? What are people struggling with?”

“All of the assemblies are different!”

And this was kind of true. We had five different larger assemblies firing in a repeating cycle:

A, B, C, A, D, E, A, B, C, A, D, E

And to make the discussion more interesting, each of these items has four sub-assemblies, of different types, that go into it. This line was building those sub-assemblies in a sequence that matched the need. So it is easy to see why all of that variation seemed overwhelming.

But there was commonality, a lot of it. The operations were very similar, with the differences being things like:

  • A left-hand or right-hand difference.
  • An operation is included, or excluded from a particular sub-assembly.
  • Differences in geometry that had little or no bearing on the actual operations being conducted.

My goal was to lead them to doing more detailed observations, seeing the blind assembly operations, chaotic layout on the bench, the occasional hunt for information, and at this point, the learning curve the assemblers are still coming down as we identify key points.

We are hard-wired to see differences in things – that blade of grass is bent, is there a tiger there? Sometimes it is more challenging to seek out and become aware of the underlying patterns. In other words, what these items have in common.

Rather than looking at obstacles to build the parts, we want to look at the obstacles to smoothly carrying out the operations. It is a subtle difference, but an important one. Sometimes you have to search through the noise to find the signal.

As of this writing, the bench is getting better organized, tools are getting homes, and some assembly aids and tools are being developed to avoid having large fingers trying to get things done in small places.

The work is starting to stabilize enough that the patterns are becoming more visible, which allows capturing the work breakdown in a rational way that can be taught – first the base industrial skills, then the common operations, then the sequence of those operations for specific parts.

We’ll get there.

Posted on

Obstacles vs. Lists of Tools

I have been noticing a significant linguistic difference between those who still embrace the “implement the tools” paradigm, and a much smaller (but growing) group are are adopting the PDCA thinking structure as a framework for everything else.

It comes down to how a problem is stated.

We were looking at an operation with a lot of variation from one team member to another, both in terms of performance, and actually, what precisely was being done.

When asked what the obstacle was, the immediate reply was “Lack of standard work.”

While this may have been true, it is not a statement of the problem. Rather, it is defining the problem as “lack of a specific solution.”

This may seem to be an semantic discussion, but consider what the responsible supervisor hears, and interprets, from these two statements:

“There isn’t any standard work.”

or

“There is a lot of variation from one operator to another.”

In the first case, we are telling the supervisor what she isn’t doing, hasn’t done, needs to do. It isn’t even teaching.

In the second case, we are pointing out something that we can both agree on. I haven’t even said it is a problem, and honestly, in some cases it might not be (yet). It is a simple observation.

If, then, we agree that this variation is leading to some undesirable effect, then we can talk about countermeasures. That might include trying to capture a baseline, teach it to a few of the team members, and see if that helps. We can name it later.

Which of those approaches is more likely to enlist the support of the supervisor, which is more likely to put her on the defensive?

Lean thinking is not a checklist of which tools are in place. It is a step-by-step convergence on smoother flow, dealing with observed obstacles and problems.

This isn’t to say that the coach doesn’t have intimate knowledge and experience with flow, with standard work, and everything else. But the approach must be respectful of the people who are struggling with the real world issues every day. Saying “You need to implement standard work” isn’t helpful no matter how much logical justification is wrapped around it.

Teaching someone to observe the impact of variation on the process might seem slower, but it will get them there much faster because it engages their curiosity.