Voice Interface Fail

I am in Germany, with a rental car, going places I have never been. To make this a little easier, I got a GPS unit.

One of the features of the GPS is that the voice turn-by-turn can be set in multiple languages. I (reasonably) set it to “American English.”

I have got to say that I have not heard such creative mangling of German street names since I was stationed over here in the Army.

Here is the irony: This little device, by the nature of its basic function knows exactly where it is. How about, people, programming it to speak the directions in English, but the street names in the local language.

Perhaps it would help if the designers actually tried to use the product in different countries.

This is a safety issue because I should not be having to suppress so much amusement when I am trying to navigate German traffic.  🙂

 

Trusting the Process

Here is an “ah-ha” or even one of those “oh s#!&” moments I had as Mike Rother was talking about his Toyota Kata research last week.

  Solution How Solution is Developed
Toyota / “Lean” Left Open Very specific – guided and directed.
Traditional Management Given / Directed Not specified, left to “empowered” employee.

When confronted with a problem, “traditional” managers have been taught to direct a solution, and leave details of putting it into place unspecified – “empowering” people to find the best way to work the details, solve the problems, and get it done.

“Toyota” or “Lean” managers, on the other hand, (if they are following the kata model – rare outside of Toyota I think), are going to be quite open about the solution, but very specific about the method used to develop and deploy that solution.

The result?

The two populations learn quite different things.

One learns to bypass obstacles, put the directed solution into place quickly.. git-r-done.

The other learns, through repetition, a thorough, adaptable, reliable and universal process for diagnosing a situation, seeing the root cause, and developing countermeasures that sustain.

The line I circled in my notes is “Kata must be content free.” meaning that if the method is carried out correctly, the solution will work to deal with the issue at hand. It is not necessary to specify a solution, only to hold the “true north” of what constitutes improvement and ensure that the process to develop the solution is carried out correctly.

An unworkable solution is a sign that the problem solving process was not applied correctly, not a flaw in the process itself.

OK – that all sounds good. What is the “ah-ha?”

How have many of us been “implementing lean” and “engaging people” by giving them targets in the form of specific tools to implement, and then leaving it to the “engaged team” to work out the details of how it will function in their situation? Which of the above two models am I using if I do that?

If I were to set an appropriate target, that takes the process closer to one-by-one, etc. and then to correctly guide the team through the process of understanding the current state, evaluating what problem(s) are blocking progress in that position, and methodically solve them they might or might not arrive at the tool I have in mind as the answer. Just to be clear – this approach is a lot tougher because there is another skill involved than just knowing how to make kanban work, or set up a u-shaped work cell.

There is a fine line as well between giving the team the solution and advising them on some things to try that will help them reveal more issues.

But in the end, if their solution works to close the gap, but uses a totally different approach, I have to be open to that possibility.

We lean “experts” have to play by our own rulebook.

Otherwise I am simply holding a wrench and looking for a screw to pound.

What Is The Problem (Again)

I am looking at a visual status display board. It has all of the usual things, safety information, 5S audit score, quality metrics.

The quality metrics display is pretty typical – there is a target trend line heading down, and a provision for bars representing actual. There is only one bar right now – it looks like this:

Clearly there is a target for next week that is lower than the results from this week.

Equally clearly is a desire to reduce defects by about half over a couple of months.

This is an effective way to display results.

But results of what?

As a manager, when I look at this board, there is one critical thing that is missing:

What are we doing to impact the outcome? What problems are keeping them from reaching the target now?

What problem are they working on at the moment?

What do they understand about that problem?

What reduction do they anticipate achieving if that problem is solved?

In a “Problems First” culture, we want focus to be on what problems we are working on right now. The results follow.

Even if the bars were marching along, ever lower, under the trend line, I am not satisfied unless I can understand why. What problems are being solved? Are they being solved the right way? Because I know it is impossible to measure yourself into different performance, I have to seek out understanding of what, exactly, is impacting these numbers. To do otherwise is to neglect my responsibility to verify that the issues are being addressed in the right way.

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.

Pull as Kaizen

Michael Ballé’s recent Gemba Coach column drives home the importance of understanding that all of the so-called “tools of lean” are really there to drive problem solving.

A well designed kanban system is (or at least should be) built to not simply provide a pull signal, but more importantly, to continuously ask, and answer:

  • “What is supposed to be happening?” (what is the target condition?)
  • “What is actually happening” (what is the current condition?)

and give at least a hint of the problem that needs to be addressed right now when there is an issue. As a minimum, what condition must be addressed right now, and the first “Why? to be investigated.

A couple of months ago I posed a hypothetical question about a team’s effort to put in a kanban process and asked for your thoughts and comments.

The scenario I described was, with one or two trivial changes, copied directly from pages 48 and 49 of the Lean Enterprise Institute’s latest workbook, Creating a Lean Fulfillment Stream.

Although the process as described would likely work (at least for a few items), I was really surprised to see an LEI book describe a process that explicitly and deliberately breaks the “rules of kanban” that they have published elsewhere, particularly in Lean Lexicon. The LEI did not make up the rules of kanban, they have been well established for decades. Thus, I have to admit that my first response was to question the credibility of the entire book (Lean Fulfillment Stream), even though there are many things in it that are worthwhile.

Many of you correctly called out issues with the mechanics. Now, in light of this new information, I would again like to invite comment.

If a good process should be set up to continuously ask, and reveal the answers to, those two questions, where does this kanban scheme come up short?

How would those issues cause problems with the processes that Ballé is describing in his column?

 

Automating the Coaching Questions

Hopefully that title got some attention.

In Toyota Kata, Mike Rother frames a PDCA coaching process around five questions.

The first three questions are:

  1. What is the target condition?
  2. What is the current condition?
  3. What problems or obstacles are preventing you from reaching the target?

Wouldn’t it be wonderful if we could build a machine that asked and answered those questions for us?

Of course automated processes do not improve themselves (yet). But they can be made to compare current operation against a standard.

When Sakichi Toyoda was working on automated weaving looms, he was actually striving to reduce the need to have an operator overseeing each and every machine. That was the point of automating the equipment. One of the problems he encountered was that threads break. When that happened, the machine would continue to run, producing defective material.

So in order to reach his goal, he needed to replace the need for a human operator to be asking these questions and give that ability to the process itself.

What is the target condition?

The loom continues to run and produces defect free material. For this to occur, the threads must remain intact.

What is the current condition?

The threads are either intact, or they are broken.

But if the machine cannot continuously ask, and answer, that second question then a human must do it. Otherwise, nobody gets to the third question, “What is stopping us?” unless they happen to notice the machine is smoothly producing defective material.

Since his goal was to reduce the need for human oversight, he had to solve this problem.

Toyoda’s (now classic, and still used) response was to put thin metal floaters on each thread. If a thread broke, the floater dropped, triggering an automatic machine shutdown.

The machine was now asking the second coaching question with each and every cycle, comparing the actual situation with the target situation.

The event of the machine shutting down triggered the attention of a human operator with the answer to the third question.

What problem or obstacle is preventing you from reaching the target?

Right now, there is a broken thread. I cannot produce defect-free material until this situation is corrected. Please assist me.

The process was named jidoka and in that moment, the foundation for what grew into the Toyota Production System was set.

Without reliable and consistent production, one-by-one flow and just-in-time are impossible. The options are to either work on the problem, or stop improving.

It is the leader’s responsibility to ensure that there are processes in place to do these things. Sitting still is not an option, there is nothing in these techniques that is a secret. Your competitors are doing it. It is only a matter of who can solve problems faster and better.

 

If The Student Hasn’t Learned…

The teacher hasn’t taught.

This article, titled “Why China is Not Ready for Lean Manufacturing” presents an account of trying to teach “lean manufacturing” in a Chinese factory. The experience is summed up in a couple of key paragraphs:

The team arrived in Dongguan and went to work giving an overview class on Lean techniques. The factory workers seemed attentive and interested in learning. The next day, the Silicon Valley Lean team gathered the people from the assembly line to begin the process of working on the quality problem. After 3 hours, the Lean team ended the session in utter frustration. No one participated. No one would identify problems on the line. No one knew how to approach gathering or analyzing data. No one volunteered.

So what happened? The training was adequate and the Lean principles and methods are sound and easily understood. Why weren’t the Chinese factory workers participating?

Why indeed?

The author’s conclusion is that Chinese worker’s culture and values conflict with the idea of collaboration and contributing ideas to improve production quality and efficiency.

But the article brought up two separate thoughts.

First, there is nothing magic about Western culture. These concepts can, and do, fall just as flat in the USA and Europe as they did in this factory. The problem in these cases has less to do with the national culture, and more to do with attempting to apply a rote approach to teaching.

Second, the result cited here was exactly the opposite of my own experience in a Chinese factory.

It took some persistence, and it took some deliberate steps to remove fear from the factory floor, but in the end we had these Chinese workers making some very innovative contributions.

400ArmBoringMock01 This photo is an old boring mill. It was a slow old boring mill. We needed to squeeze cycle time out of the process to make the projected takt time. We showed the workers some photos of other teams’ efforts to mock-up fixtures so they could quickly try out ideas. The workers, after a few false starts, constructed what you see here, and ended up with a pretty good set of fixtures that could be loaded and unloaded quickly. After some trials, they figured out on their own that they could fit two fixtures on the platform, which allowed them to be unloading and loading one while boring on the other.

400BucketBoring

One of the machinists complained that the machine could run faster if it had a liquid cooling system. With encouragement, he designed and built a simple, but working, cooling system for the cutting tools. (The steel box in the foreground with a pump on it.) The clever part was the chip filter made from a bottle cap and a nail.

400BucketCellMock01 Another team was working on a welding cell. They ended up designing and fabricating more efficient fixtures than had been provided by the engineers. Then they set out to develop the most efficient way to get parts positioned, to load them quickly into the fixture, and weld up the part.

 

 

What was different?400CellWorkDesign

First, we didn’t do any classroom education. Not quite true. We showed them photos of really good welding fixtures that had been designed by a sister company. That took about 30 minutes. We explained what features made those fixtures good. Then we continuously encouraged them to try things so they could learn on their own. And try they did.

We didn’t ask them to go beyond mock-up. We fully expected to take their ideas, turn them over to engineers to get them finalized and drawn up, then have the fixtures fabricated. But the workers took it on their own initiative to dig through the (embarrassingly large) amount of scrap metal out back, bring in what they needed, machine parts, scrounge others, and built their fixtures in steel.

A number of ideas were things I could clearly see would not work. I knew that heat distortion from welding would make a particular fixture design difficult (impossible!) to unload after welding. I could tell them it wouldn’t work, or I could let them try it on their own. I chose the path that would engage their curiosity and let them learn through experience. They became better welders for it.

Honestly – this was a slow time while we were working out other issues with market positioning, sales, design and sourcing decisions, and most of this activity was intended to keep people busy and engaged. But what we ended up with was production-ready work cells, all built upon ideas from the workers.

So why did I tell this little story?

First, I will admit that I was pretty proud of these guys. This was a few years ago now, but it was fun blowing away everyone’s stereotypes about Chinese factories and Chinese workers.

But I wanted to make a key point.

Instead of looking for cultural reasons why “this won’t work here” we kept faith that, if the initial response was silence and non-participation, there was something that we needed to address in the way we taught, and in the environment we were creating.

Indeed, what the Chinese culture brings to kaizen is a centuries-old tradition of improvising with what you have to get something done. This is a great strength that can be hard to find in cultures with longer traditions of wealth.

Just as we were encouraging these workers to try things so they could learn what did work, we had to do the same thing. We didn’t give up after three hours. Eventually we managed to remove the fear and bring out the best these people had to offer.

Classroom education is actually a very poor way to teach people how to study a process, understand it and improve it. Sometimes it kind of works, but I think that is because it is marginally effective if all of the other conditions are right. Perhaps in some cultures that starting point is past the limit of what classroom education can handle. That isn’t a problem with the culture, it is revealing the inherent weakness in the approach.

There is no cookbook. There is only a clear objective, and good faith effort to keep trying until a solution is found.

Epiloge: Yes, this factory got into production. However the parent company could never get traction in this market with this product and recently made a decision to close this plant and pursue a different strategic direction. That is not a reflection at all on the people who did the work in these photos.

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.

Production Planners in a Lean World

Many organizations have a centralized production planning function that would undergo a radical change in a transition to pull.

I know many of you have experienced this type of organization, some have transitioned it.

We have a fledgling exchange on the topic started in the discussion forum.

I would like to invite more participation there on the topic. If you have comments or insights, how about putting them there.

http://forums.theleanthinker.com/viewtopic.php?f=15&t=18