I believe this is a significant event for the lean community as a whole, as well as for the LEI.

As many of my regular readers know, I have maintained the view that the LEI had not kept up with the current state of knowledge about what makes “lean” work.

Back to Basics

An Open Letter to John Shook

When the LEI published Kaizen Express in 2009, I wrote a review that addressed this topic. The review had two parts. One part about the book itself, and the other about the context of the community’s knowledge at the time.

I think it is a great book, for 1991.

But this is 2009. So while Kaizen Express is a welcome refresher of the mechanics, those mechanics are, according to the current standing theory, built upon a foundation of something that Kaizen Express, and for that matter, the LEI has not, to date, addressed. What is missing, in my view, is how the tools and practices outlined in Kaizen Express and its predecessors actually drive daily continuous improvement that engages every team member in the process. [bolding added for emphasis here]

When Toyota Kata was published, I believe it closed that gap for the community at large. But I felt a bit of irony that while Mike Rother had co-authored the LEI’s flagship workbook Learning to See, Toyota Kata was not only outside the LEI’s community at the time, it was hardly acknowledged to exist.

The purpose of this post is to acknowledge that a significant step has been taken: For the first time in many years, the LEI is embracing material that they did not originally publish.

From my perspective, this looks like a turning point away from the path of irrelevance.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Toyota Kata at lean.org

The target condition at this point is simply to establish some degree of transparency of the current condition on a status board without having to resort to probing questions to elicit what is working, and what is not.

The observation was:

“We’ll know we are succeeding when we see a failure.”

In other words, “no problem is a big problem” but I think this says it just as well.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Failure as Success

I have a couple of teams working to develop pull systems through their respective work areas.

The conventional approach (I suppose) is a lot of PowerPoint about kanban, some exercises, developing a future state value stream map, then devising an implementation plan.

An alternative approach is to have a small group of experts design the system.

Most of the time this results in a fairly arduous process of wringing out the issues once the system goes live. If the team isn’t prepared for that, it is likely the system will come apart as people bypass it out of necessity to get the work done.

What I am watching this week is more organic.

First, we covered a few fundamentals about flow and pull signals in a simple demonstration of “build and push” vs. one-piece-flow with a visual limiter on work-in-process inventory. They saw the throughput, productivity, stability, visibility all increase while lead time dropped by an order of magnitude. That took about an hour.

The team then set up a tabletop simulation of their existing work flow, and exercised it a few times to confirm that it is a fair representation of the way things actually work today. In doing so, they gain more understanding of the current condition because they have to replicate it.

They then set out to make their far more complex real-world situation work more like what they saw in the demonstration. To help them get started, they were given some suggestions about a few things to try, and some basic principles and rules.

Some of that advice included restricting changes to a single factor at a time, and predicting what would happen, then trying it. If you find yourself speculating, or discussing alternative speculations, try it and see.

Two days into it, the teams have full-blown multi-loop kanban working, and are devising experiments to learn how the system responds to things like machines going down, unpredicted shifts in product mix, and other things they normally need to respond to.

They are exploring not only the mechanics and the rules, but the dynamics of the process in operation. They are learning what “normal” looks like in the face of abnormal conditions. They are testing the boundaries – where and when does it break, and what does “broken” look like vs. something that will recover on its own.

They are figuring out how to make it more robust, without making it cumbersome or too complicated.

They are gaining confidence and a deep understanding by iterating through ever more complex scenarios.

The people doing this are the ones who will be working IN the system in the future. We are seeing who emerges as thought leaders.

What they have right now – mid week – is a crystal clear view of their target condition, and they are very confident that they can make it work in their real world. Are there unknown issues? Sure. There always are. Translating this to the real world will involve more cycles of iteration. Only now they know exactly how to do those iterations because they have practiced dozens of times already.

This is actually less about kanban than it is about learning how to gain knowledge about something previously unknown.

It is pretty cool to watch, and a lot more fun (for everyone) than just implementing a process designed by someone else. Even the skeptics get drawn in when people are working hands-on to try to make something work.

Oh – and I’m really glad this process works because that saves me from having to know the answers.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Learning vs Teaching

One of the many good points that struck me was that you can’t rally around an ROI.

Yet companies try to do just that. They set something ROI or margin objectives, and wonder why everyone doesn’t pick them up and run with them.

Even companies that do issue a good challenge often come up wondering why the organization doesn’t align around it. Rother mentions one good reason: Nobody is there to coach them through meeting their part of the challenge.

A similar fallacy is trying to rally people around an abstract vision. I have experienced this a couple of times. A company tries to apply general education to people – lots of it – in the (vain) hope that once people “understand” then they will pick up the ball and run. But without consistent direction toward a limited objective that is easily articulated, people freeze up. “What do we work on?” There are too many choices.

Chip and Dan Heath discuss the importance of a rallying point in their book about culture change, Switch. They talk about “Pointing to the Destination” and “Scripting the Critical Moves.” When we talk about an aligning challenge, we are saying the same thing. Remember – in these initial stages you are trying to infuse a fundamental behavior and culture change. You can’t just tell people what it is and expect things to change tomorrow.

Classroom training may teach people the words, but it does little to accelerate the process of learning on the shop floor. That takes leadership.

More after the video:

One of the concepts that Rother discusses in Toyota Kata is the concept of “True North.” Spear also talks about it as striving toward the ideal process. Same thing, different words.

But at another level, when we are trying to shape a different management system, it is equally important for the leaders to have a “true north” for the ideal leadership process. I think this is different (or should be expressed differently) from the True North of the ideal value-adding process.

As I develop my own practice, I am honing in on those key elements of “leadership true north” and making it the cornerstone of my engagements. Mainly I try to describe specific behaviors and critical elements that need to be in place. This seems to play better than abstract concepts like “servant leadership” because it tells people what they need to do. (See “Script the Critical Moves.”)

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Leadership and Challenges

Having worked in the airline business, it’s really a matter of having employees that CARE (most due to their own pride, not by management) We many times had weather and mis-connected passengers to deal with. It only took a few minutes of extra time to send a message to the destination station and let them know what to expect or which passenger was going to be disappointed to not get their bag. Today’s situation is exacerbated by under-staffing, stressed employees, passengers with sometimes unrealistic expectations, checked bag fees, etc it’s ugly and very little relief in sight.

He brings up some really interesting points. In most of the airline industry, like most industry in general, “caring” is thought of as something the people have to do.

“The employees don’t care” or even “management doesn’t care” are pretty common statements.

Let’s turn it around.

How was the original process designed?

Continuing on the theme from the original post, I would speculate that most players in the airline industry see themselves as providing transportation to people and their stuff.

The process design is, logically, going to center on what things have to happen to get people and their stuff from their point of entry into the system through to their point of exit at baggage claim. (the fact that the trip doesn’t actually end at baggage claim is another topic – one which has been discussed by Jim Womack in Lean Thinking, among other places.)

In traditional thinking, improvements in that process will involve making those things happen cheaper, usually by doing less.

What if, though, we start with a different question:

“What experience do we want the customer to have?”

Describe, first and foremost, the things the customer has to do to get herself and her stuff from the point of departure to (sadly) baggage claim. (Bonus points if beyond, but let’s not stretch the fantasy too far.)

Even better, act it out. Simulate it. Try it on. Work out the kinks, from the customer’s perspective.

Next, design the interface between your customer and your process. What does the customer-touching part of your process have to look like to deliver that experience?

(I often wonder if airline executives ever see their own web reservation systems.)

Now, only when you know what the “on stage” part of your process looks like can you design the rest of it – the back stage parts that make it all happen.

Economics come into play at this last stage. This is where you have to get creative. If the solution is too expensive, work on the back-stage part to make it cleaner and more streamlined. The customer facing part of the process is the target condition. Your problem solving works to deliver that experience in continuously better ways.

What does this have to do with “caring?”

Remember, this is from the customer’s perspective. When we say “our employees care” do we not really mean “our customer’s feel cared-about?” Since we started with the customer’s experience, if that is what is desired, it was built into the process specification from the beginning.

Once there is a process that we predict will result in customer’s feeling that people care about them, then your market surveys make sense. You are not soliciting complaints about things to fix, you are validating (or refuting) your design assumptions. Every bit of customer feedback will be a learning experience.

Don’t forget Murphy.

In a complex business like airline travel, sometimes luggage doesn’t get to baggage claim at the same time as the customer. It happens. But this is the time to really apply the above process design. What do you want the customer to experience when things go wrong?

Ironically, in the customer satisfaction world, a spectacular and surprising recovery actually generates more loyalty than flawless delivery of service. This is the moment for your company to shine.

Whatever happens, though, make sure it is something you would do on purpose rather than relying on chance or a random team member’s disposition. Build “caring” into the process itself, and you will embed it into the culture.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

The Process of Caring

Where in Chapter 2 the authors were outlining the individual leader’s responsibility for self-development, now they are describing the environment and the process of supporting and focusing that drive.

Rather than just outline the chapter, I want to dig into some key elements of the context that Toyota creates for their leaders.

First is the expectation that leaders lead.

Leading vs. Delegating

Chapter 3 has a great story that exemplifies the key differences in management styles that I alluded to in the post about Chapter 2.

In that story, NUMMI has equipment reliability problems in the body shop. Mr. Ito, the President has instructed Convis to have each engineer prepare and present a one page report for every breakdown lasting over 30 minutes. The telling moment is Convis behavior in the presentations:

While Ito was critiquing the [A3] presentations and reports, Gary [Convis] simply stood to one side, marveling at Ito’s insight and amused at the struggles of the engineers’ efforts to learn this way of thinking.

This quote nails the core issue we have to deal with in any company that wants to succeed with lean production.

Convis was newly hired from the U.S. automobile industry, and was acting exactly as he was trained as a manager. He was acting as every manager in the USA is trained.

He has delegated the process of training the engineers to Ito, who he sees as the technical expert. Convis viewed his presence here as overseeing how well his engineers are responding to that training.

Ito, though, had other ideas.

After a few sessions, Ito asked Gary how he was coaching the engineers through the process before the presentations. Ito pointed out that there was still a lot of red on the reports, and if Gary had been teaching the engineers properly, there would be less red ink. […] problems with the reports were a reflection of Gary’s leadership, and he was more responsible for any failures than the engineers were.

Zing.

You can’t even cite “If the student hasn’t learned, the teacher hasn’t taught” here because the delegation paradigm was so strong that Convis didn’t realize he had responsibility for being the teacher.

Convis, of course, “got it” and began seeing the red ink as his failure, rather than the engineers’. The drive for self-development kicked in and worked. And of course, in the process of struggling to coach the problem solving process, he had to struggle to learn it well enough to do so.

Personally, I see the idea of delegating and then passively overseeing improvement and people development is a cancer that is difficult to excise from even the most well intentioned organization.

I have seen this with my own eyes – senior executives struggling with how to “implement lean.” What was their concern? What metrics they could use to gage everyone’s progress through reports to corporate headquarters. They simply saw no need to get personally involved in learning, much less going to see, and certainly not teaching, the messy details. Not surprisingly, that company still struggles with the concepts.

Of course it cascades down from there. The various sites’ leaders follow the example, and delegate to their professional staff people. The staff’s job? To come up with “the lean plan” and “drive improvement” while the leaders watch. At some point, someone in charge of the operation actually has to do something different, but that, it seems, is always the next level down.

I am not going to get into what stops leaders from stepping up to this responsibility or what do to about it because that would be a book in itself.

It doesn’t help that, with the revolving-door of leadership we often encounter, each new leader comes in with the old mindset. OK </rant> and back to the book.

The Technical Support

This expectation of leaders leading does not operate in a vacuum. Toyota processes are deliberately set up to remove any ambiguity about what the next challenge is by surfacing problems immediately

In the words of Lean Leadership, these problems are framed as challenges for leader development.

In a much earlier post, I objected to our western euphemism of “opportunity” when we meant “problem.” My objection was treating this “opportunity” as an something that could be taken on, or not.

A challenge, especially in the context of leader development, isn’t optional. A top level athlete grasps the meaning of a challenge. He is driven to take it on and push himself to meet it. He improves in the process. It isn’t about the record, per se, it is about what he must develop and pull from within himself to get there.

Just as the world-class athlete has a stopwatch on every lap, the assembly line is set up to verify the timing of every cycle. Any discrepancy is immediately apparent to both the team member and the leaders. If the work can’t be done, the line is stopped and things are made right. Then we figure out why. And everyone learns.

TPS […] creates a never-ending stream of opportunities for on-the-job development and increased challenges. Toyota sensei do not need to create artificial training situations […]. The daily process of producing cars generates all the development opportunities and challenges that are needed.

If your organization has trouble finding problems, it isn’t because they aren’t there. It is because your processes are blind to them. That is why “No problem is a big problem.”

The key is that when we talk about “implementing the tools of lean” we are doing nothing more than setting up the baseline process to present the challenges for leadership development. That’s it. It is the difference between playing a casual game and deciding to keep score.

You can’t improve without keeping score, to be sure. But keeping score alone doesn’t cause things to get better. If anything, it increases people’s frustration because they see they are coming up short, but don’t have the support or opportunity to do anything about it.

What happens then? They start seeing problems as “normal” and start blinding the system. They add padding to cycle times to “allow for variation.” They decouple processes and put in extra inventory. They start running two at a time, then four, and return to batching.

If a problem remains hidden below the surface long enough, it can stop being perceived as a problem and become part of normal operating procedure.

OK, so I’ve beaten that to death yet again. It is critical to structure the work so that we can see whether things are going as planned or not.

But it is just as critical to have the problem solving processes engaged immediately. If those processes don’t yet exist, you have no hope of your so-called improvements sustaining for long.

That’s not all. There is another standard that is just as critical – if not more: A standard for problem solving.

The A3

We just got done exploring how critical it is to have a process that is totally transparent. Why? So we can clearly see any difference between how it is and how it should be.

The purpose of the A3 is to provide that level of visual control to the problem solving process itself.

And yes, problem solving is a process. It follows standard work. It is perhaps the most critical thing to standardize. The only way to gain skill at something is to practice against a clear standard. It really helps to have a coach watching your every move and calling out small adjustments, things you need to pay more attention to the next time you do it (which should be immediately).

The A3 is the game film, the slow motion camera, the visual control of how problem solving is being done. It is not sufficient to find the solution. It is more important to develop a consistent approach to problem solving across the entire organization.

But outside of Toyota and a few companies that are starting to grasp what this is about, the A3 is, sadly, one of the more recent fads in the lean community.

An A3 isn’t something you tell someone else to do. It is a visual control, just like the moving line, that works only in the context of direct observation and participation by all parties involved. In the above story, Ito was setting an example, and expecting Convis to follow it. Once that started happening, Ito’s participation shifted from coaching the engineers to coaching Convis as he coached them.

Just as the tools of takt time, standard work, pull systems, etc. do not stand alone and “make you lean,” neither does filling out A3 forms. Even if you have “the tools” and a problem solving process, it doesn’t help if they are not intimately linked together.

All of these things are designed for 1:1 interaction. They are messy testaments to the fact that problem solving often loops back to previous steps as more is learned.

The Big Picture

This chapter provoked a lot of thought for me, and I have tried to share some of that. When / if you choose to read the book, I hope you have your own thoughts, and even share them here or in the forum (that could use some life right now).

Fundamentally, Chapter 3 is about the phenomenal support Toyota provides those leaders who have the self-motivation to learn.

• Every operation is structured to provide challenges and opportunities for them to develop their skills. There is no shortage of things that obviously need improving.
• Every leader is positioned to teach and mentor those who are willing to step up to the challenges that are there.
• The problem solving process itself is structured as standard work so that a prospective leader can practice against a standard and improve skill through repetition and coaching.

Aside from a couple of case studies and examples, this chapter is a bit of a synopsis of Toyota Kata. I continue to bring Kata into this discussion because there is obvious overlap in topics, and I see these two books complimenting each other. Kata gets into the nitty-gritty of how problem solving and coaching happens. Lean Leadership is providing a context and case examples of the entire ecosystem.

More to follow.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

The Structure Behind Leader Development

If anyone were to ask my advice here, it comes down to one word:

Don’t.

Two reasons.

First, we have overwhelming evidence that these incentives not only don’t work, but they actually make performance worse in the kinds of work you are asking these people to do.

The Overjustification Effect

Dan Pink on motivation

All of this is consistent with what Deming told us decades ago, yet we keep doing it.

The second reason is inconsistency and misalignment.

Having the continuous improvement staff operating to separate metrics disconnects their efforts from line management’s. They become responsible for improving the operation while the line management processes are… what?

The message to the shop floor team is pretty clear here. They can read an organization chart. Do what the boss says, then, if we have time, and if the improvement guys can make the case, then maybe listen to what they have to say.

If you must have management-by-KPI, then the performance measurement for continuous improvement must be exactly the same as the line manager being supported. Why?

The question I would ask is “Who is responsible for the performance of the organization?” If it isn’t the line leader, then why does that position exist?

It makes no sense whatsoever to have the lean implementer working to a different agenda.

Our management traditions of de-aggregating and delegating are not serving us well. We need to take a systems view and realize that everything is inter-related. Further, we need to grasp that B.F. Skinner’s (dubious) research on rewards-based-behavior simply does not apply to management. Never has. Wishing otherwise isn’t going to change it.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

‘Tis The Season for Management by Measurement

Every one of those branch points is a decision. It is a point where the team member must memorize decision criteria and the correct choice(s).

Each “If-Then” in the process flow potentially doubles the number of possible paths the process can take.

Each decision is an opportunity to make a mistake.

The more complex a process, the more time and experience the team member requires to master it.

Mental bandwidth is limited.

The more attention they must expend to do it right, the less they can devote to thinking about how it could be done better.

How complicated a world do you create for people trying to do the work?

The more “flexible” your human interface with the process, the more complicated it is for the person who has to use it.

Do they have to enter ad-hoc query criteria into computers to pull information they routinely need every day?

How many decision criteria are things that people “just know?”

How often does someone encounter a problem or new situation and get a verbal instruction from the supervisor on how to handle it? What happens then? Maybe a general announcement at the next team meeting, if you’re lucky?

Go down to your work area.

Watch how people interact with the routine work.

Each of those decision points is an opportunity to simplify your process flow and make life a little less stressful for all of you.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Decisions, Decisions

The idea that a company can focus on 25 key areas, or 125 key performance indicators (yes, I said 125 because I have seen it myself) is obviously ludicrous.

Of course a manager has a legitimate concern to ensure people don’t take their eyes off things that are important to focus on something else.

But the leader’s role here is to ensure there are processes and systems in place that anchor the routine things. Further, those processes and systems need to be designed to alert the appropriate people when something goes out of control, or past a boundary.

Without having any routines the manager has no choice but to make everything something to focus on.

Because there is no standard process, everything must be managed as an exception.

This stresses the organization because in reality they can only micro-manage a few things at a time. It is left up to the people to decide what isn’t going to get done. The bosses response at that point is going to be negative no matter what they accomplish. “Respect for people” does not play here.

Leader’s toughest job is deciding what we are not going to work on right now. It isn’t as tough as it seems because if a focus or challenge is selected well, it actually organizes the problem solving effort to pull just about everything else in behind it.

Let’s take an example from a previous post: On time delivery.

If we say “We are going to emphasize “on time delivery” as a theme or challenge this year, what kind of things might people end up working on?

• Having every operation start on time.
• Sources of delay.
• Quality issues (which cause delays)
• Safety issues (also cause delays)
• Visual controls and good response to problems (to get on top of problems quickly)
• Equipment reliability.
• Setting a good operational takt time.

The list goes on. But by having a decent challenge, the local area can focus on the things that are impacting their ability to deliver on time. It isn’t necessary to make a laundry list of everything that could cause a delay and measure it from the top of the organization. If you do, everyone’s energy is dissipated working on problems that they don’t necessarily have.

Of course this is all based on having a leadership process that gets down to the work area, grasps what people are actually working on, and coaches them through the process of aligning their efforts and solving the right problems in the right way.

Hmmmm… so does that mean that the #1 thing to focus on if you want consistent on-time delivery might be leadership development?

I guess I need to get back to the Liker and Convis book.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

The Tough Decision: What Not To Do

1. Has been covered before – we know all of this.
2. Needs to be covered again, because most people act as though we don’t know it.

Simply put, Liker and Convis (legitimately) feel the need, once again, to let us know the things which reliably fail when trying to build a sustaining culture of continuous improvement.

“So let’s train some Lean Six Sigma experts to grab the tools and start hacking away at the variability and waste that stretch out lead time; this will make us more successful, both for our customers and for our business. What could be simpler?”

What indeed.

I am, once again, reminded of a saying that “People will exhaust every easy thing that doesn’t work before they try something difficult that will.”

The authors cite some of the same things that we have heard before:

• Trying to determine ROI for each individual process step, or each individual improvement, doesn’t work.
• Trying to motivate the right behavior with metrics and rewards doesn’t work.
• Trying to copy the mechanics doesn’t work.
• Trying to benchmark, and copy, a “lean company” in your business doesn’t work.

Yet, even though we have been hearing these messages for at least a decade, actually longer, I continue to encounter managers who try to work this way.

The authors assert, and I agree, that this is the result of people trying to fit Toyota’s system into a traditionally taught management paradigm that is so strong people aren’t even aware that there is a paradigm, or can’t conceive there is anything else.

They are stuck inside their threshold of knowledge when the answer is beyond it.

This reminds me of the Edwin Abbot’s 1884 story of Flatland, a two-dimensional world populated by creatures who cannot conceive of “above” and “below” their planer existence.

Although his story is often read by students struggling to grasp models with four, five and more dimensions to them, it is really a story of social change and paradigms.

Our management systems are a “flatland” with Toyota’s system existing in a space that we have to work hard to grasp. We can see pieces of it where it touches ours, but like the creatures in Flatland who only see two dimensions of three dimensional objects, we only see the pieces of TPS that we can recognize.

Fed from: The Lean Thinker. Copyright © 2012, Mark Rosenthal

Once Again: What Doesn’t Work