The Lean Thinker

November 10, 2013January 9, 2019

Learning To See in 2013

With the publication of Learning to See in 1999, Mike Rother and John Shook introduced a new genre of book to us – a mix of theory, example, and practical application. The story invites the readers to follow along and actually do for themselves.

This is one of those books that gives a bit more every time I read it. The more thorough my baseline understanding of TPS, the more I get from some of the nuances of Rother and Shook’s intent.

At the same time, I am beginning to formulate an idea that perhaps this book is often used out of its intended context – maybe a context that was assumed, but left unsaid.

I’d like to share some of the things I have learned over the years, especially as I have worked to integrate the concepts in Learning to See into other facets of the TPS – especially research by Steven Spear, Jeff Liker, and of course, Mike Rother’s follow-on work Toyota Kata with my own experience.

Value Streams

Learning to See introduced the term “value stream” to our everyday vernacular.

Although the term is mentioned in Lean Thinking by Womack and Jones, the concept of “map your value streams” was not rigorously explained until LTS was published.

To be clear, we had been mapping out process flows for a long time before Learning to See. But the book provided our community with a standard symbolic language and framework that enabled all of us to communicate and share our maps with others.

That, alone, made the book a breakthrough work because it enabled a shorthand for peer review and support within the community.

It also provided a simple and robust pattern to follow that breaks down and analyzes a large scale process. This enabled a much larger population to grasp these concepts and put them to practical use.

Learning to See and “Getting Lean”

In Chapter 11 of Lean Thinking, Womack and Jones set out a sequence of steps they postulate will transform a traditional business to a “lean one.”

The steps are summarized and paraphrased in the Forward (also by Womack and Jones) of Learning to See:

Find a change agent (how about you?).

Find a sensei (a teacher whose learning curve you can borrow)

Seize (or create) a crisis to motivate action across your firm.

Map the entire value stream for all of your product families.

Pick something important and get started removing waste quickly, to surprise yourself with how much you can accomplish in a very short period.

Learning to See focuses on Step 4, which implies establishing a future-state to guide you.

In the Forward, Womack and Jones commented that people skipped Step 4 (map your value streams). Today, I see people skipping straight to that step.

Let’s continue the context discussion from the Forward, then dig into common use of the value stream mapping tool..

“Find a change agent (how about you?)” is a really interesting statement. “How about you?” implies that the reader is the change agent. I suspect (based on the “change agents” discussed in Lean Thinking that the assumption was that the “change agent” is a responsible line leader. Pat Lancaster, Art Byrne, George Koenigsaecker were some of the early change agents, and were (along with their common thread of Shingijutsu) very influential in the tone and direction set in Lean Thinking.

Today, though, I see job postings like this one (real, but edited for – believe it or not- brevity):

Job Title: Lean Manager

Reports To: Vice President & General Manager of Operations

Summary:

Lead highly collaborative action-based team efforts to clean out, simplify and mistake-proof our processes and our strategic suppliers’ processes.

This includes using proven methodological approaches, applying our culture and providing our team with technology, best cross-industry practices and all other resources needed to attain ever higher levels of productivity and customer delight.

Essential Duties and Responsibilities:

Endlessly define, prioritize and present opportunities for applying AWO’s, GB/BB projects and other LEAN principles to our supply chain and customer deliverables.

Develop, plan and execute the plans as selected by the business leaders.

Train all team members (and other selected individuals) in LEAN principles and mechanisms to be LEAN and preferred by customers.

Document procedures/routines, training, team results/best practices and the like.

Coaches business team members in the practical application of the Lean tools to drive significant business impact.

Leads and manages the current state value stream process.

Develops and implements future state value stream processes.

[…]

Responsible for planning and assisting in the execution of various Lean transformation events targeted towards improving the business’s performance on safety, quality, delivery, and cost.

Focuses on business performance that constantly strives to eliminate waste, improve customer satisfaction, on-time delivery, reduce operating costs and inventory via the use of Lean tools and continuous improvement methodologies.

[…]

Acts as change agent in challenging existing approaches and performance.

Whew. With all of that, here is my question: What is the line leadership expected to do? In other words, what is left for them to do? And what, exactly, are they supposed to be doing (and how) during all of this flurry of activity?

While all of the “change agent” examples outlined in Lean Thinking (which, in turn, provides context for Learning to See), are line leaders, all too often the role of “change agent” is delegated to a staff member such as the above.

I believe it is entirely possible for a line-leader change agent to also be the “sensei” – Michael Balle’s The Lean Manager shows a fictional scenario that does just that.

But if your “sensei” is a staff technical professional, or an external consultant, the “change agent” function is separate and distinct, or should be.

Which leads me to the first question that is never asked:

Why Are You Doing This At All?

That question can be a pretty confrontational. But it is a question that often goes unasked.

This is especially true where “getting lean” is an initiative delegated to staff specialists, and not directly connected to achieving the strategic objectives of the business. In these cases, “Lean” is expressed as a “set of tools” for reducing costs.

I do not believe that “creating a crisis” is constructive, simply because when motivated by fear people tend to (1) panic and lose perspective and (2) tend to apply habitual responses, not creative ones. If there are high stakes at risk, creativity is not what you should expect.

On the other hand, a narrow and specific challenge that is set as Step Zero helps focus people’s attention and gives them permission not to address every problem all at once (which avoids paralysis and gridlock).

So, if I were to edit that list of steps, I’d change “Create a crisis” to “Issue a challenge to focus the effort” and move it to #1 or maybe #2 on the list. The “Find a sensei” then becomes a countermeasure for the obstacle of “We need AND WANT to do this, but don’t have enough experience.” (That assumption, in turn, implies a driving need to learn doesn’t it?)

These are appropriate roles for the “change agent” – and they are things that can only be effectively done from a position of authority.

Which brings us to back to Learning to See.

Beyond “Value-Added”

Someone, a long time ago, proposed that we categorize activities as “value-added” or “non-value-added.”

We say that a “value-added step” is “something the customer is willing to pay for.” A “non-value-added step” is anything else. Some non-value-added steps are necessary to advance the work or support the business structure.

While this analysis is fundamentally correct at the operational level, and works to get a general sense of what it possible, this approach can start us off on a journey to “identify and eliminate waste” from the process. (Not to mention non-productive debates about whether a particular activity is “value added” or not.)

Right away we are limited. The only way to grow the business using this approach is to use the newly freed up capacity to do something you aren’t doing now. But what?

If that decision hasn’t been made as a core part of the challenge, the leaders are often left wondering when the “lean initiative” will actually begin to pay – because they didn’t answer the “Why must we do this?” question from the beginning.

Without that challenging business imperative, the way people typically try to justify the effort is to:

Analyze the process.
Try to quantify the waste that is seen. This would be things like inventory, walking distance, scrap, etc. that are easily measurable. More sophisticated models would try to assign value to things like floor space.
Add up the “proposed savings”
Determine a return on the investment, and proceed if it is worth it.

The idea, then, would be to deliver those savings quickly with some kind of rapid improvement process.

This fundamental approach can be (and is) taken at all levels of the organization. I have seen large-scale efforts run by a team of consultants doing a rapid implementation of an entire factory over a timespan of a few weeks.

I have also seen that same factory six months later, and aside from the lines that were painted on the floor and the general layout changes, there was no other sign the effort had ever been undertaken. In this case, no matter how compelling the ROI, they didn’t get anywhere near it.

One of the tools commonly (ab)used for this process is value stream mapping.

This approach is SO common that if you search for presentations and training materials for value stream mapping on the web, you will find that nearly all of them show describe this process:

Map your current state map.
Identify sources of waste and other opportunities on the current state map.
Depict those opportunities with “kaizen bursts” to show the effort you are going to make.
Based on what opportunities you have identified, and your proposed kaizen bursts, develop the future state map to show what it will look like.
Develop the new performance metrics for the future state.
Viola – make the case to go for it.

Now – to my readers – think for a minute. Where are the “kaizen bursts” in Learning to See? They are on the current state map, right?

Nope.

Here is the current state map on page 32:

If, on the other hand, I were to ask “What value do we wish we could create for our customers that, today, we cannot?” I open myself up to a host of possibilities, including creating a new value stream that currently doesn’t exist at all – using freed up resources, at essentially zero net cost (or at least heavily subsidizing the new effort).

Now I ask “What must I do to make these resources available to me?”

In the “find and eliminate waste” model, the staff-change agents are often responsible for the “lean plan.” Like the job description above, they are charged with convincing the leaders (who hired them!) that this all makes business sense.

A Manual for How to Meet a Challenge

In “Part III: What Makes a Value Stream Lean” (the green tab) there is a strong hint of the original intent in the second paragraph:

To reduce that overly long lead time from raw material to finished goods, you need to do more than just try to eliminate obvious waste.

This statement implies that the value stream mapper is dissatisfied with the current lead time, and has a compelling need to change it.

What you are looking for in the Future State is how must the process operate to get to the lead time reduction you must achieve.

For example, given a target lead time and a takt time, I can calculate the maximum amount of work-in-process inventory I can have and still be able to hit that objective.

I can look at where I must put my pacemaker process to meet the customer’s expectations for delivery.

Based on that, I can look at the turns I must create in the pull system that feeds it.

Based on that, I can calculate the maximum lot sizes I can have; which in turn, drives my targets for changeovers.

As I iterate through future state designs, I am evaluating the performance I am achieving vs. the performance I must achieve.

What is stopping me from making it work?

What must I change?

If something is too hard to change, what can I adjust elsewhere to get the same effect?

In the end, I have a value stream architecture that, if I can solve a set of specific problems, will meet the business need I started with.

This is my view on the fundamental difference between creating a generic “crisis” vs. stating a compelling performance requirement.

The process outlined in the book is to develop the future state, and then identify what is stopping you from getting there.

Of the eight KEY QUESTIONS FOR THE FUTURE STATE that are outlined in page 58, “What process improvements will be necessary for the value stream to flow as your future state design specifies?” is question #8.

It is the last thing you consider.

The kaizen bursts are not “What can we do?”

They are “What must we do?”

The first thing you consider is “What is the requirement?”

“What is the takt time?”

In other words, how must this process perform?

Here is a clip of the future state map from page 78:

The “bursts” are not “opportunities” but rather, they represent the things we have to fix in order to achieve the future state.

In Toyota Kata terms, they represent the obstacles in the way of achieving the target condition, just at a higher level.

What this is saying is “To achieve the future state we need to rearrange the work flow AND:

Get the stamping changeovers down to 10 minutes or better.
Get the weld changeovers to where we can do them within the takt.
Get the welder uptime to 100%.
Get the work content for weld + assembly down to under 168 seconds.”

These are the obstacles to achieving the performance we want from the future state value steam.

Notice that the stamping press only has an uptime of 85% on the current state map. There isn’t a corresponding kaizen burst for that – because, right now, it isn’t in the way of getting where we need to go. It might be an issue in the future, but it isn’t right now.

But if we were just “looking for waste” we might not see it that way, and spend a ton of time and resources fixing a problem that is actually not a problem at the moment.

Putting This Together

Thus, I suspect that Learning to See, like many books in the continuous improvement category, was intended for value stream leaders – managers who are responsible for delivering business results.

In my experience, however, most of the actual users have been staff practitioners. Perhaps I should use the 2nd person here, because I suspect the vast majority of the people reading this are members of that group.

You are a staff practitioner if you are responsible for “driving improvement” (or a similar term) in processes you are not actually responsible for executing on a daily basis. You are “internal consultants” to line management.

Staff practitioners are members of kaizen promotion offices. They are “workshop leaders.” They are “continuous improvement managers.” The more senior ones operate at the VP and Director level of medium and large size companies.

No matter what level of the organization, you are kindred spirits, for most of my post-military / pre-consulting career has been in this role.

The people who actually read and study books like Learning to See are staff practitioners.

This creates a bit of a problem, because Learning to See is very clear that the responsible manager should be the one actually building the value stream map. But often, that task is delegated to the staff practitioner.

“Map this value stream, and please present your findings and recommendations.” If you have gotten a request or direction like that, you know what I am talking about. Been there, done that.

In my personal experience, although it gave me valuable experience studying process flows, I can honestly say that relatively few of those proposed “Future States” were actually put into practice.

The one that I vividly remember that was put into practice happened because, though I was a kaizen promotion office staffer, I had start-up direct responsibility for getting the process working, including de-facto direct reports. (That is a different story titled “How I got really good at operating a fork lift”)

Into 2013

Today we see Toyota Kata quickly gaining popularity. The Lean Bazaar is responding, and “coaching” topics are quickly being added to conference topics and consulting portfolios.

I welcome this because it is calling attention to the critical people development aspect that distinguishes the Toyota Management System from the vast majority of interpretations of “lean” out there.

But make no mistake, it is easy to fall into the tools trap, and the Lean Bazaar is making it easier by the way it positions its products.

Just as value stream mapping isn’t about the maps, establishing an improvement culture isn’t about the improvement boards, or the Kata Kwestions.

It is about establishing a pervasive drive to learn. In that “lean culture,” we use the actual process as a laboratory to develop people’s improvement skills. We know that if we do the right job teaching and practicing those skills, the right people will do the right things for the process to get better every day. Which is exactly what the title of Learning to See says.

November 6, 2013January 9, 2019

Creating an Empowered Team

EDIT: There is a follow-on post here: David Marquet: Turn the Ship Around

In the past couple of decades, we went through an “empower your people” fad. We saw work teams in world class companies that were largely self directing, surprisingly well aligned with the overall goals of the organization, and getting things done.

“Well,” we thought, “since empowered teams are obviously more effective, we’ll empower our teams.”

They brandished their wand uttered some wizard’s chant, and bing! empowered their teams.

“What did you expect to happen?”

“We expected our newly empowered teams to self-organize, get the work done, plan all of their own vacations and breaks, and continuously improve their operations on their own.”

“What actually happened?”

“Work ground to a halt, people argued and squabbled, quality went to hell, and labor hours went up 20%”

“What did you learn?”

“That empowerment doesn’t work.”

Which is obviously not true, because there are plenty of examples where it does. Perhaps “Empowerment doesn’t work the way we went about it” might be a better answer. That at least opens the door to a bit more curiosity.

The last place I would expect an experiment in true empowerment would be onboard a U.S. Navy nuclear submarine.

Take a look at this video that Mike Rother sent around a couple of days ago, then come back.

A U.S. Navy submarine skipper isn’t generally inclined to swear off ever giving another order. It runs against everything he has been taught and trained to do since he was a Midshipman.

I’d like to cue in on a couple of things here and dissect what happened.

First is the general conditions. I think he could do this just a bit faster than normal because everyone involved was sealed inside a steel can for six months. Just a thought – groups in those conditions tend to have a lot of team cohesion.

But the mechanics are also critical. He didn’t just say “You are empowered.” Rather, this was a process of deliberate learning and practice.

What is key, and what most companies miss, are the crucial elements that Capt. Marquet points out must be built as the pillars of an empowered team.

Let’s put this in Lean Thinker’s terms.

As the Toyota Kata wave begins to sweep over everyone, there is a rush to transition managers into coaches.

“What obstacles do you think are now in the way of reaching the target?”

See the illustration above.

Competence and clarity.

I am going to start with the second one.

Clarity

Or… where the hell are we trying to go?

Capt. Marquet points out the critical element of commander’s intent. I learned this during my decade or so as a military officer (U.S. Army). When preparing operations orders, I had to clarify the overall commander’s intent. Why? So that when everything went to hell in a handcart, everyone knew what we were trying to get done even if the how to do it entirely broke down.

What that means in the lean thinking world is “What is the business imperative” or “What is the challenge we are trying to achieve?” If nobody knows “why,” then all they can know is “what” and that comes down to “implement the tools,” which, in turn, comes down to “because I said so” or “Because we need a 3 on the lean audit.”

Doesn’t work. Never has.

But I’m beating that topic to death right now, so I want to move the pillar on the left.

Competence

In my book, that means “The leader has a good idea how to do it.”

What does that mean in practical terms? In Capt. Marquet’s world, it means that, fundamentally, the crew knows how to operate a nuclear submarine. Additionally, it means they understand the ramifications of the actions they are taking on the overall system, and therefore, the contribution they are making to achieving the intent.

It doesn’t matter how clearly anyone understands what they are trying to get done if they have no idea how to do it.

In Lean Thinking world, competence means a few things.

The leader knows how to “do the math.” She understands the overall flow, the impact of her decisions on the system and the overall system.
The leader / coach has a good understanding of at least the fundamentals of flow production, and why we are striving to move in that direction.

While these things can be taught through skillful coaching, that implies that the coach has enough competence to do that teaching.

But if the coach doesn’t fundamentally grasp the True North, or doesn’t consistently bias every single conversation and decision in that direction, then Clarity is lost, and Competence is never built.

We end up with pokes and tweaks on the current condition, but no real breakthrough progress.

Day to day, this means you are on the shop floor interacting with supervisors and front line managers. You are asking the questions, and guiding their thinking until they grok that one-by-one flow @ takt is where they are striving to go.

In my Lean Director role in a previous company, I recall three distinct stages I went through with people calling me for “what to do” advice.

First, I gave them answers and explanations.

Then I transitioned to first asking them what they thought I would give as an answer.

Then they transitioned to “This is the situation, this is the target, this is what we propose, this is why we think it will work, what do you think?”

“Captain, I propose we submerge the boat.”

“What do you think I am thinking?”

“Um… you would want to know if it is safe?”

“How would you know it is safe?”

In other words…

What are you trying to achieve here? How will you know?

So here is a challenge.

If you are a line leader, especially a plant manager, take one week and utterly refuse to issue direction to anyone. Ask questions. Force them to learn the answers. Test their knowledge. Have them teach you so they must learn.

You will learn a lot about the competence of your team. You will learn a lot about your own clarity of intent. Try it on. No matter what, you will learn a lot.

November 5, 2013January 9, 2019

Curiosity

The tenor of what “lean” is about is shifting, at least in some places, toward the line leader as improver, teacher and coach. Successfully adopting that role requires a qualification that I wish I saw more of as I work with industrial clients – curiosity.

To succeed in this role, a supervisor must be intently curious about, not only the minute-by-minute performance, but what things are affecting it, or could affect it.

Even if he is just walking by, his eyes must be checking – is there excess inventory piling up? Are all of the standard WIP spots filled? Is anyone struggling with the job? Are the carts in the right places? Pressures and temperatures OK? Kanbans circulating correctly? Workers all wearing PPE? Safety glasses? Ear plugs? Does the fork truck driver have his seatbelt fastened?

Though there should also be deliberate checks as part of his standard work, a leader needs to be intently curious about what is happening all of the time.

To improve things requires even more curiosity. “What obstacles do you think are now keeping you from reaching the target?” is not a question that should be answered casually. Rather, the preparation to answer it properly requires careful study – being curious – about what operational conditions must be changed to reach the target.

Sadly, though, my experience is that true curiosity is a pretty rare commodity. A plant manager that can spout off a barrage of facts and figures about how things have to be, but is surprised every time the math doesn’t reflect his view of reality doesn’t impress me much.

Niwa-sensai said once (probably many times) “A visual control that doesn’t trigger action is just a decoration.”

You have to be curious about what those visual controls are telling you. What good is a gage if it is supposed to read between 4 and 6, but drops to 0 and nobody notices?

That supervisor walking through the area needs to be visually sweeping those gages, looking for leaks, anything unusual or abnormal, and taking action.

“How did that stain get here?” Run the trap line. The process, as designed, shouldn’t let anything leak. Why did it? What is really happening?

All we practitioners can do is patiently, again and again, walk the line with them, ask what they see, stand in the chalk circle with them, and do our best to teach them to see what we do.

Show them the system, show them the future consequences of letting this little thing slide – how second shift is going to be brought to their knees because the work isn’t being processed according to the FIFO rules.

I suspect, though, that at least a few leaders get promoted and somehow believe they reach a level where they are exempt from checking and teaching. That’s someone else’s job.

But if not them, who? And how do they know it is getting done?

October 4, 2013January 9, 2019

Active Control

Imagine you are driving an automobile with a high-performance suspension. You are on a perfectly straight stretch of road, with smooth pavement. Get yourself up to, say, 65 miles per hour (100 km/h). Got it pointed down the middle of the road?

OK, close your eyes, let go of the steering wheel and wait. (Actually closing your eyes is optional.)

Can you predict what will happen, more likely sooner than later?

It doesn’t matter how “stable” your car is.

There are small, random things that are eventually going to cause your car to drift away from the centerline and off the road, into the ditch on one side, or over the cliff on the other. (Didn’t I mention those?)

I often see people set up a well performing process and treat it the same way – as though it will continue to work the same way forever, without any intervention.

But your process is going to encounter random chatter, and when it does, what typically happens?

In most cases, the team members can find a way to work around the issue, and likely continue to get things done, though they will have added a bit of friction, requiring a bit more effort, to do so. They will add a redundant check to make sure no mistake got made. They will add some inventory under the work bench, in case something runs out. They will carry the product over to the other machine because the one they are supposed to use isn’t working as it should be.

They will clean up the spilled coolant, catch the leaking oil.

They will head up-line to borrow a team member’s grease bucket.

They’ll tap out paint clogged or unthreaded holes, cut wires that are delivered too long to length, even drill new holes to mount the part that doesn’t fit.

In the office, they get one more signature, send an email to back-up the “unreliable” ERP messages, and make screen prints so they can enter the data into another system.

“Waste is often disguised as useful work.”

All of this easily goes unnoticed, and eventually (maybe) the process becomes cumbersome enough that someone decides to address it with an improvement activity. And the cycle starts again.

How do we stop the cycle?

The point of intervention is in the last paragraph… “All of this goes unnoticed.”

It isn’t a matter of standing and watching for problems. Sakichi Toyoda figured that out almost 100 years ago. It is about designing your process to detect anomalies in either execution (how it is done, how long it takes) or results immediately, signal, and trigger some kind of response.

Here are some fundamental questions to ask yourself:

Before the process even begins, does the team member have everything he needs to succeed? How does he know? I’m talking about parts, information, tools, air pressure, assistance… whatever you know is needed to get the job done.

If the team member doesn’t have everything needed exactly what do you want him to do?

Is the team member carrying out the process in a way that gets the desired result? How does she know? Is there a sequence of steps that you know will give her the result you want? What alerts her if one of them is skipped?

If the team member, for whatever reason, isn’t able to carry out those steps in sequence, exactly what do you want her to do? Go find a grease bucket? Or let you know?

How long do you want to allow your team member to try to fix something or make it work before letting you know there is a problem? Related to this – how far behind can you allow him to get before he can’t catch up, even with help?

Once the team member has completed the process, how does he know the result is what was expected? If the team member doesn’t have a way to positively verify a good outcome, who does detect the problem, when, where and how? It might be your customer!

An Active Control System

Even if you have all of those checks in place, however, you still need to answer a few more questions starting with “Once the team member detects a problem, what do you what exactly do you want them to do?”

I alluded a little to this above, but let’s go a bit deeper.

On a production line, a typical way for a team member to signal a problem is with some kind of andon. This might, for example, take the form of a rope along the line that the team member can pull in order to trigger a signal of some kind.

But that is the easy part. Lots of factories have copied the mechanics of Toyota’s andon only to see them fall into disuse following a period of cynicism.

The hard part is what is supposed to happen next?

Now we are back to the original questions because the andon is nothing more than a trigger for another process.

Who is the designated first responder? (Remember, if it is everybody’s problem, it is nobody’s problem.) Does that person know who he is?

What is the standard for the response? What is the first responder supposed to do, and how long does she have to do it?

When we had takt times on the order of dozens of minutes, our standard for the first response making face-to-face contact with the team member who signaled was 30 seconds.

How much intervention can the first responder make before being required to escalate the problem to the next level?

As a minimum

As a minimum, the first responder’s primary goal is to restore the normal pattern of work. This might be as simple as pitching in and helping because something minor tripped up the team member’s timing.

This is active control – a system or process that detects something going outside the established parameters, and applying an adjustment to get it back. Active control requires a process to detect abnormalities, a trigger, and a response that restores things. It is no different than maintaining thickness in a rolling operation – the machine measures the output, and adjusts the pressure accordingly – or an autopilot that keeps an airplane on course.

Without some kind of active control system, your process will erode over time as the team members do the only things they can do in an effort to keep things moving: They can overproduce and build inventory to compensate, they can add extra process steps, they can add just about any of the things we call “waste.”

The only question is what do you want them to do?

September 17, 2013January 9, 2019

Eiji Toyoda 1913-2013

Reuters reports the death of Eiji Toyoda today, 3 days after his 100th birthday.

In the late 1940’s, the fledgling Toyota Motor Company was in financial difficulties, and was forced to lay off workers. As part of the agreement, Kiichiro Toyoda resigned in 1950 and turned the helm of the company over to his cousin, Eiji.

Kiichiro had developed the early concepts of Just In Time production, and his father, Sakichi, had developed the early concepts of stopping a process that was having quality issues (jidoka).

Eiji had to deal with a turnaround situation, and challenged the company to reach U.S. levels of productivity on a very short timeframe. As part of that effort, he assigned Taiichi Ohno, a machine shop manager, to make it all work. The result was what we today call “The Toyota Way.”

Though there were obviously many people involved, Eiji has a huge share of the credit for creating “The Machine that Changed the World.”

September 1, 2013January 9, 2019

Checklists: “Do.” vs. “Did you do?”

When operations or steps get omitted, a common countermeasure is to establish a checklist.

A typical checklist has a list of items or questions – sometimes even written in the past tense.

“Was the _______?”

There are a couple of common problems with this approach.

First, the time to actually, physically make the checks is not included in the planned cycle time. This implies we are expecting the team member to review the checklist and remember what she did.

The second issue is that the team member often does remember doing it even if it wasn’t done.

This is human nature, it isn’t a fault or flaw in the individual. It is impossible to maintain continuous conscious vigilance for any length of time. There are techniques that help, however they require some discipline from leaders.

Overall, a checklist that asks “Did you___?” in the past tense is mostly ineffective in practice.

We make things worse when the checklist is used as a punitive tool and we “write up” the team member for signing off on something that, actually, didn’t get done. Most of the time it does get done, but everyone in this system occasionally misses something. Sometimes those errors get caught. This kind of “accountability” is arbitrary at best.

Where checklists work is in “what to do next” mode – referring to the check list, doing one item, checking off that it was done, then referring to the next item on the list. This is how it works in an airplane cockpit.*

CAPTAIN: okay, taxi check.

FIRST OFFICER: departure briefing, FMS.

CAPTAIN: reviewed runway four.

FIRST OFFICER: flaps verify. two planned, two indicated.

CAPTAIN: two planned, two indicated.

FIRST OFFICER: um. takeoff data verify… one forty, one forty five, one forty nine, TOGA.

CAPTAIN: one forty, one forty five, one forty nine, TOGA.

FIRST OFFICER: the uh weight verify, one fifty two point two.

CAPTAIN: one fifty two point two.

FIRST OFFICER: flight controls verify checked.

CAPTAIN: check.

FIRST OFFICER: stab and trim verify, thirty one point one percent…and zero.

CAPTAIN: thirty one point one percent, zero.

FIRST OFFICER: the uh…. engine anti-ice.

CAPTAIN: is off.

FIRST OFFICER: ECAM verify takeoff, no blue, status checked.

CAPTAIN: takeoff, no blue, status checked.

FIRST OFFICER ON PA: ladies and gentlemen at this time we’re number one for takeoff, flight attendants please be seated.

FIRST OFFICER: takeoff min fuel quantity verify. nineteen thousand pounds required we got twenty one point eight on board.

CAPTAIN: nineteen thousand pounds required, twenty one eight on board.

FIRST OFFICER: flight attendants notified, engine mode is normal, the taxi checklist is complete sir.

(This is also how it works when assembling a nuclear warhead, but I can’t tell you that.)

This is also very effective for troubleshooting. For example, I was working with a team in a food processing plant. The obstacle being addressed was the long (and variable) time required to change over a high-speed labeling machine and get it “dialed in” and running at full speed without stops and jams.

Some operators were much better at this than others. We worked to capture an effective process of returning the machine’s settings to a known starting point, then systematically adjusting it for the specific bottle, label, etc. It worked when they were able to slow down enough to use it. That was an instance of “Slow is smooth; smooth is fast.”

The act of reading out load, performing the action, and verbally confirming is very effective when it is actually done that way. Even so, people who are very familiar with the procedure will often take shortcuts. They don’t “need” the checklist… until they do.

Still, you have a sequence of operations, and it is critical that they are all performed, in a specific order, in a specific way.

What works?
I’d say look around.
If you are reading this, you likely have been at least dabbling, and hopefully trying to apply “lean” stuff for a while.

What is a basic shadow board? It is a “checklist” of the tools to confirm they are all there – and a lot faster because missing items can be spotted at a glance. At a more advanced level, companies move away from shadow boards and to having the visual controls outlining what should be where to perform the work.

If you kit parts, you can set them out in a sequence – a “checklist” that cues the team member what order they should be installed.

I could continue to cite examples, but here’s the point.

When things are being left out, there is a high temptation to say “Let’s make a checklist” and sometimes make it worse by saying “…and we’ll have the worker sign it off for accountability.” That is more often than not simply a “feel good” solution. You feel like you have done something, and I’ve even heard “Well, it’s better than nothing.” I’m not sure it IS better than nothing – at least not in very specific conditions.

Instead, you need to study the actual work. Don’t try to ask questions, just stand and watch for a while. (Explain what you are doing to the team member first, otherwise this is creepy. “Hi – I’m just trying to understand some of the things that might get in your way. Do you mind if I just watch for a while without bothering you?”)

What cues the team member which step to perform next? Does he have to know it from memory? Or is there something built into the way the workplace is organized?

Does he end up going back and doing things he forgot?
Does he set out parts and tools in order on his own so he doesn’t forget?
Does he get interrupted, by anyone or anything, that takes him out of his mental zone?
(I go through airport TSA security checkpoints at least twice a week. I have a routine. When the TSA agent tries to “help” by talking to me, my routine gets broken, and that is when I forget stuff.)

If you are coaching someone, it helps if you go there with them, help the see the details by spotting these things and “asking” about them; then taking them to another area and challenging them to see as many of these issues as they can. See who can spot more of them.

What you are seeing are obstacles that impact the team member’s ability to do quality work.

Checklists don’t help remove those obstacles.

___________________

*The checklist transcript here is a cleaned up version of the Cockpit Voice Recorder transcript from Cactus 1549, the US Airways A320 that successfully landed in the Hudson River after multiple bird strikes knocked out both engines. I used it here because it is authentic, and the accident was one where everything went right and no one was seriously injured.

August 27, 2013January 9, 2019

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.

August 26, 2013January 9, 2019

Applying 5S to Processes

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.

August 19, 2013July 22, 2021

Fast Transients

Warning: Arcane esoteria follows.

A while back, Steve Spear put on a webinar about problem solving.

A key theme in the early part of Spear’s presentation was about a company that realized a need to be able to cope with ever accelerating changes. My notes captured this as:

We no longer do high volume manufacturing..

We do high volume engineering.

The design process is on a ramp-up.

In other words, in the context of this product development cycle, they needed to shift their thinking. They are mass-producing designs, not products. They need to be able to not only get the designs out, but get those designs into production and to the market with faster and faster transitions from one product to the next.

This meant that they were never in a steady state. Rather, the normal state was transition.

Everything in our world is accelerating. Our organizations must become very quick at adopting to new products, new technology, and process changes as a matter of routine.

We are living in a world where it isn’t so much what we know that gives us an edge, but how fast we can figure out the meaning of what is new.

This idea of faster and faster transients is not new to me, and I wanted to share some thoughts and background from a previous line of work that is technically out of the realm of “lean.”

Transient back in time: Korea: MiG Alley – 1952

Flying a MiG-15 in the Korean War was a very dangerous business indeed. The front line U.S. fighter was the F-86, and they were shooting down MiG-15s in a 10:1 ratio.

But that statistic beguiled analysis. By nearly all objective measures, the MiG-15 has a decisive advantage in a dogfight. It was lighter and more nimble. It could fly faster, out climb, out gun, and out-turn an F-86.

Fighter pilots being what they are, the original assessment was better piloting skills. And, overall, that was likely true. U.S. pilots, at least the more senior ones, were combat veterans from WWII. But many MiG pilots were combat veterans as well – especially the Russian ones.

No, while piloting skill could account for some of the difference, the mystery remained.

John R. Boyd

John Boyd (1927-1997) was a fighter pilot with no aerial victories. Yet he is acknowledged as one of the greatest fighter pilots in history. His contributions to the theory of aerial warfare are the anchor for training every fighter pilot in the world today. His theories are used to evaluate every fighter aircraft design.

As he was developing his breakthrough Energy-Maneuverability Theory, the MiG-15 / F-86 victory ratio did not fit his equations. In other words, he was faced with observation that did not fit his theory.

What was the advantage held by the F-86 that made it so formidable?

Though the MiG is physically smaller, the two aircraft are actually very similar looking. But there are some crucial differences in the design.

The F-86 has a large bubble canopy. Pilot visibility is unobstructed, superb. The MiG-15’s canopy is more conventional. It has frames, is smaller, and does not extend as low as its F-86 counterpart. This translates to the F-86 pilot being able to see more, see better. He is less likely to miss a spec that is behind a canopy frame. He can see better beneath him, and to his rear. Thus, he can begin to set up his next move just a little sooner than his opponent in a MiG-15.

The F-86 has hydraulically boosted controls. The F-86 pilot does not have to use his muscle power against the aerodynamic forces on the control surfaces. He can effortlessly move the stick, and the elevators and ailerons respond.

The MiG-15, on the other hand, requires muscle power. It is physically harder to move the controls, and the pilot must continuously fight, and overcome, the air pressures on the control surfaces.

Thus, the F-86 pilot can transition from one maneuver to another with less effort.

An aerial dogfight is not a steady state affair. The dynamics are continuously changing as each combatant tries to gain an advantage.

With these seeming small advantages, the F-86 pilot could gain situational awareness a touch more quickly, and change his maneuver a touch more quickly than his North Korean counterpart.

Even if the MiG could turn inside the F-86, this is a steady-state advantage. It only holds while both planes are in a constant turn. The F-86 pilot, though, could change directions more quickly and easily than his opponent.

As the maneuvers progressed, the MiG pilot would be lagging further and further behind the developing situation. Eventually he would be countering the last maneuver of the F-86, while the F-86 is already doing something else.

In other words, the F-86 pilot could gain the initiative by executing fast transients – changes in the tactical situation that forced his opponent to respond; or he could respond more quickly than his opponent could change things up.

The gun camera films showed that often the MiG pilots would either use their superior speed to break off the engagement (which leaves the F-86s in local control); or if the situation was hopeless, sometimes would bail out before the F-86 even fired his guns. He was defeated psychologically before physically.

From this analysis, Boyd developed a model of situational awareness, analysis and response that is known today as the OODA loop.

Observe – the process of physically sensing the outside world.
Orient – interpreting what was observed, and forming a picture of the situation. This process engages in some hypothesis testing as well – checking what is actually happening against what should be happening if the conclusion is correct.
Decide – Based on the situational awareness, decide the next action to take to gain advantage.
Act – Carry out the action.

Act carries with it a prediction. “If I carry out this action, this is what I anticipate will happen next.”

Act is the only thing which physically affects the outside world.

As the action is carried out, Observation is made to determine the actual impact, maintain situational awareness, and adjust accordingly.

Orient is an interpretation process. It carries all of the biases and assumptions that are inherent in human nature. There is a heavy bias toward seeing what is believed vs. seeing what is. This is the weakest point in the process, and the point where deception exploits the opponent by presenting something they expect or want to see.

After developing this theory for aerial combat, Boyd went on to develop it into a general theory. He was a student of military strategy, some have likened him to a modern Sun Tzu.

Boyd studied other cases in history where one side or the other had a clear advantage, and asked “What do these things have in common?”

He took the specific instance of aerial combat in the Korean War, searched seemingly unrelated experiences, and teased out a common pattern: The ability to execute fast transients – to change up the situation more quickly than the opponent can get a handle on what is happening; and to respond to changes quickly and routinely – gives a decisive edge. Modern maneuver warfare is built around Boyd’s theories.

According to Boyd, defeat was more about the opponent becoming so confused and disoriented that they became totally demoralized and lost command cohesion. They were no longer functioning as a team.

A poorly led army has a very rigid and centralized command structure. There is a detailed plan, every unit has specific instructions they are to carry out. Though this approach is appealing, it only works until first contact is made.

In this high-control environment, any unit needing to deviate from the plan must report the situation upwards, and wait for a decision and instructions. This takes time. In this time, an opposing unit who can execute more quickly can quickly gain an advantage. Our (U.S.) military calls this “getting inside the enemy’s decision cycle.” It means changing things up faster than they can react.

In the mid 1970’s, Boyd developed a two day briefing titled “A Discourse on Winning and Losing” and presented it to packed rooms at the Pentagon.

Later on, Boyd became interested in the Toyota Production System as he saw this system as increasing the ability of a company to quickly respond to challenges – execute fast transients – through its central direction / local execution model.

Normandy, June 5, 1944

On the night of June 5/6 1944, thousands of paratroopers were dropped on the Normandy peninsula. The U.S. 82nd and 101st Airborne Divisions were scattered all over the countryside. Very few troopers ended up on their intended drop zones.

But each trooper knew the overall mission, and they got together with whoever they could find, and banded together into whatever units they could assemble. The ranking man took charge, and they set out to get things done. They didn’t (and couldn’t) call in and get permission to carry out the new mission. They knew what was supposed to be done, and found a way to do it.

This was not the first time this had happened. The experience in Sicily in 1943 was similar. In both cases, what is known today as “The Rule of LGOPs (Little Groups of Paratroopers)” comes into play:

After the demise of the best Airborne plan, a most terrifying effect occurs on the battlefield. This effect is known as the rule of the LGOPs. This is, in its purest form, small groups of pissed-off 19 year old American paratroopers. They are well-trained, armed to the teeth and lack serious adult supervision. They collectively remember the Commander’s intent as “March to the sound of the guns and kill anyone who is not dressed like you…” or something like that.

Even when things do not go horribly wrong, a key element of modern command and control is centralized direction and decentralized execution. This means that the higher level commander sets the direction, the objective for the operation. They establish boundaries, priorities, overall intent, and ensure that everyone knows what needs to get done.

As a sub-unit encounters an opportunity or a problem, they respond and report. But the reporting in this case is not to seek permission to do something, but rather, to report what initiative is being taken. The purpose is so the higher level headquarters can coordinate support from other units to deal with the developing situation. In this way, there is no need to tightly coordinate each individual unit, only to ensure that the right resources are being applied in the right place to exploit opportunities and deal with threats.

What makes this work is every sub-unit knows the situation, the mission, and the overall intent of the plan. Thus, even if the exact details don’t work, they can quickly devise, and execute, actions that further the overall goal. This allows them to maintain overall direction while quickly exploiting opportunities and dealing with emergent threats.

Birds

A large flock of birds in flight looks like a fine chorography of fluid motion. But, of course, there is no bird-in-charge coordinating everyone and saying “Turn left… now.”

In 1986, Craig Reynolds studied how this complex behavior emerged from groups of individual “agents” that, individually, show none of the complex characteristics of the flocking behavior. He developed a computer simulation called “Boids” that implemented three simple rules for each “boid” in the network.

Those rules defined how each “boid” responded to the other “boids” in its immediate neighborhood. Based on these simple rules, the complex, fluid, rapid response to changing external conditions emerges.

We see similar patterns throughout nature. Ant foraging behavior is based on simple rules for following pheromone trails. Indeed, there is nothing inherent in a neuron that suggests the complexity of the human brain.

A flock of birds, though, exhibits very complex, fluid behavior. They can collectively respond very quickly to changes of direction, threats and opportunities. In other words, the flock, as a whole, can transition quickly from one state to another.

What Does It All Mean?

Back in 1970, Alvin Toffler published a best selling book Future Shock. He (and his uncredited wife, Heidi) set out a premise that, as the pace of technology development accelerated, we would be faced with making ever quicker transitions from one base of understanding to another. In other words:

“The illiterate of the future will not be the person who cannot read. It will be the person who does not know how to learn.

Putting all of this into context, our success will become increasingly dependent on our ability to see emerging opportunities, necessities, problems, threats; assess them; understand what must be done; solve the underlying problems; implement, then do it all again… at ever accelerating rates.

The competitive advantage will come to the organizations that can organize around fast transitions from one structure to another, all within the context of a well aligned direction.

What I see is that our developing understanding of “lean” as a process for developing and coordinating fast cycles of learning is exactly what we are all needing to become.

But the classic model of “lean” is too static. It relies on a hand full of professional implementers working hard to install pre-defined systems that strive to copy the mechanics from the mid 1980’s. While these installations may pride themselves on speed, they routinely do not leave behind an organization that is capable of nimble adaption and transition in the face of emerging issues.

Regular readers (or those who choose to wade through the past posts) know I write a lot about “lean” being more about a culture shift than the mechanics.

That culture is one where ad-hoc groups can quickly come together under a common alignment and direction; work to a robust, simple set of pre-existing rules for local interaction; and fluidly adapt to changing situations.

Those teams might be putting together a production line that is only in existence for a few weeks or months before quickly transitioning to another. There won’t be time to wring out the bugs, it will have to come up operational and undergo rapid improvement throughout its existence- passing what was learned to the next iteration.

The innovations will come from the user community. Proprietary ideas may be too slow. Rather, those who can quickly exploit public ideas, then grab the next one once the fast-followers catch up will be the organizations that stay ahead.

It is going to be about fast transients.

What we have to get very good at executing is learning and discovery.

How Do We Learn to Learn?

Saying “you have to do something” is the way of too many consultants and authors. The real question is “How do you do it?”

As I continue to strive to teach the principles in Toyota Kata in diverse organizations, I am building a model of how the organization actually functions.

If there is a common structure and framework that aligns how people think and interact with one another about problems, I see an analogy to the structural rules that govern swarms, like flocks of birds. (Kanban follows the same pattern, by the way, but that is a different topic.)

Not having to take the time to develop problem solving skills and norms would allow teams to come together and quickly get to work. Having good alignment on the direction and challenge up front would prevent a lot of rototilling that many teams go through when they try to tackle a problem they haven’t defined first.

“What are we trying to achieve, and how will we know? followed by “Where are we now? and “How do we know?” are questions that are rarely asked in many organizations. And when they are asked, my experience is the questions are regarded as a waste of time, because “everybody knows” or “it’s obvious” – except that they don’t and it isn’t.

But to answer the question in the header – “How do we learn to learn?” the answer is the same as for “How do I get to Carnegie Hall?” Practice.

Practice means you likely won’t be very good at it at first, and the results may be slow in coming. You will have to work on simpler systems at first, because they are easier to improve. It will feel like you aren’t tackling “real problems” – but in reality, you will see issues that have been adding friction to your systems for years.

Practice means you don’t try to play like Mozart before you can play notes without thinking about where your fingers are going.

The good news is that if you decide to actually take on the struggle and do the work, you will develop a basic proficiency pretty quickly. On the other hand, if you are fighting the utter necessity to learn, then you will never progress beyond going through the mechanics.

References:

John Boyd, Conceptual Spiral, and the meaning of life

August 18, 2013January 9, 2019

The Struggle

In The Leader’s Journey, I highlighted the struggle with escalating challenges as a core driver of growth in both our fictional heroes and real-life developing leaders.

This week I was essentially doing 2nd level coaching with a client I have been working with for quite a while. One of the things we did was have a brief session where we reviewed and reflected the ideal state of a coaching / problem solving culture (thanks in large part to Gerd Aulinger and Mike Rother). We reviewed the principles of what a coach and the coaching chain is striving to achieve, and the mechanics of doing it.

Combining that review with the shop-floor 2nd level coaching, a couple of my participants commented on how much better they “got” what they were trying to do. They started to move from rote to the higher-level understanding.

I am still digesting why this week had this kind of breakthrough when we have been working on the same key things for months. Nothing we went over was new information. What was different this time around?

My thought right now is that they have been in the struggle trying to understand this stuff, and finally reached the point where the additional theory snapped things into place. I told them “if you hadn’t been struggling with this, you wouldn’t have had the insights you got this week.”

I really think that is the case. We can give people all of the answers. But I am realizing if they haven’t, first, been struggling to find those answers on their own – if they haven’t been trying hard to figure it out – then the additional information would have far less (or little) impact. It is only after they have challenged themselves that the externally supplied insights have any meaning or context.

At least that is where I am right now. Time for a couple of additional experiments.