What Can You Do For Me?

I have probably written around this question in the past, but it comes up often enough that I wanted to address is specifically.

One of the challenges facing the lean practitioner is the “What can you do for me?” boss (or client).

This manager wants to know the expected ROI and outcome of your proposal before he agrees to make the investment in improvement.

This style of proposal-evaluation-decision management is exactly what is taught in every business school in the world. The process of management is a process of deciding between alternative courses of action, including no action at all.

This approach actually creates “no action” as the baseline. Any change is going to disrupt the status-quo and incur some kind of cost. Therefore, the thinking goes, the change better be worth it. “Am I going to get enough back?”

“What can you do for me?” implies a general sense of satisfaction with the status quo.

The lean thinker reverses this model. The status quo is a stagnant and dangerous place.

There is always an improved state that we are striving for.

Rather than measuring progress from the current state, we are measuring remaining gap to the target, and we must close that gap.

There are problems in the way.

Proposed solutions to those problems are evaluated on (among many other things) cost to see if the solution is an acceptable one, or if more work is required to find a better solution. But maintaining the status quo is not on the table. The decision has already been made to advance the capability of the organization. The only decision is around how to do it, not whether to do it.

So when a legacy GM style manager asks “What can you do for me?” the question must be changed to “What are you striving to achieve?”

Challenging the complacency of the status quo is our biggest hurdle.

Recovering the Reasons for 5S

5S has become an (almost) unchallenged starting point for converting to lean production. Although the basics are quite simple, it is often a difficult and challenging process.

After the initial push to sort stuff out and organize what remains, sustaining  often usually almost always becomes an issue.

Again, because of early legacy, the most common response is what I call the 5×5 audit. This is a 5×5 grid, assigning 5 points across each of the “S” categories. It carries an assumption that managers will strive for a high audit score, and thus, work to sustain and even improve the level of organization.

Just today I overheard a manager trying to make the case that an audit score in his area ought to be higher. It was obvious that the objective, at least in the mind of the manager, was the audit score rather than solving problems.

The target condition had become abstract, and 5S had become a “program” with no evident or obvious purpose other than the general goodness that we talk about upon its introduction.

If the audit score is not the most important thing, then why do we emphasize it so much? What is our fascination with assigning points to results vs. looking at the actual results we are striving to achieve?

To digress a bit, many will say at this point that this is an example of too much emphasis on audits. And I agree. But this is more common than not, so I think of this as an instance of a general problem rather than a one-off exception.

Our target condition is a stable process with reduced, more consistent cycle times as less time is spent hunting for things. Though we may see a correlation between 5S audit scores and stability, it is all to easy to focus on the score and forget the reason.

Shop floor people tend to be intelligent and pragmatic types. They do not deal in a world of abstraction. While the correlation might make sense to a manager used to dealing in an abstract world of measurements and financials, that is often not the case where the work is actually done.

The challenge is: How do we make this pragmatic so it makes sense to pragmatic people?

Let’s start by returning the focus to pragmatic problems. Instead of citing general stories where people waste time looking for things so we can present a general solution of 5S, let’s keep the focus on specifics.

What if (as a purely untried hypothetical), we asked a team member to put a simple tick mark //// on a white board when he has to stop and hunt for something, or even dig through a pile to get something he knows is in there? If you multiply that simple exercise times all of the people in the work area, add up the tick marks every day, and then track the trend, you may just get more valuable information than you would with the 5×5 audit done once a month.

What if we actually track stability and cycle times. Isn’t this avoiding these wastes the case we make for 5S in the first place?  So perhaps we should track actual results to see if out understanding is correct, or if it has gaps (which it does, always).

What if we taught area leaders to see instability, off-task motions, and to see those things as problems. Let them understand what workplace dis-organization causes.

How about tracking individual problems solved rather than a general class of blanket countermeasure?

How many sources of work instability did we address today? I’d like to see what you learned in the process. What sources of instability did you uncover as you fixed those? What is your plan to deal with them? Great!

No problems today? OK – let’s watch and see if we missed anything. OH! What happened there? Why did we miss that before? Could we have spotted that problem sooner? What do we need to change so we can see it, and fix it, before it is an issue with the work?

These are all questions that naturally follow a thorough understanding of what 5S actually means.

But we have had 5S freeze dried and vacuum packed for easy distribution and consumption. At some point along the way, we seem to have forgotten its organic state.

Keep Visual Controls Simple

In this world of laser beams and ultrasonic transducers, we sometimes lost sight of simplicity.

Remember- the simplest solution that works is probably the best. A good visual control should tell the operator, immediately, if a process is going beyond the specified parameters.

Ideally the process would be stopped automatically, however a clear signal to stop, given in time to avoid a more serious problem, is adequate.

So, in that spirit I give you (from Gizmodo) the following example:

Warning Sign

What Have You Learned?

“What have you learned?” It is a question I hear often at the end of kaizen events and other improvement activity. The key points of a typical report-out, though, seem to be on how much was accomplished, and what was learned comes as an afterthought.

A typical week-long kaizen event is organized like this:

Monday: There may be some classroom type training followed by studying the process. This study is often collecting cycle times and building spaghetti charts.

Tuesday: The team develops their vision or target state – they decide what they are going to do.

Wednesday / Thursday: Make some pretty dramatic changes to the process.

Friday: Report the results followed by pizza for everybody.

The pre-planning often includes some targets for cycle time or inventory, and sometimes even qualifies as a “target condition” that is focused on larger level objectives. But equally often, it doesn’t. The target results are vague or simply “Look at this process and improve it.”

Here is a question – how many coaching cycles – instances where a situation was understood, a target was established, an attempt was made to hit the target, and learning was assessed – actually happen in the course of this week?

In the worst case, zero. Those are the instances where the Friday report-out is followed on Monday by leaving work team to bask in their newly improved process. There is no attempt at all to see what they are struggling with, or if there is, it is an “audit” with the idea of “ensuring compliance” with the new process. No learning at all takes place in this situation. There is only blame shifting.

Nearly as bad is when the answer is “one.” That is, there is some attempt prior to Friday to see if the target condition is achieved, and to understand what new issues have emerged. The problem here is that it is usually too late to do anything. The improvement experts are moving on to planning another event, and whatever is left behind is usually an action item list of incompletes from the week.

That doesn’t work very well either.

Neither does trying to capture “learnings” on a flip chart at the end of the event. That is a nice feel-good exercise, but rarely translates into improving the process of process improvement

So if the above is a “current condition” then what is the target?

How can improvement itself be organized so that we learn how to do it better?

One thing would be to structure kaizen events to cycle through the coaching process many more times during the week. Take the five day agenda, and carry it through EVERY day. That is a start. How would your kaizen events be different if you did five one-day events in a row rather than one five day event? Isn’t that close to one-piece-flow?

What would be the next  step after that?

What Failed Today?

Now and then, usually when coaching or teaching someone, I get what I think is a flash of insight. Then I realize that, no, there is nothing new here, it is just a different way to say the same thing. Still, sometimes finding a different way of expressing a concept helps people grasp it, so here is one I jotted down while I was working with a plant.

One of the myths of “lean production” is the idea that, at some point, you achieve stability in all of your processes.

Nothing could be further from the truth.

Failure is a normal condition.

The question is not, whether or not you have process breakdowns.

The question is how you respond to them. Actually, a more fundamental question is whether you even recognize “process failure” that doesn’t knock you over. Our reflex is to try to build failure modes that allow things to continue without intervention. In other words, we inject the process with Novocain so we don’t feel the pain. That doesn’t stop us from hitting our thumb with the hammer, it just doesn’t hurt so much.

But think about it a different way.

“What failed today?”

Followed by

“How do we fix that?”

Now you are on the continuous improvement journey. You are using the inevitable process failure as a valuable source of information, because it tells you something you didn’t know.

There is a huge, well established, body of theory in psychology and neuroscience that says that we learn best when three things happen:

  1. We have predicted, or at least visualized, some kind of result.
  2. We try to achieve that result, and are surprised by something unexpected.
  3. We struggle to understand what it is that we didn’t know.

In other words, when we (as humans) are confronted with an unexpected event, we are flooded with an emotional response that we would rather avoid. In simple terms, this translates to “we like to be right.” The easiest way to “be right” is to anticipate nothing.

This takes a lot of forms, usually sounding like excuses that explain why stability is impossible, so why bother trying?

Why indeed? Simple – if you ever want to get out of perpetual chaos, you first have to embrace the idea that you must try, and fail, before you even know what the real issues are.

When Can I see?

One of the issues Mike Rother says he has had with the coaching questions in Toyota Kata is question #5 “When can we go see what you have learned?”

In the west, inevitably it seems, once the word “When” is uttered, everyone in the conversation leaps to hear “When will you be done?” no matter how the question is actually framed.

As I am understanding it right now, the actual intent is for the coach to establish two things:

  1. The PDCA cycle needs to be turned rapidly. “When…”? is meant to establish a time fame that might be measured in hours, or even minutes, rather than days or weeks. The more quickly the PDCA cycle is turned, the more thoroughly the problem is understood and the more robust the countermeasure.
  2. “What we have learned…” means “What surprises did you encounter?” “What went differently than you expected?” “What didn’t work the way you thought it would?” this part of the question is intended to drive home the point that it is these things, not the success, that drive deeper understanding plus give clues about the next problem that must be addressed.

Based on Rother’s experience with this question, I am tinkering with how to re-frame it so I can use it more effectively. Ultimately the behavior I want is an invitation to jointly observe how the proposed countermeasure has changed the process. We want to understand the actual effect vs the intended effect.

That, of course, requires that the intended effect is understood and explicitly stated before trying. That does NOT mean that every little step is documented on paper such as an A3. That is far too cumbersome at this level of granularity. We want this process to cycle faster than the time required to write this stuff down. It does mean that I would have evidence that it has been thought through rather than just blindly trying something.

What you can, Where you can

In my review of Toyota Kata by Mike Rother, I suggested that the staff-level practitioners who are embedded in almost every company that is “implementing lean” could put those practices to work immediately, even if it was not an ideal “top down” teaching process.

This week I gave that a try.

I was coaching a workshop leader who was, in turn, leading the team I mentioned earlier. He was simultaneously reading the book, I referred him to “the coaching questions” on page 247 and we worked together to keep asking them as the team was doing its work.

Since the team was working to solve problems that were blocking the problem solving process, it got a little complicated to keep them focused on the right “immediate problem.” However what I observed, for sure, was that my workshop leader’s skills improved significantly as the week went on, as did the team’s understanding of the issues and countermeasures.

My working theory was that just asking the questions puts someone into “teaching mode” and, as I have said earlier, the best way to learn is to try to teach.

Was this the ideal approach advocated by Mike Rother? Nope. I will have to loop back and catch some of the foundational elements. But as I have experienced in the past, these practices are so powerful that even trying and awkward application gets significantly better results than following no structure at all.

Start asking the questions, and see what you can learn as you try to teach.

Using the Questions

This week I am coaching a kaizen team in the first phases of implementing a process to respond to problems on the shop floor.

They clearly understand the objective, and are working hard.

The key is to keep them focused on working out the problem response process vs. getting distracted by the production problems they are responding to.

For my part, in an effort to accelerate the cycles of learning, I am trying to consciously apply “the five questions" of the coaching cycle as outlined on page 247 of Toyota Kata by Mike Rother.

They are:

  1. What is the target condition? (the challenge – what do we expect to be happening)?
  2. What is the actual condition now?
  3. What problems or obstacles are now preventing you from reaching the target condition? Which one are you addressing now?
  4. What is your next step?
  5. When can we go and see what we have learned?

This will not be my only opportunity – I have other challenges lining up in other parts of the company that I support.

I’ll tell you, though, it isn’t as easy as just asking the questions.

The first challenge is context. My actual condition is that this kind of rigor is new to even experienced kaizen practitioners out there. As Rother, and others, point out, most “kaizen events” simply aren’t structured this way.

There is a strong bias toward generalization and sweeping statements of "problems” and “what we need to do is…” I have to keep working to bring the focus back to what is directly in front of us as we try to work through this specific iteration. Yes, that other thing might be an issue, but it isn’t coming up NOW, so let’s keep working on what is actually stopping us.

This is important because it gives the problem solvers great power. If they can learn to stick to what is stopping them right now, they have an easier time not getting discouraged by all of the other issues that are out there.

One-by-one. Step-by-step.

Of course this iteration is complicated by the fact that we are working on a process designed to clear problems in another process, so it is easy to get sucked in to the production issues.

To their credit – we have a Home Depot technology andon light, and the team members who are the subjects of this experiment seem to be appreciating (for now) the fact that this group of people is swarming every issue they run into.

“We CAN’T Just Stop The Line!”

I suppose, at some level, that makes emotional sense. After all, the idea is to keep production moving.

But the logical follow-on question is: “OK, so if the team member encounters aproblem that is going to force her to work around things, to do the work in a way that wasn’t planned, what do you want her to do?