I came across this old fable again recently.

So much of it applies to the improvement culture – especially if you run your equipment all the time to “maximize your output”

Once upon a time, a very strong woodcutter asked for a job in a timber merchant and he got it. The pay was really good and so was the work condition. For those reasons, the woodcutter was determined to do his best.

His boss gave him an axe and showed him the area where he supposed to work.

The first day, the woodcutter brought 18 trees.

“Congratulations,” the boss said. “Go on that way!”

Very motivated by the boss words, the woodcutter tried harder the next day, but he could only bring 15 trees. The third day he tried even harder, but he could only bring 10 trees. Day after day he was bringing less and less trees.

“I must be losing my strength”, the woodcutter thought. He went to the boss and apologized, saying that he could not understand what was going on.

“When was the last time you sharpened your axe?” the boss asked.

“Sharpen? I had no time to sharpen my axe. I have been very busy trying to cut trees…”

In the real world, this kind of decline happens much more slowly.

And it happens well beyond the context of equipment and maintenance.

If you don’t work to continuously improve your processes, they are degrading. You can’t just “standardize” your way to stability.

 

“True North” – Explicit or Intrinsic?

compassOne of the factors common to organizations that maintain a continuous improvement culture is leadership alignment on an overall direction for improvement – a “True North” – that defines the perfection you are striving for.

Steve Spear describes Toyota’s “Ideal” as:

An activity or a system of activities is IDEAL if it always produces and delivers:

(a) defect-free responses (those that meet the customer’s expectations),

(b) on-demand (only when triggered by the customer’s request),

(c) in batches of one,

(d) with immediate response times,

(e) without waste, and

(f) with physical, emotional, and professional safety for the supplier.

(From The Toyota Production System: An Example of Managing Complex Social / Technical Systems, Steven Spear’s PhD dissertation, 1999, Harvard University)

You (and I) can quibble about some of the semantics, but overall, this is a pretty good list.

Mike Rother (not coincidently, I am sure) puts up something quite similar in Toyota Kata:

…Toyota has for several decades been pursuing a long-term vision that consists of:

  • Zero defects
  • 100% value added
  • One-piece-flow, in sequence, on demand
  • Security for people

Toyota sees this particular ideal-state condition – if it were achieved through an entire value stream – as the way of manufacturing with the highest quality, at the lowest cost, with the shortest lead time. In recent years, Toyota began referring to this as its “true north” for production.

As I have tried to emphasize the importance of a leadership team having a clear sense of “True North” I have noticed that many of them get bogged down in trying to develop and articulate a concrete statement. (This is partly my fault, and I am revising my training materials to reflect what I am writing here.)

What I am realizing is that this is more of an “attractor” than a rule set. Let me explain through a bit of digression.

When we see something, we have an immediate emotional response. Generally it is attraction toward something we see as good (or are curious about); or avoidance of something we see as fearful or dangerous.

We construct a logical reason for that emotional reaction several tenths of a second after that emotional reaction is firmly anchored. Thus, our logic follows, rather than driving, our responses to things. This happens so fast that we are not usually aware, but two people seeing the same thing can respond very differently based on their individual background and experience. I don’t want to dive too deeply into psychology here, so I’ll pull back out of this.

“True North” sets the direction of process improvement because there is high alignment on what kinds of process changes are attractive vs. those which should be avoided. When I say “attractive” I mean “we want to actively move toward them” meaning the organization will expend energy, ingenuity, and resources to do so. This is how continuous improvement is driven.

If I am right, then “True North” is more of an “I know it when I see it” kind of thing than it is a carefully articulated statement.

If I look at other businesses who are (or have been) pretty well aligned with their efforts, I can see the same kind of thing.

For example, though I doubt that it is articulated internally in this way, it has been pretty clear to me “Windows Everywhere” has been something that sets (or set) overall direction within Microsoft. (I’ll admit I don’t have as strong a sense of this as I did in the late 1990’s when my social circles included a number of people who worked there.)

A local hospital does articulate theirs, but it also makes sense: “No wait, no harm.”

Most organizations I have dealt with, though, don’t have a good sense of long-range perfection. They are mired in the details of today, tomorrow, this quarter.

They might have some kind of “vision” or “mission” statement, but often those are paragraphs that are carefully constructed to address constituencies (“Satisfying our customers while delivering maximum shareholder value and being a great place to work, blah, blah”)

Those “visions” though are rarely actively used to guide conversations or decisions, much less continuous improvement.

Since I believe this is a gap these teams need to close if they are to shift toward a continuous improvement culture, I need to improve how I am getting this across to them.

So… the next thing I am going to try is to rework my “True North” instruction and do a better job of framing it as something to actively move toward rather than something to try to logically articulate.

“True North” may be more of a feeling rather than a logical test.

This means that the job of the teacher / practitioner / change agent is to hold on to that “True North” during your coaching until the leaner “gets it” and starts actively seeking solutions that move in that direction.

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?

One-By-One; On Demand; As Requested

Once again we see another data point on the trend.

Why is “batching more efficient?”

Simple – you haven’t solved the problems yet.

Here is an ice cream shop that has no ice cream… until you order it.

Does this shop surface the next layer of issues to solve? Certainly. But by thinking it is possible and they trying it, she is learning fast.

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.

TSA Kata

Robert Heinlein observed (through the HOLMES IV computer character in The Moon is a Harsh Mistress) that “humor” often centers around the misfortune of others. I’ll make this little story topical by hypothetically applying the “coaching kata”…

This wasn’t me, just something I witnessed. If only people would apply PDCA to real life… If I were coaching this guy, it might go something like this:

“What is your target condition?”

“To get to the gate for my flight.”

“What is your current condition now?

“In the TSA security checkpoint.”

“What obstacle are you addressing?

“The TSA wants to do a secondary screen on me, delaying my passage through the checkpoint.”

“What was your last experiment?”

“I raised my voice and became indignant, accusing them of not knowing what they were doing.”

“What result did you expect?”

“That they would understand they were wrong, and let me pass.”

“What actually happened?”

“A lot more TSA agents showed up, along with a police officer.”

“What did you learn?”

I think the trajectory is pretty clear from this point…

What is the ROI for That Log?

I still see companies struggle to apply a financial return on every improvement proposed.

PC has made an excellent analogy in a post on the forum. Rather than repeat it here, I’ll give you the link, maybe we can get a conversation started.

http://forums.theleanthinker.com/viewtopic.php?f=9&p=903#p903

(Sidebar: I am pretty aggressive about deleting accounts that look like spammers. If I got yours by mistake, write to me at “Contact Mark” on the right sidebar, and I’ll fix it.)

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.

Appearances vs. Reality

I’m looking at a form labeled as an X-Bar / R-Bar SPC chart. It is filled out pretty consistently by the operators.

But the “control limits” are actually specification limits, and the “standard deviation” looks like it is calculated as 1/3 x the spec limits to force the lines to where they want them from the mean… er ah… nominal.

When I asked about it, at least one company leader was under no illusion that this was a statistical process control, it is simply a means to develop a run chart of actual parameters vs. a nominal value and the specification limits.

I’ve seen far worse, like the time an engineer didn’t understand the difference between “in control” and “in specification.”

But what do they say in their everyday conversations? Do they talk about this process being “within specification” or “in control?” I expect the later.