Competence and Clarity: Toyota Kata at Sea

A friend, and reader, Craig sent a really interesting email:

As I was practicing the coaching Kata with one of the First Mates on the factory trawler, whenever an issue arose (usually with the leader blaming an employee) he began asking factory and engineering leadership “what needed to be communicated?” or “what needed to be taught?” He found it encompassed every problem on the vessel and I loved that he made it his own and communicated in manner to which lifetime fishermen could relate.

What I found really cool about this is how it is exactly the same conclusion reached by David Marquet, both in the sketchcast video I posted earlier, and the titles of two chapters in his book. The reasons leaders feel they must withhold authority, remain “in control” ultimately come down to competence – what must people be taught, or clarity – what have we failed to adequately communicate. Maybe it’s being at sea.

In other words, if people know whGiveControl.pngat to do (clarity), and know how to do it (competence), then leaders generally have no issues trusting that the right people will do the right things the right way.

The Improvement Kata  is a great structure for creating and carrying out development plans for leaders (or future leaders) in your organization.

The Coaching Kata is a great way to structure your next conversation to (1) ensure clarity of intent: Does their target condition align with the direction and challenge? and (2) develop their competence, both in improving / problem solving, but also in their understanding of the domain of work at hand.

 

 

 

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:

  1. Find a change agent (how about you?).
  2. Find a sensei (a teacher whose learning curve you can borrow)
  3. Seize (or create) a crisis to motivate action across your firm.
  4. Map the entire value stream for all of your product families.
  5. 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:

image

 

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:

image

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.

Steve Spear on Creative Experimentation

On Monday MIT hosted a webinar with Steven Spear on the topic of “Creative Experimentation.”

A key theme woven throughout Spear’s work is the world today is orders of magnitude more complex than it was even 10 or 15 years ago. Where, in the past, it was feasible for a single person or small group to oversee every aspect of a system, today that simply isn’t possible except in trivial cases. Where, in 1965 it was possible for one person to understand every detail of how an automobile worked, today it is not.

My interpretation goes something like this:

Systems are composed of nodes, each acting on inputs and triggering outputs. In the past, most systems were largely linear. The output of upstream nodes was the input of those immediately downstream. You can see this in the Ford Mustang example that Spear discusses in the webinar.

Today nodes are far more interconnected. Cause and effect is not clear. There are feed-back and feed-forward connections and loop-backs. Interactions between processes impact the results as much as the processes themselves.

Traditional management still tries to manage what is inside the nodes. Performance, and problems, come from the interconnections between nodes more than from within them.

The other key point is that traditional management seeks to first define, then develop a system with the goal of eventually reaching a steady state. Today, though, the steady state simply does not exist.

Product development cycles are quickening. Before one product is stable, the next one is launched. There is no plateau anymore in most industries.

From my notes – “The right answer is not the answer for very long. It changes continuously.”

Therefore, it is vital that organizations be able to handle rapid shifts quickly.

With that, here is the recorded webinar.

(Edit: The original flies have been deleted from the MIT server.)

A couple of things struck me as I participated in this.

Acknowledging that Spear has a bias here (as do I), the fact that Toyota’s inherent structure and management system is set up to deal with the world this way is probably one of the greatest advantages ever created by happenstance.

I say that because I don’t believe Toyota ever set out to design a system to manage complexity. It just emerged from necessity.

We have an advantage of being able to study it and try to grasp how it works, but we won’t be able to replicate it by decomposing its pieces and putting it back together.

Like all complex systems, this one works because of the connections, and those connections are ever changing and adapting. You can’t take a snapshot and say “this is it” any more than you can create a static neural net and say you have a brain.

Local Capability

One thing that emerges as critical is developing a local capability for this creative experimentation.

I think, what Spear calls “creative experimentation” is not that different from what Rother calls the “improvement kata.” Rother brings more structure to the process, but they are describing essentially the same thing.

Why is local capability critical? Processes today are too complex to have a single point of influence. One small team cannot see the entire picture. Neither can that small team go from node to node and fix everything. (This is the model that is used in operations that have dedicated staff improvement specialists, and this is why improvements plateau.)

The only way to respond as quickly as change is happening is to have the response system embedded throughout the network.

How do you develop local capability? That is the crux of the problem in most organizations. I was in an online coaching session on Tuesday discussing a similar problem. But, in reality, you develop the capability the way you develop any skill: practice. And this brings us back to the key point in Kata.

Practice goes no good unless you are striving against an ideal standard. It is, therefore, crucial to have a standardized problem solving approach that people are trying to master.

To be clear, after they have mastered it, they earn a license to push the boundaries a bit. But I am referring to true mastery here, not simple proficiency. My advice is  to focus on establishing the standard. That is difficult enough.

An Example: Decoding Mary – Find the Bright Spots

Spear’s story of “Decoding Mary” where the re-admission rate of patients to a hospital directly correlated with the particular nurse handled their transfer reminded me of Heath & Heath’s stories from Switch. One of the nine levers for change that they cite is “find the bright spots.”

In this case the creative experimentation was the process of trying to figure out exactly what Mary did differently so it could be codified and replicated for a more consistent result independent of who did it.

The key, in both of these cases, is to find success and study it, trying to capture what is different – and capture it in a way that can be easily replicated. That is exactly what happened here.

A lot of organizations do this backwards. They study what (or who) is not performing to determine what is wrong.

Sometimes it is far easier to try to extract the essence what works. Where are your bright spots for superb quality? Does one shift, or one crew, perform better than the others? Do you even know? It took some real digging to reveal that “Mary” was even the correlating factor here.

Continuous Improvement Means Continuous Change

Since “continuous improvement” really means “continuously improving the capability of your people,” now perhaps we have “to do what.” I have said (and still say) that the “what” is problem solving.

What you get for that, though, is a deep capability to deal with accelerating change at an accelerating rate without losing your orientation or balance.

It is the means to allow the pieces of the organization to continue to operate in harmony while everything is changing. That brings us back to another dilemma: What is the ROI on learning to become very, very good? You don’t know what the future is going to throw at you, only that you need the capability to deal with it at an ever quicker pace.

But none of this works unless you make a concerted effort to get good at it.

Here is the original link to the MIT page with the video, and a download link for PDFs of the slides:

http://sdm.mit.edu/news/news_articles/webinar_010912/webinar-spear-complex-operating-systems.html

Mike Rother: Time to Retire the Wedge

Note – this post was written pretty much simultaneously with a post on the lean.org forum.

Mike Rother has put up a compelling presentation that highlights a long-standing misunderstanding about the purpose of “standards.”

[slideshare id=9312458&doc=retirethepdcawedge-091711-mr-110918191213-phpapp01]

Some time ago, a (well-meaning) author or consultant constructed a graphic that shows the PDCA wheel rolling up the incline of improvement. There is a wedge labeled “Standards” shoved as a chock block under the wheel to keep it from rolling back. That graphic has been copied many times over the years, and shows up in nearly every presentation about PDCA or standard work.

The implication – at least as interpreted by most – is that a process is changed for the better, a new standard is created, and people are expected to follow the standard to “hold the gains” while they work on rolling the PDCA wheel up to the next level on the ramp.

Slide 6 (taken from the book Toyota Kata) shows the underlying assumptions that are implied by this approach, especially when it doesn’t work.

There are some interesting assumptions embedded in the “wedge thinking.”

The first one is that “the standard can be ‘held’ by the people doing the work.

That, in turn, means that if when things start to deteriorate, the workers and first line leaders are somehow responsible for the “slippage” or “not supporting the changes.”

With this attitude, we hear things like “Our workers aren’t disciplined enough” or “How do I make them follow the standard?” The logical countermeasures are those associated with compliance – audits focused on compliance, and sometimes even escalating punitive actions.

Back in my early days, I had a shop floor team member call us on it quite well: “How can you expect us to hold some kind of standard work if the parts don’t fit?” (or aren’t here, or the tools don’t work, or jigs are misaligned, or the machine isn’t running right, or someone is absent, or we are being told to hurry and just get stuff out the door?)

This is the approach of control. The standard is fixed until we decide to change it.

Taiichi Ohno didn’t teach it this way.

Neither did Deming or Juran. Neither did Goldratt. Nor does Six Sigma, TQM, TPM.

Indeed, if we want creativity to be focused on improvements, we have to look up the incline, not back.

We are putting “standards” on the wrong side of the wheel. Rother’s presentation gets it right – the “standards” are the target – what we are striving to achieve.

The purpose of standards is to compare what we actually do against what we wanted to do so we know when they are different and so we have some idea what stopped us from getting there.

Then we have to swarm the problem, and remove the barrier. Try it again, and learn what stops us the next time.

The old model shows “standards” as a countermeasure to prevent backsliding, when in reality, standards are a test to see if our true countermeasures are working.

I believe this model of “standards” as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what “continuous improvement” really means.

It is time to actively refute the model.

If you own your corporate training materials, find that slide (it is in there somewhere) and change it.

If you see this model in a presentation, challenge it. Ask what should happen if something gets in the way of meeting this “standard.”

“What, exactly do you expect the team member to do?”  That sparks an interesting conversation which reveals quite a bit.

How Do You Deal With Marshmallows?

Yesterday, Kris left great comment with a compelling link to a TED presentation by Tom Wujec, a fellow at Autodesk.

 

Back in June, I commented on Steve Spear’s article “Why C-Level Executives Don’t Engage in Lean Initiatives.” In that commentary, Spear contends that business leaders are simply not taught the skills and mindset that drives continuous improvement in an organization. They are taught to decide rather than how to experiment and learn. Indeed, they are taught to analyze and minimize risk to arrive at the one best solution.

Tom Wujec observes exactly the same thing. As various groups are trying to build the tallest structure to support their marshmallow, they consistently get different results:

So there are a number of people who have a lot more “uh-oh” moments than others, and among the worst are recent graduates of business school.

[…]

And of course there are teams that have a lot more “ta-da” structures, and, among the best, are recent graduates of kindergarten.[…] And it’s pretty amazing.

[…] not only do they produce the tallest structures,but they’re the most interesting structures of them all.

What is really interesting (to me) are the skills and mindsets that are behind each of these groups’ performance.

First, the architects and engineers. Of course they build the tallest structures. That is their profession. They know how to do this, they have done it many thousands of times in their careers. They have practiced. Their success is not because they are discovering anything, rather, they are applying what they already know.

In your kaizen efforts, if you already know the solution, then just implement it! You are an architect or engineer.

BUT in more cases than we care to admit, we actually do not know the solution. We only know our opinion about what the solution should be. So, eliminating the architects and engineers – the people who already know the solution – we are left with populations of people who do not know the solution to the problem already. This means they can’t just decide and execute, they have to figure out the solution.

But decide and execute is what they are trained to do. So the CEOs and business school graduates take a single iteration. They make a plan, execute it, and fully expect it to work. They actually test the design as the last step, just as the deadline runs out.

The little kids, though, don’t do that.

First, they keep their eye on the target objective from the very beginning.

Think about the difference between these two problem statements:

  • Build the tallest tower you can, and put a marshmallow on top.

and

  • Support the marshmallow as far off the table as you can.

In the first statement, you start with the tower – as the adults do. They are focused on the solution, the countermeasure.

But the kids start with the marshmallow. The objective is to hold the marshmallow off the table. So get it off the table as quick as you can, and try to hold it up there. See the difference?

More importantly, though, is that the kids know they do not know what the answer is. So they try something fast. And fail. And try something else. And fail. Or maybe they don’t fail… then they try something better, moving from a working solution and trying to improve it. And step by step they learn how to design a tower that will solve the problem.

Why? Simply because, at that age, we adults have not yet taught the kids that they are supposed to know, and that they should be ashamed if they do not. Kids learn that later.

Where the adults are focused on finding the right answer, the kids are focused on holding up a marshmallow.

Where the adults are trying to show how smart they are, the kids are working hard to learn something they do not know.

Third – look what happened when Wujac raised the stakes and attached a “big bonus” to winning?

The success rate went to zero. Why? He introduced intramural competition and people were now trying to build the best tower in one try rather than one which simply solved the problem.

Now – in the end, who has advanced their learning the most?

The teams that make one big attempt that either works, or doesn’t work?

Or the team that makes a dozen attempts that work, or don’t work?

When we set up kaizen events, how do we organize them?

One big attempt, or dozens of small ones?

Which one is more conducive to learning? Answer: Which one has more opportunities for failure?

Keep your eye on the marshmallow  – your target objective.

Last thought… If you think you know, you likely don’t. Learning comes from consciously applied ignorance.


Edited 2 August 2016 to fix dead link. Thanks Craig.

“Opportunities” vs “Problems”

Over the decades, I have observed that it is quite common for organizational leaders to try to use the word “opportunity” when talking about a problem.

I can understand the desire to do this – we typically think of “problems” as something to do with people.

But I find the emphamistic language… problematic.

 

 

Mr. Opportunity

 

There is a Honda marketing campaign in the USA that features a cartoon character named “Mr. Opportunity.” His tag-line is “I’m Mr. Opportunity, and I’m knocking.” The opportunity is an invitation to take advantage of discounted prices for Honda cars.

Words mean things.

An opportunity is something that I may, or may not, decide to pursue.

But in lean thinking, no problem can go unaddressed.

Rather than a friendly cartoon character knocking on your door, a problem has kicked your door in and is standing in your living room. It must be dealt with, and dealt with quickly.

It has to be contained, pushed back, and finally resolved to keep it from getting back in.

IF the process for doing these things is carried out correctly, there are opportunities for the organization to learn along the way. But in the vast majority of cases, the only way those opportunites get exploited is if the leaders insist on hearing what was learned. So even those “opportunities” shift to imperatives.

Friendly euphemism that soften the urgency do not help us. If we are to have a true problem solving culture, we have to be willing to call things what they actually are.

Knowing vs. Knowing How To Learn

On the way to the airport a few days ago a couple of thoughts occurred to me that I wanted to toss out there and see how you all responded. This is one of them.

What separates an expert from a master? Actually I need to ask in more prejudicial terms. Some people who are truly experts are also “stuck” in that they try to fit new things they encounter in to an analogy within their (vast) experience. When they find it, they apply the analogy and often come up with a pretty good solution. But they can have problems relating when the encounter something that doesn’t compare with anything they have seen before.

As an example, the classic elements of standard work are described as

  • a repeating work sequence
  • balanced to a takt time
  • standard in-process stock

And, indeed, these things are the elements of standard work when there is a repeating work sequence and when there is a takt time.

Some experts at applying standard work, however, have a hard time seeing application outside of this scope. They know work needs to be standardized, but they continue to try to shoe horn what they see into this model.

Another, more general, lean manufacturing model is the notion that this is about manufacturing, or that it “doesn’t apply” to true job-shops or non-repetitive environments. But this, too, is just a limitation of an “analogy” model. It is the analogy that breaks down, not the concept.

In the analogy model, we try to educate by providing more analogies, more examples of different applications in order to expand the base for comparison.

And, to be honest, this works to a degree. Some people get it, others simply don’t want to expand their analogy base. They are the ones who say “This (model) does not apply to (whatever is their current paradigm)     .

Indeed, people who are tightly holding the view that kaizen events led by trained specialists are the only way to drive improvement can easily be blind to the possibility that an organization that is successfully running daily kaizen is operating at a fundamentally different level. I have seen that as well. And I have seen the same excuses made to explain away the difference in performance. “It isn’t different;”  “it doesn’t scale;”  “it isn’t repeatable.” All of this is defending a mental model – a paradigm – an analogy.

On the other hand, I want to contend here that a true master is not one who has mastered a process, but rather one who has mastered the process of learning about a process.

At an organizational level, true continuous improvement starts to engage when “process” and “standard” become baselines to gain higher understanding. Rather than trying to audit and enforce compliance, they are genuinely curious about the reason why a process is not being carried out as it should. This thinking requires far more work because it is empowering – it simply does not allow playing victim to “they won’t.” It puts the spotlight right back on what can (or should) be learned from the experience.

Put another way, the “expert” knows.

The “master” knows that there is much to learn.

Grassroots Innovation: The 3rd Way

Grassroots Innovation: The 3rd Way.

Greg captures a concept in 183 words that entire books have utterly failed to explain.

When we are trying to solve a problem, there are always people involved. And people have positions, feelings, and are always emotionally tied to this-or-that outcome.

It is critically important to find “The 3rd Way” when working on a solution.

There is a great example of what Greg describes as “flight” starting in page 73 of John Shook’s book “Managing to Learn.”

Shook summarizes “The 3rd Way”:

. . . making good decisions required everyone’s complete commitment to dealing with harsh reality.

This produced yet another counter-intuitive aspect of A3 management: respect through conflict.

Organizations that confuse “nice-nice” with teamwork end up paralyzed and frozen in place the moment there is disagreement. No further intellectual growth appears, and they had better hope they are far enough ahead that their competitors won’t catch on.

I have already used more words talking about Greg’s post than he spent making it.

Is This a Problem – Part 2

Last week I posted a story of a failed freezer, ruined food, and a customer support experience that could be summed up as “That’s how we do it.” I invited comments and asked:

“Is this a problem?”

And when I say “problem” I mean, is this a “problem” from the standpoint of the company’s internal process?

There are some interesting comments, some about the internal culture of the company, others about the support process itself.

But I promised to offer my thoughts, so here they are.

The key question is “What did they intend to happen?” While we can speculate, unless we have the process documentation or are otherwise privy to that internal information, we really don’t know what they intended in this case.

Let’s assume, for the sake of argument, that Frank’s experience was exactly as the company intended it to be. Then, from the point of view of their internal process, there is no problem.

“Wait a minute!” I can hear, “Nobody wants  a customer to never buy the product again.”

And here is my point. We don’t know. This company may be perfectly willing to accept that consequence, i.e. “fire the customer” to preserve their warranty cost structure. They certainly would not be the first. Whether that is good business or not is a totally separate issue. The question is “Did they produce this result on purpose, as a logical, foreseeable outcome of the process as they designed it?.” If the answer is “Yes, they did” (and only they can know), then there is no problem. It might be bad business, but the process is working just fine. (I acknowledge that “bad business practices” can result in unintended results – like bankruptcy. But my point is the results are the outcome of a process, and the process is the result of a decision, even if that decision was to “not care.”)

The key point here is that only after there is clarity of what should happen, can the process itself even be addressed. Until the intended result is clear, then there is no way to see if the process works or not.

Was there a problem here? I don’t know. But this is what I would like people to take away from this little story.

Whenever something in your company seems “not right” ask this really powerful clarifying question:

“Did (or would) we do this on purpose?
If the answer is anything other than an unqualified yes then it is likely you have a problem.

Here is a tougher position: If something was unpleasant for your customer, and you don’t intend to fix it, then embrace the truth that you did do it on purpose. Take responsibility for your decisions, look in the mirror, and say “We meant to do it exactly that way, and will do it the same way next time.” If you can’t stomach that, then go back the the first question.

Here is an extra credit question for this little case study in customer support.
What, exactly, did the customer want here?

Amazon.com Gets It

Not many people know that Amazon.com is one of the “places to see” if you are looking for companies practicing the TPS. The fact that their sales and profits are hitting records as most others are scratching and clawing to stay in business is telling.

This recent post by Kevin Kelleher on Gigacom really sums the whole thing up with one sentence quoted from Jeff Bezos’ letter to shareholders:

At a fulfillment center recently, one of our Kaizen experts asked me, “I’m in favor of a clean fulfillment center, but why are you cleaning? Why don’t you eliminate the source of dirt?” I felt like the Karate Kid.

If you have to keep cleaning up a mess, find out where the dirt is coming from.

But the philosophy goes deeper.

If an assembly Team Member is continuously spending time cleaning up threaded holes, go find out how the debris is getting in there (or find a way to keep it out). Go and see.

If you keep losing market share, find out why customers prefer your competitors products. (And don’t sit around a mahogany table talking about it, GO AND SEE.)

Other posts on the same site relate to eBay’s troubles trying to compete with Amazon. The difference, I think, is summed up in a quote from an Amazon executive related to me by someone who was a fly on the wall in one of their meetings:

“At an eBay sellers meeting last quarter, my counterpart was booed off the stage. That is not going to happen here.”

Kaizen is less about the tools than it is an obsessive curiousity about what the next problem is between you and perfection.