Thoughts and Insights from the Shop Floor
As of about 12:30 Pacific 11/4 there have been a couple of revisions, so be sure to download the latest.
Mike Rother has released Version 12.0 of the Toyota Kata handbook on his website.
The handbook, over the last few iterations, has become much more pragmatic (and practical).
The information about the coaching process is greatly improved. I’d say it backs up my own experience and learning pretty well.
I have been noticing a significant linguistic difference between those who still embrace the “implement the tools” paradigm, and a much smaller (but growing) group are are adopting the PDCA thinking structure as a framework for everything else.
It comes down to how a problem is stated.
We were looking at an operation with a lot of variation from one team member to another, both in terms of performance, and actually, what precisely was being done.
When asked what the obstacle was, the immediate reply was “Lack of standard work.”
While this may have been true, it is not a statement of the problem. Rather, it is defining the problem as “lack of a specific solution.”
This may seem to be an semantic discussion, but consider what the responsible supervisor hears, and interprets, from these two statements:
“There isn’t any standard work.”
or
“There is a lot of variation from one operator to another.”
In the first case, we are telling the supervisor what she isn’t doing, hasn’t done, needs to do. It isn’t even teaching.
In the second case, we are pointing out something that we can both agree on. I haven’t even said it is a problem, and honestly, in some cases it might not be (yet). It is a simple observation.
If, then, we agree that this variation is leading to some undesirable effect, then we can talk about countermeasures. That might include trying to capture a baseline, teach it to a few of the team members, and see if that helps. We can name it later.
Which of those approaches is more likely to enlist the support of the supervisor, which is more likely to put her on the defensive?
Lean thinking is not a checklist of which tools are in place. It is a step-by-step convergence on smoother flow, dealing with observed obstacles and problems.
This isn’t to say that the coach doesn’t have intimate knowledge and experience with flow, with standard work, and everything else. But the approach must be respectful of the people who are struggling with the real world issues every day. Saying “You need to implement standard work” isn’t helpful no matter how much logical justification is wrapped around it.
Teaching someone to observe the impact of variation on the process might seem slower, but it will get them there much faster because it engages their curiosity.
We had five sequential operations. Although the lowest repeatable times for each were well within the planned / target cycle time, there was a lot of variation.
Though Operation 3 was working pretty continuously, Operations 4 and 5 (downstream) were getting starved on occasion, and the empty “bubble” was working its way to the output. The exit cycles, therefore, were irregular enough that they weren’t making rate.
The team set their target to stabilize Operation 3, with the expectation that doing so would smooth out the overall exit cycles.
To that end, they went back and started to study Operation 3 in a little more detail to better understand the obstacles that were impacting the Team Member’s ability to complete the work smoothly.
Then a wrinkle – a different team member was now doing the work, and his cycles were faster.
This actually was an opportunity. Why is one Team Member faster than another?
Their hypothesis was that the faster Team Member had some knack or technique, that enabled him to perform more consistently. And indeed, he did have a few tricks.
So the first experiment was to capture this work cycle in a Job Breakdown, then see if using Job Instruction and teaching it to the first Team Member they could duplicate the results of the second.
Then another wrinkle. The first team member was back on the job. Armed with the knowledge gained by breaking down the steps, key points and reasons for Team Member #2, they took more baseline data from Team Member #1 to set up their experiment.
…only to discover that Team Member #1 was also doing things that #2 didn’t do.
One of those things was unbending a part that was sometimes being bent by an upstream operation.
It seems that #2 was just passing those along as he got them. With that background, the conversation went something like this:
“What obstacle are you addressing?”
“The manual rework in Operation 3 is adding variation and extending his cycles.”
“What experiment are you running next?”
“We think the jig being used in Operation 1 is a bit undersize, allowing the part to deform. We are going to adjust the jig to the proper size.”
“What do you expect from that?”
“We expect to eliminate bent and deflected parts, and see more consistency in Operation #3’s cycles.”
Then they tried it. Skipping ahead a bit:
“What actually happened?”
“The parts are now more consistent, and there Operation #3 has a lot less variation, and is running closer to the planned cycle time… except that now he is waiting on parts from the upstream operation.”
“Huh. What is happening there? What did you just learn?”
“Well, it looks like Operation #3’s variation was masking inconsistent delivery from Operation #2. That team member is operating in small batches, then turning and delivering 3-5 parts at a time. When there was a lot of variation in Op #3, those parts were kind of buffering everything. Now he is working more consistently and faster, and ends up waiting on parts.”
“Because of the layout, the Operation #2 Team Member has to turn to his left and pass the parts behind him. He said he batches so he doesn’t have to turn so often. So what we are thinking is we want to…”
“Hang on, I want to stick to the structure so you guys can practice hearing and responding to it… So – what is your next step?”
“We talked to the team members, and they all agree that if we straighten out that bend in the layout, this will be a lot easier on them, so we are going to do that during the lunch break.”
“And what do you expect from that?”
“Operation #3 will get his parts one-by-one, as they are ready, and won’t have to wait on them.
“Great, so when can we see what you have learned?”
“Give us about 30 minutes after lunch break is over.”
You can probably surmise that things smoothed out a bit.
Then they went back to capturing a hybrid of the best practices of both operators in a job breakdown. At this point, the Team Members were genuinely interested in how they were doing, and both were quite open to learning the “tricks” of the other, so “Get the worker interested in learning the job” had pretty much been done.
A lot was learned over a few hours.
The “real world” is often quite a bit messier than the real world. There was actually a lot more dialog than I reconstructed here to keep the “learners” on track and focused on their stated target vs. resorting to an action of “improvements.”
In addition, merely beginning to work on one obstacle revealed enough information that they were dealing with a different underlying problem.
At another point in the week, they also believed they saw a need for more consistent part presentation. I happened to agree with them, but…
when pressed for what result they expected, the initial response was “The parts will be consistently presented.”… but what does that have to do with your target?
That was tough because, at the time, they were looking at the cycles of the 2nd operator that were, actually, pretty consistent, and lost sight of the fact that they were working on reducing the overall variation of output from that position.
They had a very hard time articulating why consistent part presentation would address the issue, even though they knew it should.
I think this is the result of years of conditioning that the “tools” – such as consistent part presentation – are good for their own sake, without really examining the underlying problems and causes that are being addressed.
If we lean practitioners are scratching our heads wondering why people don’t see this stuff helps, it would be a lot easier to deal with if we could point to the issue being addressed at the moment.
More tomorrow.
While we lean practitioners seem to have earned a reputation of distain for high-speed automation, industries like mass production consumables, and the food and beverage industry, would not be viable without that approach.
These plants are capital intensive, and the main focus of the people is to keep the equipment running. I hinted at some of these things a couple of years ago from the Czech Republic.
Here are some more recent thoughts.
This is not a paradox at all. People are the ones who are getting cranky equipment to run, scurrying about clearing jams, clearing product that got mangled. Until you have a “lights out” plant, people are critical to keeping things running.
In a purely manual world, you can get away with burying issues under more people and more inventory.
With interconnected automated equipment, not so much. The hardware has to run. It all has to run or there is no output.
How the organization responds to a technical problem makes the difference between quickly clearing the issue, or struggling with it for a couple of hours while everything else backs up.
This is where standard processes are critical, not only to short-term success, but also to capture new information as it is learned. This is the “chatter as signal” issue I have written about a couple of times.
Quoting from the above link:
Most organizations accept that they cannot possibly think of everything, that some degree of chatter is going to occur, and that people on the spot are paid to deal with it. That is, after all, their job. And the ones that are good at dealing with it are usually the ones who are spotlighted as the star performers.
The underlying assumptions here are:
- Our processes and systems are complex.
- We can’t possibly think of and plan for anything that might go wrong.
- It is not realistic to expect perfection.
- “Chatter is noise” and an inevitable part of the way things are in our business.
Those underlying assumptions say “Our equipment is complicated and difficult to get adjusted. All we can do is try stuff until it runs.”
That assumption actually lets people off the hook of actually understanding the nuances of the equipment; as well as letting them off the hook of a disciplined approach to troubleshooting. The assumption essentially says “We can’t do anything about it.”
A dark side of this designed ignorance is that the only thing leaders are really able to do is hover about and apply psychological pressure to “do something” or, at best, contribute to the noise of “things to try.”
Neither of those is particularly helpful for an operator who is trying to get the machine running. Both of those actually have a built-in implication that the operator (1) Does not know how to do his job or (2) Is somehow withholding his expertise from the situation.
But we get a different result from the alternative assumptions:
On the other hand, the organizations that are pulling further and further ahead take a different view.
Their underlying assumptions start out the same, then take a significant turn.
- Our processes and systems are complex.
- We can’t possibly think of and plan for anything that might go wrong.
- But we believe perfection is possible.
- “Chatter is signal” and it tells us where we need to address something we missed.
What does this look like in practice?
A known starting condition for all settings, that is verified.
A fixed troubleshooting checklist for common problems (that starts with “Verify the correct initial settings).
What things should be verified, in what sequence? (Understand the dependencies).
If a check reveals an issue, what immediate corrective action should be taken?
I would also strongly recommend using the format of a Job Breakdown (from TWI Job Instruction) for all of this. It is much easier to teach, but more importantly, it really forces you to think things through.
Of course, the checklist is unlikely to cover everything, at least at first. But it does establish a common baseline, and documents the limit of your knowledge.
The end of the operator checklist then defines the escalation point – when the operator must involve the next level of help.
It takes robust problem solving skills (and willingness to take the time to use them) to develop these processes; but doing so can save a mountain of time that pays back many times over.
The alternative is taking the time to mess with things until it sort of works, and never really understanding what was done or what had an effect – every single time there is an issue.
Cry once, or cry every day.
The obvious answer is that, if done well, it will save time.
The more subtle effect is that it sharpens the organization’s knowledge base, as well as their ability to really understand the nuances of the equipment. But this must be done on purpose. It isn’t going to happen on its own.
By getting things up and running sooner; and reducing the time of stoppages; it increases equipment capacity.
But more importantly, all of this increases people capacity.
It gives people time to think about the next level of problems rather than being constantly focused on simply surviving the workday. Of course you need the right organizational and leadership structure to support that.
When we did the first “Toyota Kata” based kaizen event here a second shift lead came up and told me “I’ve been working here 34 years and this week I learned what my job is.”
In most companies leads are expediters charged with forcing product out of the process when the system breaks down.
As we have introduced better flow into this process, things generally work better for overall output, but obstacles still occur.
The leads now assume a critical role for daily kaizen. They are the nerve endings for the entire production process. They are the ones who see the issues when they are small.
We are working with them this week to develop their skills to see, and capture those issues – the rough spots where the production team members struggle a bit to get things working; or where the team needs to bypass the intended process flow to make things work.
By helping them see the difference between smooth flow and rough flow, we are increasing the sensitivity of those nerve endings, and starting to flush out more sources of unplanned variation in a process with a fair amount of part and cycle variation.
At the same time, we are working with the core shop floor leadership team running then through PDCA cycles to develop their skills for improving flow.
What is kinda cool is that it is working, and the linguistic patterns (which reflect thought patterns) are shifting.
Mike Rother sent out an email today pointing out that the Lean Enterprise Institute’s web site now has a Toyota Kata page.
I believe this is a significant event for the lean community as a whole, as well as for the LEI.
As many of my regular readers know, I have maintained the view that the LEI had not kept up with the current state of knowledge about what makes “lean” work.
When the LEI published Kaizen Express in 2009, I wrote a review that addressed this topic. The review had two parts. One part about the book itself, and the other about the context of the community’s knowledge at the time.
I think it is a great book, for 1991.
But this is 2009. So while Kaizen Express is a welcome refresher of the mechanics, those mechanics are, according to the current standing theory, built upon a foundation of something that Kaizen Express
, and for that matter, the LEI has not, to date, addressed. What is missing, in my view, is how the tools and practices outlined in Kaizen Express
When Toyota Kata was published, I believe it closed that gap for the community at large. But I felt a bit of irony that while Mike Rother had co-authored the LEI’s flagship workbook Learning to See, Toyota Kata was not only outside the LEI’s community at the time, it was hardly acknowledged to exist.
The purpose of this post is to acknowledge that a significant step has been taken: For the first time in many years, the LEI is embracing material that they did not originally publish.
From my perspective, this looks like a turning point away from the path of irrelevance.
A great insight from a client today.
The target condition at this point is simply to establish some degree of transparency of the current condition on a status board without having to resort to probing questions to elicit what is working, and what is not.
The observation was:
“We’ll know we are succeeding when we see a failure.”
In other words, “no problem is a big problem” but I think this says it just as well.
Coincidently my experience this week ties in nicely to the last post.
I have a couple of teams working to develop pull systems through their respective work areas.
The conventional approach (I suppose) is a lot of PowerPoint about kanban, some exercises, developing a future state value stream map, then devising an implementation plan.
An alternative approach is to have a small group of experts design the system.
Most of the time this results in a fairly arduous process of wringing out the issues once the system goes live. If the team isn’t prepared for that, it is likely the system will come apart as people bypass it out of necessity to get the work done.
What I am watching this week is more organic.
First, we covered a few fundamentals about flow and pull signals in a simple demonstration of “build and push” vs. one-piece-flow with a visual limiter on work-in-process inventory. They saw the throughput, productivity, stability, visibility all increase while lead time dropped by an order of magnitude. That took about an hour.
The team then set up a tabletop simulation of their existing work flow, and exercised it a few times to confirm that it is a fair representation of the way things actually work today. In doing so, they gain more understanding of the current condition because they have to replicate it.
They then set out to make their far more complex real-world situation work more like what they saw in the demonstration. To help them get started, they were given some suggestions about a few things to try, and some basic principles and rules.
Some of that advice included restricting changes to a single factor at a time, and predicting what would happen, then trying it. If you find yourself speculating, or discussing alternative speculations, try it and see.
Two days into it, the teams have full-blown multi-loop kanban working, and are devising experiments to learn how the system responds to things like machines going down, unpredicted shifts in product mix, and other things they normally need to respond to.
They are exploring not only the mechanics and the rules, but the dynamics of the process in operation. They are learning what “normal” looks like in the face of abnormal conditions. They are testing the boundaries – where and when does it break, and what does “broken” look like vs. something that will recover on its own.
They are figuring out how to make it more robust, without making it cumbersome or too complicated.
They are gaining confidence and a deep understanding by iterating through ever more complex scenarios.
The people doing this are the ones who will be working IN the system in the future. We are seeing who emerges as thought leaders.
What they have right now – mid week – is a crystal clear view of their target condition, and they are very confident that they can make it work in their real world. Are there unknown issues? Sure. There always are. Translating this to the real world will involve more cycles of iteration. Only now they know exactly how to do those iterations because they have practiced dozens of times already.
This is actually less about kanban than it is about learning how to gain knowledge about something previously unknown.
It is pretty cool to watch, and a lot more fun (for everyone) than just implementing a process designed by someone else. Even the skeptics get drawn in when people are working hands-on to try to make something work.
Oh – and I’m really glad this process works because that saves me from having to know the answers.
The key points addressed today (Day 3) at the Toyota Kata seminar were:
Even though the book and course material are quite explicit, a couple of people in the room weren’t readily grasping this until today.
Who Is Being Coached?
In the Kata model, the first level of “learner” is the first line leader who has direct responsibility for the process, and the people who work in it.
On a production floor, this would be the area supervisor.
The core material of the course is how to plan and execute continuous improvement in your work group. This is called the “Improvement Kata”
The “Coaching Kata” is covered and demonstrated (quite well), but it is not the prime topic this week.
Who is doing the coaching?
The coach is nominally the direct supervisor of the person being coached.
To learn how to coach, one must first learn the game. Thus, no matter your role in the organization chart, you come to this seminar gain awareness of the role of your first line leaders.
Then you go home and practice the role some more. Once you have lived in their shoes, then you can turn around and expect them to do the same.
What is absolutely critical to understand here is that this is not a “kaizen event” model. This is a daily improvement model. The coaching cycle happens for a few minutes every day between front line supervisor and the immediate manager. It is a process for developing better supervisors. It cannot (or at least should not) be delegated.
Here is the crucial difference: In many kaizen events, the specialist staff workshop leader is the one directing the actions of the team. The area supervisor may be a member of the team, but she is often not the one actually guiding the effort. In this model, there is no “learner” because there is no deliberate process to improve the problem solving and leadership skills of the supervisor.
If the course has a weak point it is that we “learners” are organized in a way that LOOKS more like a traditional kaizen team, which shifts the instructor / coach more into a role that LOOKS like that of the traditional kaizen workshop leader. Thus, it is easy for a participant to slip into a well-engrained mindset about kaizen events. We have all “practiced” the kaizen event pattern many times. The “kata” pattern is new.
This is the nature of the instructor coaching a group of “learners” rather than the 1:1 that is designed to happen in reality.
So, advice if you decide to attend: Be explicitly conscious that the structural limitations of the course, and deliberately work to overcome them in your mindset. This will help you grasp the material that you are there to learn.
That being said, I have a very explicit picture now of how I want shop floor supervisors to behave and lead. I have a pretty good idea of how to help them get there.
I’ve got an early flight, more later.
I am taking the Toyota Kata seminar this week in Ann Arbor. There are two programs offered:
I am taking the three day version.
There are about (quick count) 36 participants, a big bigger group than I expected considering the premise. I don’t know how many are not going to be attending the shop floor part, but most people are.
I suppose the ultimate irony is the slide that makes the point that classroom training doesn’t work very well for this.
Realistically, I can see it as necessary to level-up everyone on the concepts. The audience runs the gamut of people who have read, studied, written about, made training material from, and applied the concepts in the book; to people who seem to have gone to the class with quite a bit less initial information.
That being said, everyone had some kind of exposure to lean principles, though there was a lot of “look for waste” and “apply the tools” mindset present. Since one of the purposes of the class is to challenge that mindset, this is to be expected.
You can get a good feel for the flow and content of the material itself on Mike Rother’s web site. He has a lot of presentations up there (via Slide Share).
Like any course like this, the more you know when you arrive, the more nuance you can pull out of the discussion.
Since I have been trying to apply the concepts already, my personal struggles really helped me to get a couple of “ah-ha” moments from the instruction.I arrived with a clear idea of what I wanted to learn, and what I thought I already knew. Both pre-disposed me to get insight, affirmation, and surprise learning from the material.
I would not suggest this for anyone who was looking to be convinced. Classroom training in any case doesn’t do that very well, and this material isn’t going to win over a skeptic. You have to be disposed to want to learn to do it.
At the end of the day, the overall quality, etc. of the presentation was pretty typical of “corporate training” stuff – not especially riveting, but certainly interesting. But we don’t do this for the entertainment value, and the learner has a responsibility to pull out what they need in any case.
Day 1 is intended, and sold, as a stand-alone. The next two days are available as follow-on, but not separately.
The intended purpose was to practice the “improvement kata” cycle in a live shop floor environment. Today was spent:
Key Points that are becoming more tangible for me:
I elaborated on Bill Costantino’s (spelled it right this time) presentation on this concept a while ago. In the seminar, I am “groking” the concept of threshold of knowledge a bit better. Here is my current interpretation.
There are really three thresholds of knowledge in play, maybe more. First is the overall organization. I would define the organizations’ threshold of knowledge as the things they “just do” without giving it any thought at all.
For example – one company I know well has embedded 3P into their product design process to deeply that the two are indistinguishable from one another. It is just how they do it.
They still push the boundaries of what they accomplish with the process, but the process itself is familiar territory to them.
Likewise, this company has a signature way to lay out an assembly line, and that way is increasingly reflected in their product designs as 3P drives both.
It wasn’t always like that. It started with a handful of people who had experience with the process. They guided teams through applying it, in small steps, on successively more complex applications until they hijacked a design project and essentially redid it, and came out with something much better.
Another level of knowledge threshold is that held by the experienced practitioner.
Today I walked into a work cell in the host company for the first time, and within a few minutes of observation had a very clear picture in my own mind of what the next step was, and how to get there. My personal struggle today was not in understanding this, but in methodically applying the process being taught to get there. I knew what the answer would be, but I wasn’t here to learn that.
An extended threshold of knowledge in one person, or even in a handful of people, is not that useful to the company.
But that is exactly the model most kaizen leaders apply. They use their expert knowledge to see the target themselves, and then direct the team to apply the “lean tools” to get there.
They tell the team to “look for waste” but, in reality, they are pushing the mechanics. You can see this in their targets when they describe the mechanics as the target condition.
The team learns the mechanics of the tools, but the knowledge of why that target was set remains locked up in the head of the staff person who created it.
So his job is to set another target condition: Expanding the threshold of knowledge of the team.
He succeeds when the team develops a viable target themselves. It might be the same one he had, but it might not. If he framed the challenge correctly, and coached them correctly, they will arrive at something he believes is a good solution. If they don’t he needs to look in the mirror.
So the next level of knowledge threshold is that held by the team itself.
If enough teams develop the same depth, then they start to interconnect and work together, and we begin to advance the organization’s threshold. Now what was previously required a major “improvement event” to develop is just the starting baseline, and the ratchet goes up a bit.
None of the above was explicitly covered today, but it is what I learned. I am sure I’ll get an email from a certain .edu domain if I am off base here. 
This is the third explicit approach I have been taught to do this.
The first was called a “Scan and Plan” that I learned back in the mid/late 1990’s. It was more of a consultant’s tool for selecting a high-potential area for that first “Look what this can do” improvement event.
Though I don’t use any of those forms and tools explicitly, I do carry some of the concepts along and apply them when appropriate.
Then I was exposed to Shingijutsu’s approach. This is heavily focused on the standard work forms and tools. Within the culture of Shingijutsu clients, it would be heresy not to use these forms.
The “Kata” approach targets pretty much the same information, but collects and organizes it differently. I can see, for myself, a of better focus on the structure of establishing a good target. I can also see a hybrid between this method and what I have used in the past. Each form or analytical tool has a place where it provides insight for the team.
One thing I do like about the “Kata” data collection is the emphasis on (and therefore acknowledgement of) variation in work cycles. (All of this is in the book by the way. Read it, then get in touch with me if you want some explanation.)
Now, I want to be clear – in spite of the title of this section, when I am coaching beginners, I will be dogmatic about the tools they use. In fact, I plan to be a lot more dogmatic than I have been.
I am seeing the benefit of providing structure so that is off the table. They don’t have to think about how to collect and organize the data, just getting it and understanding it.
What I can do, as someone with a bit more experience, is give them a specific tool that will give them the insight they need. That is where I say “no dogma.” That only applies when the principles are well within your threshold of knowledge.
The real ah-ha is that, unlike the Shingijutsu approach, we weren’t collecting cycle times at the detailed work breakdown level. Why not? Because, at this stage of improvement, at this stage of knowledge threshold for the team, the work cell, that level of detail is not yet necessary to see the next step.
I will become necessary, it just isn’t necessary now.
One place where my work team bogged down a bit this afternoon was mixing up the target condition that we are setting for a week from now, and what we are going to try first thing in the morning.
The target condition ultimately requires setting up a fairly rigid standard-work-in-process (SWIP) (sometimes called “standard in-process stock) level in the work cell.
There was some concern that trying that would break things. And it will. For sure. We have to stabilize the downstream operation first, get it working to one-by-one, and make sure it is capable of doing so.
The last thing we want to do while messing with them is to starve them of material.
So – key learning point – be explicitly clear, more than once, that the Target Condition is not what you are trying right away. It is the predicted, attainable, result of a series of PDCA steps – single factor experiments. You don’t have the answers of how to do it yet. So don’t worry about the SWIP level right now. That will become easier… when it is easier.
More tomorrow…