Sometimes the situation arises where the learner has been beating her head against an obstacle with little or no luck overcoming it. The question comes up: When is it OK to give up and switch to something else.
The answer is, of course, a little situational. (Consultant speak: It depends…)
The natural progression of the Improvement Kata will provide an opportunity.
Improvement Kata steps by Mike Rother
As the learner is iterating against obstacles toward the Target Condition the clock is ticking because the Target Condition is always associated with an “achieve by” date. If the Target Condition is achieved OR we hit the “achieve by” date without achieving it, the learner should cycle back to the beginning and:
Verify understand of the direction and challenge. (The learner may well have gotten more clarity along the way.)
Get a complete grasp of the Current Condition. This is important because often while working toward a Target Condition the learner is only updating specific process and performance metrics, and may not be looking for collateral changes elsewhere. This is a time to take a step back, put up the periscope, and get a grasp of the complete picture.
Based on that new Current Condition, establish a new Target Condition, with a new “achieve by” date.
Now… identify the obstacles in the way of achieving that new Target Condition. Ideally they should wipe the obstacle parking lot clean and take a fresh look.
This process often helps clear the learner’s mind and see another way to get there, or see easier obstacles that were overlooked before.
This is also why it is important for the “achieve by” date to be relatively close (a couple of weeks) – because that date is a safety valve that forces a reset of the process if the learner is stuck.
If the learner asks if it is OK to work on a different obstacle, then the coach should become curious about the learner’s rationale.
Specifically, I want to understand why the learner thinks there might be an easier way vs. just saying this one is too hard. This may well require some more information gathering – a mini version of the reset I talked about above.
The key point here is to maintain the learner’s motivation. There is a fine line between struggling to solve a problem and getting frustrated. This might be a good time for the coach to engage in some empathetic questioning.
For example, name the feeling you are picking up to test your hypothesis: “It seems you are really frustrated by this…” Then listen. The learner will likely either agree, “yeah, I am.” or refute and give you more information, “No, I’m just trying to…” Then you might learn more about their threshold of knowledge with the process of problem solving.
That can open up a discussion for why the learner thinks it would be a good idea to try something else. Then use your judgement.
But as a coach, I don’t want to make switching obstacles too easy because there is a high risk of it becoming a whack-a-mole game. Some obstacles actually require digging and perseverance to overcome. Your job, coach, is to keep the learner in the game.
Sometimes, though, the learner gets fixated on a problem and doesn’t see another way. Even in this case, if the time to the “achieve by” date is short, I’d let it ride. But if that isn’t practical…
The coach may well have a broader perspective – in fact, this is part of the coach’s job.
If the learner is making progress on something I (the coach) consider a red herring, I generally let it go. There is always learning involved – so long as the effort doesn’t bog down progress.
Sometimes, though, the learner is getting frustrated and so focused that he just doesn’t see any other way.
This is time for gentle intervention with whatever questions might help the learner pause, step back, and see the bigger picture.
For example, perhaps something like “If this obstacle were cleared, how would the process operate?” This might not be the full target condition. I’m just trying to learn what “solved” looks like to the learner. Maybe just thinking about it will help them see the where they are trying to go and possibly another path to get there.
An interesting follow-up might be, “Hmmm, what’s stopping it from working that way now?”
“What would you need to learn to better understand what is going on?” might be another avenue to get the learner to look at his threshold of knowledge vs. the big ugly obstacle in front of him
It all depends on what you think will help the learner raise her head and take a different look at things.
But in the end, if you have a learner that is truly stuck, and after a few tries isn’t going to get unstuck, then, honestly, it’s time to go shoulder-to-shoulder with them and dig into things together.
What I would work very hard to avoid is direct intervention – “Why don’t you work on…” because this undermines the entire process by giving them the answers and can easily create a “what do you think I should work on?” expectation next time.
I’m digging through old archives again, and came across this graphic I put together around 2006 or so. It depicts more detailed version of “Organize, Standardize, Stabilize, Optimize” showing the continuous comparison between “what should be happening” and “what is actually happening.” It is the gap between these two that drives improvement forward.
Like the pocket card in the last post, this is built on a foundation established by the work of Steven Spear, especially his PhD dissertation that is summarized in Decoding the DNA of the Toyota Production System. By the way, if you are in the business of continuous improvement, reading (and understanding) this breakthrough work is critical for you.
Other than generally sharing this, my other reason for putting this up is that in the Toyota Kata community there has been discussion for about a decade about whether or not the right hand loop – pushing for stability – is an appropriate use of the Improvement Kata.
I think that is an unfortunate result of some very early conversations about the difference between “troubleshooting” and “improving” a process. We get into semantic arguments about “problem solving” as somehow different from “root cause analysis” and how the Improvement Kata is somehow distinct, again, from those activities.
This makes no sense to me for a couple of reasons.
Scientific Thinking is the Foundation
Toyota Kata is not a problem solving tool. It is a teaching method for teaching scientific thinking, and it is a teaching method for learning to teach scientific thinking. In the books and most literature, it uses organizational processes as working examples for the “starter kata,” but exactly the same thinking structure works for such diverse things as working through quality issues, developing entirely new products and processes, working through leadership and people issues. The underlying sub-structures may change, but the basic steps are the same.
When I encounter an organization that already has a “standard problem solving approach” I do not attempt to tell them they are wrong or confuse them by introducing a different structure. Rather, I adapt the Improvement and Coaching Kata to align with their existing jargon and language, and help them learn to go deeper and more thoroughly into their existing process.
Stability is a Target Condition
I see a lot of pushback about working to “return a process to standard.” In reality, that is the bulk of the activity in day-to-day improvement. The whole point of having a standard in the first place is to be able to see when the actual process or result is somehow different.
Think about it: If there isn’t an active means of comparing “actual” vs. “standard” what is the point of having a standard in the first place?
Think of the standard as a target condtion.
What obstacles are preventing you from [operating to that standard]? You can guess, but the best way is to diligently try to operate to the target condition and see what gets in your way. That might not happen immediately. Maybe some time will go by, then BAM! You get a surprise.
This is good. You have learned. Something you didn’t expect has interfered with getting things done the way you wanted to. Time to dig in and learn what happened.
Maybe there was some condition that you could have detected earlier and gotten out in front of. Who knows?
You Cannot Meet a Challenge Without Working on Stability
As you are working to reach new level of performance – working toward a new challenge – there will be a point when the process works sometimes, so you know it is possible. But it doesn’t work every time because there are still intermittent obstacles that get in the way.
Nevertheless, you have to work diligently to see problems as they occur, respond to them, dig into causes (root cause analysis anyone?) and systematically protect your process from those issues.
The only real difference between covering this territory for the first time vs. trying to recover a previously stable process is that in the later case you can ask “What has changed?”
But, in the end, in both cases – stabilizing a new process vs. re-stabilizing an old one – you are dealing with conditions that are changing from one run to the next. That is why it works sometimes and not others. You don’t know what is changing. You are trying to figure it out by experimenting and learning.
What About Root Cause Analysis?
My challenge is still a stable process.
My current condition is my level of understanding of how the process works today, and the exact mechanism that results in a defect. Even defects are produced by a process – just not the process we want.
That understanding will be incomplete by definition – because if we truly understood what was going on we wouldn’t have the problem. So… what do I know (and can prove with evidence) and what do I not know.
What do I suspect? What evidence do I need to gather to rule out this possible cause, or keep it in play? Next experiment. What do I expect to learn?
I’ll write a more detailed post about this at some point. I think it is a topic worth digging into. Suffice it to say that I have absolutely used the Improvement Kata structure to coach people through finding the root cause of wicked quality problems.
It really helped that they were able to see the same underlying pattern that I had already been teaching them. It made things simpler.
Don’t Complicate a Simple Concept
It’s all “solving problems” (the term “problem solving” apparently has some specific form it needs to take for some people).
The underlying structure for all of it is scientific thinking. Some say it’s PDCA / PDSA. Same thing.
Splitting semantic hairs and saying “this is different” makes simple things complicated. Yes, there are advanced tools that you use when things get tough. But… addition and subtraction; basic algebra; advanced polynomials; basic differential calculus; advanced multivariate calculus – IT IS ALL MATH. You apply the math you must to model and solve the problem at hand.
DON’T apply more math than you need just because you can. That serves no purpose except, perhaps, to prove how smart you are… to nobody in particular.
Solving problems is the same. There are some cases where I need to develop a designed experiment to better understand the current condition – the interactions between variables. There are cases where other statistical tools are needed. Use them when you must, but not just because you can.
I was going through some old files and came across a pocket card we handed out back in 2003 or so. It was used in conjunction with our “how to walk the gemba” coaching sessions that we did with the lean staff, and then taught them to do with leaders.
A lot has happened, a lot has been learned since then. Toyota Kata has been published, and that alone has focused my technique considerably (to say the least).
Nevertheless, I think the elements on these little cards are valuable things to keep in mind.
With that being said, a caveat: Lists like this run the risk of becoming dogma. They aren’t. There are lots of lists like this out there, and the vast majority are very good. The key here is something that a leader or team member can refer to as a reminder that may bias a decision in the right direction. It is the direction that matters, not the reminders.
Fundamentals
The fundamentals are based on the “Rules-in-Use” from Decoding the DNA of the Toyota Production System, a landmark HBR article by Steve Spear and H. Kent Bowen. The article, in turn, summarizes (and slightly updates) Spear’s findings from his PhD work studying Toyota.
A. All work highly specified as to content, sequence, timing, and outcome.
B. Every customer-supplier connection is simple and direct.
C. The path for every product is simple and direct.
D. All improvements are made using PDCA process.
What we left off, though, is that in each of those rules there is a second one: That all of these systems are set up to be “self diagnostic” – meaning there are clear indications that immediately alert the front line people if:
The work deviates from what was specified.
The connection between a customer and supplying process is anything other than specified.
The path a product follows deviates from the route specified.
Improvements are made outside of a rigorous PDCA (experimental) process.
In other words, the purpose of the rules is to be able to see when we break them, or cannot follow them, so we trigger action.
To put this into Toyota Kata-speak – every process is set up as a target condition that is being run as an experiment – even the process of improvement itself!
Every time there is a disruption – something that keeps the process from running the way it is supposed to – we have discovered an obstacle. That obstacle must first be contained to protect the team members and community (safety) and to protect the customer (quality). Then goes into the obstacle parking lot, and addressed in turn.
If you think about it, the Improvement Kata simply gives us much more rigor to (D).
This ties to the next sections.
Key Leadership Behaviors
Note that this is behaviors. These are things we want leaders to actually strive to do themselves, not just “support.” It was the job of the continuous improvement people to nudge, coach, assist the leaders to move in these directions. It was our job to teach our continuous improvement people how to do that coaching and assisting – beyond just running kaizen events that implement tools.
A. PDCA Thinking
Today we would use Toyota Kata to teach this. But the same structure drove our questioning back then.
B. Four Rules:
1. Safety First
Even though this should be obvious, it is much more common that people are tacitly, or even directly, asked to overlook safety issues for the sake of production. I remember walking through a facility with a group of managers on the way to the area we were going to see. Paul stopped dead in his tracks in front of a puddle on the floor. He was demonstrating just how easy it was for the leadership to walk right past things that should be attended to. And in doing so, they were sending the message – loud and clear in their silence – that having a puddle on the floor was OK.
2. Make a Rule, Keep a Rule
This is a more general instance of Rule #1. But the it is more subtle than it may seem on the surface. Most people immediately interpret this as enforcing organizational discipline, but in reality it is about managerial discipline.
Nearly every organization has a gap between “the rules” and how things really are day-to-day. Sometimes that gap is small. Sometimes it is huge.
Often “rules” are enforced arbitrarily, such as only cases where a violation led to a bigger problem of some kind. Here’s an example: Say your plant has a set of rules about how fork trucks are to be operated – speed limits, staying out of marked pedestrian lanes, etc. But in general the operators hurry, cut a corner now and then. And these violations are typically overlooked… until there is some kind of incident. Then the operator gets written up for “breaking the rules” that everyone breaks every day – and management tacitly encourages people to break every day by focusing on results rather than process.
When we say “make a rule / keep a rule” what we mean is if you aren’t willing to insist on a rule being followed consistently, then take the rule off the books. And if you are uncomfortable taking the rule off the books, then your only option is to develop something that you can stand behind. It might be simple mistake proofing, like physical barriers between forklift aisles and pedestrian aisles. But if you are going to make the rule, then find a way to keep the rule.
Do you have “standard work” documents that are rarely followed? Stop pretending you have standards or rules about how the work is done. Throw them away if you aren’t willing to train to them, mistake proof to them and reinforce following them.
3. Simple is Best
Simply, bias heavily toward the simplest solution that works. The fewest, simplest procedures. The simplest process flow. Complexity hides problems. “Telling people” by the way, is usually less simple than a physical change to the work environment that guides behavior. See above.
4. Small Steps
Again, Toyota Kata’s teaching covers this pretty well today. The key is that by taking small steps, verifying that they work, and anchoring them into practice before taking the next ensures that each step we take has a stable foundation under it.
The alternative would be to make many changes at once in the name of going faster.
We emphasized here that “small steps” does not equal “slow steps.” It is possible to take small steps quickly, and we found that in general doing so was faster than making big leaps. Getting big changes dialed in often required backing out and implementing one thing at a time anyway – just to troubleshoot! See “Gall’s Law” which states:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
John Gall, author of Systematics
and sums this up nicely.
C. Ask “Why, what, where, when, who, and how” in that order.
Here we borrowed the sequence from TWI Job Methods. The first two questions challenge whether a process step is even necessary: Why is it necessary? What is its purpose? To paraphrase Elon Musk, the greatest waste of time is improving something that shouldn’t even exist.
Then: Where is the best place? and When is the best time? These questions might nudge thinking about combining steps and further simplifying the process.
And finally we can ask Who is the best person? and “How” is the best method? The key point here is until we have the minimum possible steps in the simplest possible sequence, and understand the cycle times, it doesn’t make sense balance the work cycle or work on improving things.
Come to think about it – perhaps we should ask “How?” before we ask “Who” since improving the method will change the cycle times and may well inform out decisions about the work balance. Hmmm… I’ll have to think about that. Any thoughts from the TWI gurus?
D. Ask Why 5 Times
Honestly, this was a legacy of the times. Unfortunately it suggests that you can arrive at a root cause simply by repeatedly asking “Why?” and writing down the excuses answers that are generated. In reality problem solving involves multiple possible causes at each level, and each must be investigated. I talked about this in a post way back in 2008: Not Just Asking Why – Five Investigations.
E. Go and see.
Go and see for yourself. Taking this into today’s practice, I think it is something that the Toyota Kata community might emphasize a little more. We tend to ask the question “When can we go and see what we have learned…?” but all too often the answer to “What have you learned?” is a discussion at the board rather than actually going and observing. Hopefully the board is close to where the improvement work is being done. Key point for coaches: If the learner can’t show you and explain until you understand, it is likely the learner’s understanding could be deeper.
As You Walk The Workplace:
Check:
perhaps we should have said “Ask…” rather than “Check” but asking and observing are ways to “check.” All of the below are things that the leader walking the workplace must verify by testing the knowledge of the people doing the work.
A. How should the work be done? Content, Sequence, Timing, Outcome
This is another nod to the research of Steven Spear. The key point here is that before you can ask any of the following questions, you have to have a crisp and precise of what “good” looks like. In this paradigm, all processes are target conditions. And as the work is being done, we are actively searching for obstacles so we can work to make the work smoother and more consistent.
In other words, “What should be happening?” and “How do you know?”
Do the people doing the work understand the standard process as it should be done?
A few months ago I went into some depth on this here: Troubleshooting by Defining Standards. That probably isn’t the best title in retrospect, but there are too many links out there that I don’t want to break by changing it.
B. How do you know it is being done correctly?
Today I ask this question differently. I ask some version of “What is actually happening?” followed by “How can you tell?” We want to know if the people doing the work have a way to compare what they are actually doing against the standard.
C. How do you know the outcome is free of defects?
So, question B asks about consistency of the process, and question C asks about the outcome. Does the team member have a way to positively verify that the outcome is defect-free?
D. What do you do if you have a problem?
Again, we are checking if there is a defined process for escalating a problem. And we define “problem” as any deviation from the standard, or any ambiguity in what should be (or is) happening. We want someone to know, and act, on this, and the only way that is going to happen is to escalate the problem.
We want this process to be as rigorous and structured as the value-adding work.
And we want as much care put into designing production process as was put into designing the product itself. All too often great care and a lot of engineering time goes into product design, and only a casual pass is made at designing and testing the process.
Even better if these are done simultaneously where one informs the other.
For Abnormal Conditions:
ACT:
These are actions that the leader must take if she finds something that isn’t “as it should be” in the course of the CHECK questions above. Key Point: These are leadership actions. That doesn’t mean that the leaders personally carry them out, but the leaders are personally responsible for ensuring that these things are done – and checking again.
That is the only way I know of to prevent the process from continuing to erode.
A. Immediately follow up to restore the standard.
If it isn’t possible to get the intended standard into back place, then get a temporary countermeasure into place that ensures safety and quality.
B. Determine the cause of erosion.
We are talking about process erosion here, with the assumption that something knocked the process off its designed standard. Some obstacle has been discovered, we have to better understand what it is – at least enough to get it documented.
C. Develop and apply countermeasure.
Here we may have to run experiments against this newly discovered obstacle and figure out how to make the process more robust.
That is the end of the little card. But I want to point out that we didn’t just hand these out. You got one of these cards after time paired with a coach on the shop floor practicing answering and asking these questions. Only after you demonstrated the skill did you get the card – just as a reminder, not as a detailed reference. This exercise was inspired by a few of us who had experiences “in the chalk circle” especially with Japanese senseis who had been direct reports to Taiichi Ohno.
We piloted and developed this process on a very patient and willing senior executive – but that is another story for another day. (Thank you once again, Charlie. I learned more from you than you will probably ever realize.)
Normally when I get an email from a company pointing me to the great lean resource on their web page, I find very little worth discussing. But Creative Safety Supply in Beaverton, Oregon has some interesting material that I think is worth taking a look at.
First, to be absolutely clear, I have not done business with them, nor do I have any business relationship. I can’t speak, one way or the other, about their products, customer service, etc
With that out of the way, I found their Kaizen Training and Research Page interesting enough to go through it here and comment on what I see.
What, exactly, is “PDCA?”
The section titled Kaizen History goes through one of the most thorough discussions of the evolution of what we call “PDCA” I have ever read, tracing back to Walter Shewhart. This is the only summary I have ever seen that addresses the parallel but divergent histories of PDCA through W. Edwards Deming on the one hand and Japanese management on the other. There has been a lot of confusion over the years about what “PDCA” actually is. It may well be that that confusion originates from the same term having similar but different definitions depending on the context. This section is summed up well here:
The Deming Circle VS. PDCA
In August of 1980, Deming was involved in a Roundtable Discussion on Product Quality–Japan vs. the United States. During the roundtable discussion, Deming said the following about his Deming Circle/PDSA and the Japanese PDCA Cycle, “They bear no relation to each other. The Deming circle is a quality control program. It is a plan for management. Four steps: Design it, make it, sell it, then test it in service. Repeat the four steps, over and over, redesign it, make it, etc. Maybe you could say that the Deming circle is for management, and the QC circle is for a group of people that work on faults encountered at the local level.”
So… I learned something! Way cool.
Rapid Change vs. Incremental Improvement
A little further down the page is a section titled Kaizen Philosophy. This section leans heavily on the thoughts / opinions of Masaaki Imai through his books and interviews. Today there is an ongoing debate within the lean community about the relative merits of making rapid, radical change, vs. the traditional Japanese approach of steady incremental improvement over the long-haul.
In my opinion, there is nothing inherently wrong with making quick, rapid changes IF they are treated as an experiment in the weeks following. You are running to an untested target condition. You will likely surface many problems and issues that were previously hidden. If you leave abandon the operators and supervisors to deal with those issues on their own, it is likely they simply don’t have the time, skill or clarity of purpose required to work through those obstacles and stabilize the new process.
You will quickly learn what the knowledge and skill gaps are, and need to be prepared to coach and mentor people through closing those gaps. This brings us to the section that I think should be at the very top of the web page:
Respect for People
Almost every discussion about kaizen and continuous improvement mentions that it is about people, and this page is no different. However in truth, the improvement culture we usually describe is process focused rather than people focused, and other than emphasizing the importance of getting ideas from the team, “employee engagement is often lip-service. There is, I think, a big difference between “employee engagement” and “engaging employees.” One is passive, waiting for people to say something. The other is active development of leaders.
Management and Standards
When we get into the role of management, the discussion turns somewhat traditional. Part of this, I think, is a common western interpretation of the word “standards” as things that are created and enforced by management.
According to Steve Spear (and other researchers), Toyota’s definition of “standard” is quite different. It is a process specification designed as a prediction. It is intended to provide a point of reference for the team so they can quickly see when circumstances force them to diverge from that baseline, revealing a previously unknown problem in the process.
Standards in this world are not something static that “management should make everyone aware of” when they change. Rather, standards are established by the team, for the team, so the team can use them as a target condition to drive their own work toward the next level.
This doesn’t mean that the work team is free to set any standard they like in a vacuum. This is the whole point of the daily interaction between leaders at all levels. The status-quo is always subjected to a challenge to move to a higher level. The process itself is predicted, and tested, to produce the intended quality at the predicted cost, in the predicted time, with the predicted resources. Because actual process and outcomes are continuously compared to the predicted process and outcomes, the whole system is designed to surface “unknowns” very quickly.
This, in turn, provides opportunities to develop people’s skills at dealing with these issues in near-real time. The whole point is to continuously develop the improvement skills at the work team level so we can see who the next generation of leaders are. (Ref: Liker and Convis, “The Toyota Way to Lean Leadership”)
Staging improvement as a special event, “limited time only” during which we ask people for input does not demonstrate respect, nor does it teach them to see and solve those small issues on a daily basis.
There’s more, but I’m going to stop here for now.
Summary
Creative Safety Supply clearly “gets it.” I think this page is well worth your time to read, but (and this is important), read it critically. There are actually elements of conflicting information on the page, which is awesome because it gives you (the reader) an opportunity to pause and think.
From that, I think this one-page summary really reflects the state of “lean” today: There IS NO CANONICAL DEFINITION. Anyone who asserts there is has, by definition, closed their mind to the alternatives.
We can look at “What Would Toyota Do?” as somewhat of a baseline, but ultimately we are talking about an organizational culture. Toyota does what they do because of the ways they structure how people interact with one another. Other companies may well achieve the same outcomes with different cultural mechanisms. But the interactions between people will override process mechanics every time.
Another interesting homework question has shown up in the search terms. Let’s break it down:
23. if the slowest effective machine cycle time in a cell is 55 seconds and the total work content is 180 seconds, how many operator(s) should operate the cell so that labor utilization is at 100%?
I find this interesting on a couple of levels.
At a social level, the idea of cutting and pasting a homework question into Google hoping to find the answer is… interesting. Where is the thinking?
What are we teaching?
The question is asking “How many people do we need to run as fast as we can?” (as fast as the slowest machine). But how fast do they need to run? Maybe they only need a part every 95 seconds. If that is true, then I need fewer people, but I am going to run the slowest machine even slower.
In other words, “What is the takt time?” What does the customer need? How often must we provide it?
Then there is the “labor utilization” metric, with a target of 100%. Assuming the planned cycle time is actually 55 seconds (which it shouldn’t be!), we need 3.3 people in this work cell. (180 seconds of labor cycle time / 55 seconds planned cycle time: “How long does it take?” / “How long do you have?” = Minimum Required Capacity)
How about improvement? What do we need to do to get from 3.3 people to 3 people? We can solve for the labor cycle time. 55 seconds of planned cycle time * 3(people) = 165 seconds of total labor. So we need to get that 180 seconds down to a little less than 165 seconds.
Now we have a challenge. We need to save a bit over 15 seconds of cycle time. That might seem daunting. But we don’t have enough information (the current condition) to know where to begin. Then we can establish the next target condition and get started making things better.
These types of questions bother me because they imply all of these things are fixed, and they imply we run “as fast as we can” rather than “as fast as we must.”
Edit: Today I saw two more searches for:
total work content divided by slowest machine cycle time
so it looks like at least two others are working on the same assignment. 🙂
“Time is the shadow of motion” is an observation usually attributed to Frank and Lillian Gilbreth, pioneers of modern industrial engineering.
What they realized was this: You want to save time. But you cannot directly affect how long something takes. You have to look at the motions, at the process structure that is casting the shadow of time. To change how long the shadow is, you have to change the structure of what is casting it.
As you start your improvement effort, your challenge is often to change the size or shape of the shadow.
Grasping the current condition is looking at the process structure so you can see what patterns and characteristics of the process are shaping the shadow.
It is important to understand how the process patterns and characteristics are affecting the shadow before you just go changing stuff.
You might think “Oh, this part of the process ought to look like this…” and change it. There might be a lot of effort involved. But if you don’t have a sense of cause and effect, then you might end up with something like this:
Change have been made, but we really haven’t changed anything on the outside.
Your target condition has three components, and it is good to develop them in this sequence:
1. The “achieve by” date.
2. The target process pattern and characteristics, and the internal process metrics that will tell you if you are working to that pattern.
3. The expected change in performance if the target working pattern becomes the norm. Then check your expected performance change against the challenge. Is it moving you in the right direction? Is it moving you enough in the right direction? If not, then go back to #2.
Edited to add: In the purest sense, you should start with the performance change you require, then determine the pattern you need to achieve it. That is what it says in Toyota Kata, and in the Improvement Kata Handbook. I don’t disagree with that sequence. However beginning improvers, when asked to first decide the performance target tend to just make a guess and can struggle if they over-reach. I find that this is more of an iterative process than a fixed sequence.
Key Point: The target process pattern has to be what you must do to get to a specified level of performance. It isn’t “Well… we can make these improvements, and therefore might be able to deliver this improvement.” It’s “We have to make these changes in order to reach the goal we have set.”
The pattern of work is what should be emphasized. The performance level is an outcome, the shadow, of the work pattern. Your target condition is really a hypothesis: “If I create a process that follows this pattern, then I will get this level of performance.”
Why am I emphasizing this?
Because a lot of managers have been taught, by pretty much every MBA program out there, to manage to results.
That may well happen, but often the changes made are (1) not sustainable and/or (2) people are creative at finding solutions that are destructive to the long (and intermediate) term interests of the organization.
The exchange of intent that is inherent in the Improvement Kata is a way to open up this communication channel.
The person making the improvement clearly has a result based challenge, and the boss ought to be asking the questions to confirm he hears it spoken back to him in the same way he understood it.
Then the boss should become intently curious. “What is it about the way we do things now that is creating (this result we want to change)?” In other words, ‘What is the actual condition now?”
“What process changes are you proposing as your initial step? What result to you expect? When can we see what we’ve learned? These questions are summarized in “What is your target condition?”
I’ve been practicing, teaching (and learning) the Toyota Kata for about four years now, and I’m seeing some pervasive patterns that are getting in people’s way of making it work.
The one I’d like to address today is skipping over “Understand the Direction.”
As designed by Mike Rother, the Improvement Kata has four basic steps:
This fact (that there are four steps) is often lost on beginning practitioners. They tend to associate “Toyota Kata” only with the “Five Questions” of the Coaching Kata, which guide Step 4 (above). On the surface, that is understandable, because we hear the coaching cycles a lot more frequently, and they are a hallmark of the kata principle.
But we (hopefully) wouldn’t think of jumping right into the Five Questions until the answer to “What is your target condition?” is something more definitive than “To improve this process.” (We only used to do that, right? hmmm.)
One of the reasons to set a clear target condition is to get away from general “waste safari” improvement efforts, and focus the improver’s attention on what must be done to get to the next level.
Without a sense of direction, it is easy for the improver to see every improvement opportunity (or none of them), and get locked up trying to find a way to fix them all.
It’s frustrating for everyone, because little progress is made, and those improvements that are made have a tough time finding their way to any higher level meaning.
Someone, long ago, pointed out to me that the geometric figure “frustum” seems to have the same Latin root as “frustration.” This is the graphic that comes to mind:
Though the concept of a clear target condition is fairly easy to get across, organizations seem to get locked into a cycle of Steps 2, 3 and 4 without ever going back to Step 1, except in the most general terms.
Here’s what I think happens:
When an organization is just getting started, we’ve commonly told them to pick an area to practice, based on quick cycles and other practice criteria, and get to learning the improvement kata, striving toward a general challenge like one-by-one flow.
That pattern of seeking improvement opportunities gets engrained, and it is hard to shift off it and start to set clear direction and challenges. Further, it is very similar to the “old way” of planning kaizen events where the goal is to “implement lean tools” … like one-by-one flow.
Setting that direction also seems to run counter to the idea of empowered workers are in the best position to know what to work on. (It doesn’t, in fact direction is required for this to really take hold.)
And if the senior leaders don’t have a clear sense of where they are trying to take the organization next… what is their scope of their responsibility?
What to do differently?
(It might help if the leadership team themselves got a coach.)
1) Be clear that your initial sessions are practice drills. You are not yet playing the game, or even a scrimmage. You are flipping tires. Be conscious that this is a transitory learning stage.
2) Establish a target condition for proficiency you are striving for in your practice. Check it weekly against your current condition. This is the job of the advance / steering team.
Challenge Light
For the first pass, it isn’t necessary to dig headlong into hoshin planning, and in many cases, you can issue a compelling challenge with a theme.
Look at what is bugging your customers about your current operation, and challenge yourself to fix it.
For example, one client had lead times and response times that were getting longer and longer, so the challenges issued by the leadership team revolved around lead time and removing “sources of delay.”
Another company had rework and quality escapes going out of control. Their first step was to “grasp the current condition” and identify where these problems were happening.
Each dot represents the origin of a defect or rework. (The colors don’t mean anything, they ran out of red, then orange, then yellow dots.) (You can see exit cycle run charts taped up there as well.)
This gave them a quick picture of where to focus their attention, and which leaders they needed to challenge, and then coach, through the process of improving their quality.
Note that for these guys, integrating the flow of material and information though the plant isn’t a target condition, or even a challenge yet. It is in the vision, but the first priority is simply to ship what the customer ordered, and then to only make the product once to do so.
By the way, profit is measurably up, rework instances have been cut by about 3/4 from the starting point, and they are well on their way.
A friend, and reader, Craig sent a really interesting email:
As I was practicing the coaching Kata with one of the First Mates on the factory trawler, whenever an issue arose (usually with the leader blaming an employee) he began asking factory and engineering leadership “what needed to be communicated?” or “what needed to be taught?” He found it encompassed every problem on the vessel and I loved that he made it his own and communicated in manner to which lifetime fishermen could relate.
What I found really cool about this is how it is exactly the same conclusion reached by David Marquet, both in the sketchcast video I posted earlier, and the titles of two chapters in his book. The reasons leaders feel they must withhold authority, remain “in control” ultimately come down to competence – what must people be taught, or clarity – what have we failed to adequately communicate. Maybe it’s being at sea.
In other words, if people know what to do (clarity), and know how to do it (competence), then leaders generally have no issues trusting that the right people will do the right things the right way.
The Improvement Kata is a great structure for creating and carrying out development plans for leaders (or future leaders) in your organization.
The Coaching Kata is a great way to structure your next conversation to (1) ensure clarity of intent: Does their target condition align with the direction and challenge? and (2) develop their competence, both in improving / problem solving, but also in their understanding of the domain of work at hand.
Credit: A lot of stuff comes across my screen, sometimes more than once. I have seen this illustration several times, but don’t remember where it originally came from. If you created it, PLEASE comment so I can give appropriate credit.
Improvement is messy. Science is messy. Research and Development is messy. These are all cases where we want an outcome, are pretty sure what that outcome looks like, but there isn’t really a clear path to get there.
This illustration has illustrates two very different mindsets.
On the left is how many people believe the improvement / organizational development / learning process works. We set out a phased project plan to transform the organization. We carry out a set of pre-defined steps, and when they are completed, we are at the goal.
Sadly our education process is largely constructed on this model. Take the classes, pass the tests, the student is educated.
This thinking is appropriate when the outcome is something we have done before, like constructing a house. Even if this house is a bit different, the builders have rich experience in carrying out all of the constituent process steps. Further upstream, the designer carefully followed building and construction codes. In those cases, we are applying a rich body of experience (or the documented experiences of others) to reach the end goal.
These tasks can be scheduled and sequenced in a project plan. The steps are known, the result is known.
On the right is the hairball of learning and discovery.
We know where we are starting.
We know where we want to end up.
We are reasonably certain we can get from Point A to Point B. But we don’t know precisely which detailed steps or experiments will give us the results we need.
We don’t know for sure that the next result will be a forgone conclusion from the next action step.
Each step gives us more information about the next step.
In the world of continuous improvement, we live in an interesting paradox.
We often believe we are operating in the set-piece model on the left. We see a situation, we apply tools to duplicate a solution we have seen work in a similar situation before.
An interesting thing happens at this point. The Real World intervenes, and we discover that the situation was actually more like the right side. We thought we knew the right answers. We might have even been mostly right. But at the detail level, things don’t work quite as we predicted.
Now… if the system has been deliberately set up to flag those anomalies, and we are recording them and being curious to discover what we didn’t understand then we are in learning mode.
But all too often the experts who guided the original installation have moved on, leaving the people executing the process behind. The assumption was “It works, we can go to the next problem.”
The people in the process did what they were told, or guided, to do. We might have even asked for their input on the details. But that process rarely leaves them with additional skills they need to deal with anomalies in ways that make the process more robust.
So they do what they must to get things done. Mostly that means adding some inventory here, some additional checks or process steps there. Over time, the process erodes back to something close to its original state.
Why? Because we thought we knew everything… but were wrong. And didn’t notice.
This model applies to any effort to shift how an organization performs and interacts. We outrun our headlights and take on the Big Change because that company “over there” does it, and we just copy the end result.
The idea that “you always start with 5S”, for better or worse, has been deeply ingrained in the “lean culture” since the late 1980’s. A lot of companies start their improvement efforts by launching a big 5S campaign.
Often, however, these 5S efforts are focused on striving for an audit score rather than focusing on a tangible operational objective.
It is, though, very possible to help bridge the gap by putting the process improvement in 5S terms. By using a language the team already understands, and building an analogy, I have taken a few teams through a level of insight.
For example –
We are trying to develop a consistent and stable work process.
Sort
Rather than introduce something totally new, we looked at the process steps and identified those that were truly necessary to advance the work – the necessary. The team then worked to avoid doing as many of the unnecessary steps as possible. In their version of 5S, this mapped well to “Sort.”
Now we know the necessary content of the work that must be done.
Set in Order
Once they knew what steps they needed to perform, it was then a matter of working out the best sequence to perform them. “Set in order.”
Now we’ve got a standard work sequence.
Sweep or Shine
The next S is typically translated as something like “Sweep” or “Shine” and interpreted as having a process to continuously check, and restore the intended 5S condition.
Here is where a lot of pure 5S efforts stall, and become “shop cleanup” times at the end of the shift, for example. And it is where supervisors become frustrated that team members “don’t clean up after themselves or “won’t work to the standard.”
In the case of process, this means having enough visual controls in place to guide the work content and sequence, and ideally you can tell if the actual work matches the intended work. A deviation from the intended process is the same as something being “out of place.” Then, analogous to cleaning up the mess, you restore the intended pattern of work.
One powerful indicator is how long the task takes. Knowing the planned cycle time, and pacing the job somehow tells you very quickly if the work isn’t proceeding according to plan. This is one of the reasons a moving assembly line is so effective at spotting problems.
Now we have work content, sequence and maybe timing, or at the very least a way to check if the work is progressing as intended. Plan, Do and Check.
I believe it is difficult or impossible to get past this point unless your cleanup or correction activities become diagnostic.
Standardize
The 4th S is typically “Standardize”
Interesting that it comes fourth. After all, haven’t we already defined a standard?
Kind of. But a “standard” in our world is different. It isn’t a static definition that you audit to. Rather, it is what you are striving to achieve.
Now, rather than simply correcting the situation, you are getting to the root cause of WHY the mess, or the process deviation happened.
In pure 5S terms, you start asking “How did this unintended stuff show up here?”
The most extreme example I can recall was during a visit to an aerospace machine shop in Korea many, many years ago. The floors were spotless. As we were walking with the plant manager, he suddenly took several strides ahead of us, bent down, and picked up….. a chip.
One tiny chip of aluminum.
He started looking around to try to see if he could tell how it got there.
They didn’t do daily cleanup, because every time a chip landed on the floor, they sought to understand what about their chip containment had failed.
Think about that 15 or 20 minutes a day, adding up to over an hour per week, per employee, doing routine cleanup.
If you see a departure from the intended work sequence, you want to understand why it happened. What compelled the team member to do something else?
Likely there was something about what had to be done that was not completely understood. Or, in the case of many companies, the supervisor, for his own reasons, directed some other work content or sequence.
That is actually OK when the circumstances demand it, but the moment the specified process is overridden, the person who did the override now OWNS getting the normal pattern restored. What doesn’t work is making an ad-hoc decision, and not acknowledging that this was an exception.
Once you are actively seeking to understand the reasons behind departure from your specification, and actively dealing with the causes of those departures, then, and only then, are you standardizing. Until that point, you are making lists of what you would like people to do.
This is the “Act” in Plan-Do-Check-Act.
Self Discipline or Sustaining
One thing I find interesting is that early stuff out of Toyota talks about four S. They didn’t explicitly call out discipline or sustaining. If you think about it, there isn’t any need if you are actively seeking to understand, and addressing, causes in the previous step.
The discipline, then, isn’t about the worker’s discipline. It is about management and leadership discipline to stick with their own standards, and use them as a baseline for their own self-development and learning more about how things really work where the work is done.
That is when the big mirror drops out of the ceiling to let them know who is responsible for how the shop actually runs.
