Does Your Solution Have A Problem? Does Your Problem Have A Customer? is a site with a few good tools centered around startup product development. (“Lean Startup”). I really liked their tutorial around the “javelin board” which is a vertical PDCA record specialized for testing product ideas.

In the tutorial, the phrase that really got my attention was this:

“Not all solutions have problems, and not all problems have customers.”

If you are a regular reader, you know one of the questions I ask frequently is “What problem are you trying to solve?” This is especially important if the proposed solution is a “lean tool.” For example, “there is no standard work” is not a problem, per se. I know lots of companies that do just fine, and have more than doubled their productivity before work cycles ever emerged as something to work on. “What obstacle are you addressing now?” is a question we ask in the Coaching Kata to explore the learner’s linkages between the proposed solution, the problem (obstacle), and target condition. The obstacle itself is a hypothesis.

The javelin board process first ensures that (1) you know who the customer is and (2) that you validate that the problem you THINK they have is one they ACTUALLY have… before you go exploring solutions.

Remember as you watch this, though, that the process isn’t different from the Improvement Kata. It is just a specialized variant. The underlying thinking pattern is totally identical… and the problem Toyota Kata is trying to solve is “We have to learn this thinking pattern.” Once you understand the pattern, and apply it habitually, then these variations make perfect sense. On the other hand, if you don’t understand the underlying pattern, then these variations all look like a different approach, and you’ll end up wrestling with “which one to adopt.”

Jeff Liker: Is Lean a Waste Elimination Program or Striving for Excellence?

Jeff Liker asks (and answers) the title question in a great Industry Week blog article by the same title.

One of the biggest obstacles we in the lean community need to overcome is our own inertia around “Lean is a process for finding and eliminating waste.”

In the article, Liker brings up a point that is often lost on us: Looking for the problems and negative things kills morale.

The “waste” that you see is the result of underlying issues and culture. Stop overproduction in one place, and it either returns or pops up elsewhere because the underlying reasons for it were never addressed.

Operations that are not operating at a high level of lean typically are lacking underlying process discipline, which leads to these problems and they proliferate daily as the company is in a constant firefighting mode. Trying to eliminate waste in the current system and culture is like identifying and fighting problems—it is debilitating and a losing proposition.

[Emphasis added]

I bolded that phrase for a reason.

We aren’t talking about a technical implementation here. We are talking about a shift in the underlying culture – the habitual ways people interact with one another, with the process, respond to challenges and problems.

Today we have, thanks to Jeff Liker and a few others, an excellent picture of an ideal version of Toyota. We know what it looks like.

Getting there is an entirely different proposition, as most companies that have tried this stuff know first hand. It is hard.

What is beginning to emerge, though, is that the thinking pattern that is learned through solving these problems the right way (vs. just implementing tool sets) is the same thinking pattern required to shift the culture.

It is hard. You have to do the work. But the way to get there is emerging.

Flipping Tires

A couple of weeks ago I was talking listening to the owner of a medium-sized manufacturing company as he shared his experience of various “lean” consultants, books, etc.

One of the stories he told was about a kid at football practice. (For my European readers, this is about “American Football.”) The coach had the linemen doing drills that involved flipping over large tractor tires.

Over and over. Wax on, Wax off.

Of course, they weren’t just doing it to flip over big tires. They were learning to get leverage, use the strength of their legs, and the motions of managing momentum.

The kid, though, was complaining about flipping tires and wondering why they just didn’t play.

The danger here is we have people doing the equivalent of sitting in the bleachers watching this football practice. “Ah – they flip tires. We need to flip tires too.”

Right thing, but no context.

What this business owner was, correctly, objecting to was consultants coming in and putting people through tire flipping drills without giving them context… the why? of doing it.

Worse, they had not distinguished between flipping tires and playing the game.

Of course in our continuous improvement worlds, we have to play the game every day, and usually work on our development at the same time.

Still, we need to be clear what things we are doing to facilitate practice and learning, and what it looks like when we are “just doing it.”

Here is a test: Which of these is different from the others:

  1. Hoshin kanri
  2. Kanban
  3. Toyota kata
  4. Standard work
  5. Value Stream Mapping

This may be controversial, but I don’t think “Toyota Kata” belongs on this list.

Toyota Kata is flipping tires. Yes, we are practicing on the field, usually during the game, but it is a method for practice.

The book Toyota Kata and most of the materials out there describe that practice in the context of production systems and process improvement. That works because these are physical processes, and we can see and measure our results.

But Toyota Kata is about learning a habitual thinking pattern. It is the same thinking pattern behind Hoshin kanri. And standard work. And Value stream mapping. And kanban. And leadership development itself.

It is the same thinking pattern behind successful product development, entering new markets, and taking on personal growth and challenge. It is the same thinking pattern behind cognitive therapy.

Don’t confuse Toyota Kata with part of the system. It is how you practice the thinking behind any system (that works). (The same thinking patterns are behind Six-Sigma, Theory of Constraints, TQM, pure research, Toyota Business Practice, Practical Problem Solving, the list goes on.)

The confusion comes in because, in practice, Toyota Kata looks like a tool or part of the system itself. We teach people the theory behind it standard work; we teach people the theory behind Toyota Kata. We go to the shop floor and put it into practice.

The difference is that the standard work is intended to stay there, as a work environment where it is easier to:

  • Define the target condition.
  • See the current condition.
  • Detect obstacles as they occur.
  • Quickly implement isolated changes as experiments and see the results.

Standard work gets into place out of necessity because batching and arbitrary work cycles would be an early obstacle to seeing what is going on.

Kanban does the same thing for materials reorder and movement.

Value stream mapping is a structure for applying the thinking that TK teaches a higher operational context.

Hoshin is a structure for applying the thinking that TK teaches to a strategic context.

I could go on listing just about all of the things in the so-called “toolbox.”

The kids were flipping tires to develop the fundamental skills and strength required for blocking and tackling.

Toyota kata is a structure to develop the fundamental skills required to use any of the “lean tools” correctly.

Hopefully this generated a little thought. Comments anyone?

Toyota Kata “A3 Problem Solving”

Over the years, I’ve been exposed a number of efforts to “implement A3 problem solving” in various companies. I worked for some of those companies, I’ve observed others.

The results are nearly always the same.

Here are a couple of examples. Let me know if any of these match up with experiences you have had.

Example 1: The company had put many people through “Practical Problem Solving” training and was (ironically) trying to measure how many problem solving efforts were underway.

I was watching a presentation by one of these problem solving teams to management. Their A3 was on a computer, projected onto the screen. They were reporting their “results.” Yet there were large discontinuities in their problem solving flow. The actions they were taking simply did not link back (through any kind of identifiable cause) to the problem they were solving.

The management team listened carefully, applauded their efforts, and moved on to the next topic of their meeting.

Example 2: A different company had a form to fill out called an “MBF” or “Management by Fact.” From the labels on the boxes, it was clearly intended to be structured problem solving. By the time I worked there, however, “MBF” had become a verb. It was a solo activity, filling out the form at the desk, and reporting on it in a staff meeting.

Example 3: Well-meaning former Toyota team members, now working for a different large company wanted to “train everyone in problem solving.” They put together a “class” that presented the purpose of each block on their A3 form with the expectation that people would adopt the process.

All of these efforts had something in common.

They didn’t work.

Over the last few days, I’ve been privileged to be included in an email exchange about the relationship between A3 and Mike Rother’s Toyota Kata. My small contribution was apparently enough to get my name onto the cover, but I want to give a real nod in the direction of a Jenny Snow-Boscolo for instigating inspiring a really good exchange.

The result is here. I think this presentation does a really good job of summing up the relationship between Toyota Kata and Toyota A3. Thanks to Mike Rother for taking the initiative and putting it all together (more below)

One of the difficulties with gaining insight into Toyota’s management processes is that they really aren’t codified. This shouldn’t be a surprise. Look at your own company, and ask how much of the culture – the reflexive way things are done and interactions are structured – is written down.

(In fact, if it is written down, I would contend it is likely your actual culture has little resemblance to what is written about it. Those things tend to be more about what they wish the culture was.)

Culture, any culture, is learned through daily interaction. This is all well and good in cases where people are immersed in it from the beginning.

But the rest of us aren’t operating in that problem solving culture. Rather, we are trying to create it. And as the former Toyota Team Members from Example 3 (above) learned, it isn’t a simple matter of showing people.

Rather than two different things, we are looking at a continuum here. At one end is the culture described on Slide 9. There isn’t any formal structure to it, the process for teaching it isn’t codified. It is learned the same way you learn the way to get the job done in any company. They just learn different things than you did.

But in another organization there is no immersion. If there is anyone who is steeped in The Way, they are few and far between.

In these cases, we want to start with something more overt. And that is the purpose of having a rote drill or kata. It isn’t something you implement. It is a structure, or scaffold, to learn the basic moves. Just as mastering the musical scales is only a prelude to learning to play the instrument, the kata is the foundational structure for learning to apply the underlying thinking patterns.

So… if you are working on kata, it is critical that you are reflecting on your thinking patterns as much (or more) than you are reflecting on your improvements. It might seem rote and even busywork at first. But it is there to build a foundation.

Write it Down

Recently, a team was trying to understand a seeming anomalous message (or lack of one, actually) in their complex computer transaction system. (Complex Computer Transaction System is abbreviated “E.R.P.”)

They discussed possible causes, settled in the likely culprit, constructed an experiment to try to replicate the issue and… everything worked perfectly. Meaning that the cause they were testing wasn’t the cause at all.

They worked to reconstruct the timeline from initial data entry to the point where the message should have been issued, and did a better job looking at what along the way could have suppressed the message.

After a series of trials, they found the culprit. It had originated in a data entry omission in a sister plant. They were able to turn the problem on and off at will with that one field.

They had actually discussed this possibility in their original discussion. But they had talked past it, and ended up focusing elsewhere.

There was a great learning here.

If you are discussing possible causes to a problem, write them down. All of them.

Get methodical. Be certain what evidence you either have in hand, or need to get, to eliminate a potential suspect from the list.

It feels slower, but it works better than faster approaches that don’t work.

Problem Solving Modes

I want to tack a similar issue onto yesterday’s post about normal operating mode vs. recovery mode.

Listening to a team trying to understand a complex issue, I noticed three different threads intertwining in their conversation.

  1. They would discuss the actions needed to work through the issue and get the product to the customer. This is appropriate and necessary, but not in a meeting to discuss cause and countermeasure of the issue itself. This topic is habitual because it is the mode the group normally operates in. They are working to change that, but until they do, they’ll have to do what is necessary to meet the requirement… just not in this meeting.
  2. They would discuss the actions required to understand the next level of the cause – the investigation itself.
  3. They would discuss possible preventive countermeasures.

We’ve already said #1 should be taken off line. As you listen to the conversation in your problem-solving meetings, watch for this one because it can be very distracting as it is often confused with finding the cause.

#3 – discussing possible preventive countermeasures – often takes place before the root cause is understood. Though it is certainly appropriate to discuss (and experiment with) preventive countermeasures once the root cause it known, it is simply an exercise in idle speculation to do so before that.

In fact, doing so can be dangerous. You could put in a “countermeasure,” followed by an intermittent problem “going away” or the symptoms disappearing for a random reason, and end up with a powerful superstitious belief that you HAVE to operate that particular screen with the mouse in your left hand, or it won’t work.

The best course of action is to follow a methodical series of experiments to rule out possible causes.

This is harder than it looks. This week a team had an epiphany when they discovered that an unlikely cause they had talked themselves out of early on turned out to be the actual issue. The lesson they learned was don’t eliminate a possible cause without hard evidence. The more certain you are, the more you need to get that evidence.

Ask yourself “What would I have to prove to eliminate this as a possible factor?”

Just some thoughts for the day.

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.

Rapid PDCA

This sub-assembly line had a planned cycle time of 15 minutes. The most skilled and experienced assembler could almost get all of the work done in that time, but generally, two people were required to consistently deliver without stopping the main line.

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.

01 Cardboard Concept

02 Cardboard Concept


Iteration 2:

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

03 Adjust Cardboard

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

03 Wood #1

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

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

04 Wood on stand

Then Maegan tries it out.


What did we learn?

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


Iteration 4:

Add some wood shims to raise the part and see if that works better.


Expected result: Should be easier to get the tool in there. Now try it.


But we learned we need a better backstop for the clamp.

Iteration 5



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. A far cry from the traditional tooling and jig design process.


This is the final version. As you can see, there is now a wedge under the clamp to change the angle + some additional clamps that allowed the tool to also be used for another subsequent operation.




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.


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.

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.