Daily Management for Improvement

I’m digging through old archives again, and came across this graphic I put together around 2006 or so. It depicts more detailed version of “Organize, Standardize, Stabilize, Optimize” showing the continuous comparison between “what should be happening” and “what is actually happening.” It is the gap between these two that drives improvement forward.

Like the pocket card in the last post, this is built on a foundation established by the work of Steven Spear, especially his PhD dissertation that is summarized in Decoding the DNA of the Toyota Production System. By the way, if you are in the business of continuous improvement, reading (and understanding) this breakthrough work is critical for you.

Other than generally sharing this, my other reason for putting this up is that in the Toyota Kata community there has been discussion for about a decade about whether or not the right hand loop – pushing for stability – is an appropriate use of the Improvement Kata.

I think that is an unfortunate result of some very early conversations about the difference between “troubleshooting” and “improving” a process. We get into semantic arguments about “problem solving” as somehow different from “root cause analysis” and how the Improvement Kata is somehow distinct, again, from those activities.

This makes no sense to me for a couple of reasons.

Scientific Thinking is the Foundation

Toyota Kata is not a problem solving tool. It is a teaching method for teaching scientific thinking, and it is a teaching method for learning to teach scientific thinking. In the books and most literature, it uses organizational processes as working examples for the “starter kata,” but exactly the same thinking structure works for such diverse things as working through quality issues, developing entirely new products and processes, working through leadership and people issues. The underlying sub-structures may change, but the basic steps are the same.

When I encounter an organization that already has a “standard problem solving approach” I do not attempt to tell them they are wrong or confuse them by introducing a different structure. Rather, I adapt the Improvement and Coaching Kata to align with their existing jargon and language, and help them learn to go deeper and more thoroughly into their existing process.

Stability is a Target Condition

I see a lot of pushback about working to “return a process to standard.” In reality, that is the bulk of the activity in day-to-day improvement. The whole point of having a standard in the first place is to be able to see when the actual process or result is somehow different.

Think about it: If there isn’t an active means of comparing “actual” vs. “standard” what is the point of having a standard in the first place?

Think of the standard as a target condtion.

What obstacles are preventing you from [operating to that standard]? You can guess, but the best way is to diligently try to operate to the target condition and see what gets in your way. That might not happen immediately. Maybe some time will go by, then BAM! You get a surprise.

This is good. You have learned. Something you didn’t expect has interfered with getting things done the way you wanted to. Time to dig in and learn what happened.

Maybe there was some condition that you could have detected earlier and gotten out in front of. Who knows?

This is all part of the continuum of Troubleshooting by Defining Standards.

You Cannot Meet a Challenge Without Working on Stability

As you are working to reach new level of performance – working toward a new challenge – there will be a point when the process works sometimes, so you know it is possible. But it doesn’t work every time because there are still intermittent obstacles that get in the way.

Nevertheless, you have to work diligently to see problems as they occur, respond to them, dig into causes (root cause analysis anyone?) and systematically protect your process from those issues.

The only real difference between covering this territory for the first time vs. trying to recover a previously stable process is that in the later case you can ask “What has changed?”

But, in the end, in both cases – stabilizing a new process vs. re-stabilizing an old one – you are dealing with conditions that are changing from one run to the next. That is why it works sometimes and not others. You don’t know what is changing. You are trying to figure it out by experimenting and learning.

What About Root Cause Analysis?

My challenge is still a stable process.

My current condition is my level of understanding of how the process works today, and the exact mechanism that results in a defect. Even defects are produced by a process – just not the process we want.

That understanding will be incomplete by definition – because if we truly understood what was going on we wouldn’t have the problem. So… what do I know (and can prove with evidence) and what do I not know.

What do I suspect? What evidence do I need to gather to rule out this possible cause, or keep it in play? Next experiment. What do I expect to learn?

I’ll write a more detailed post about this at some point. I think it is a topic worth digging into. Suffice it to say that I have absolutely used the Improvement Kata structure to coach people through finding the root cause of wicked quality problems.

It really helped that they were able to see the same underlying pattern that I had already been teaching them. It made things simpler.

Don’t Complicate a Simple Concept

It’s all “solving problems” (the term “problem solving” apparently has some specific form it needs to take for some people).

The underlying structure for all of it is scientific thinking. Some say it’s PDCA / PDSA. Same thing.

Splitting semantic hairs and saying “this is different” makes simple things complicated. Yes, there are advanced tools that you use when things get tough. But… addition and subtraction; basic algebra; advanced polynomials; basic differential calculus; advanced multivariate calculus – IT IS ALL MATH. You apply the math you must to model and solve the problem at hand.

DON’T apply more math than you need just because you can. That serves no purpose except, perhaps, to prove how smart you are… to nobody in particular.

Solving problems is the same. There are some cases where I need to develop a designed experiment to better understand the current condition – the interactions between variables. There are cases where other statistical tools are needed. Use them when you must, but not just because you can.

Use the simplest method that works.

Toyota Kata: What If There Is No Takt Time?

The default Starter Kata for “Grasp the Current Condition” places heavy emphasis on takt time and variation in timing of a regular process. However a lot of processes, both within manufacturing as well as in other domains such as health care, don’t seem to have any kind of regular heartbeat.

As Steve Medland pointed out at KataCon, this can present a struggle for a novice learner, as well as for a lot of coaches.

Before we get into ways to deal with this, I want to level set on what takt time is, and what it does for us.

Why Takt Time?

From an industrial engineering standpoint, takt time is an expression of how much capacity you need.

The traditional way to calculate takt time is to divide the total time available by the output required in that time. This gives us a “time per unit of output” that we have to achieve if we are going to get everything done. In other words, takt time is the required rate of production.

The whole goal of an ideal “Just-in-Time” system is that we have only the capacity required to meet the demand. If the system is even able to run faster than the takt time, we have excess capacity. Excess capacity = extra cost, and “overproduction” is a symptom of having excess capacity. Note that this is the “ideal” – it isn’t anything we can realistically achieve. The concept gives us a direction to strive toward.

Also Note: Determining how much capacity you need has absolutely nothing to do with how much capacity you have.

OK, that answered the question “What is takt time?” but not the question I posed: “Why takt time?” After all, I could just as easily say I need the capacity to product 96 units per day. But that doesn’t answer the question, “How fast do I need to go?” And that is what takt time gives us.

Think of it this way. If I need to make 96 units during the course of an 8 hour day, then I need to have made 48 units in four hours.

To make 48 units in four hours, I need to make 24 units in 2 hours. Which means 12 units in 1 hour. 6 units in 30 minutes. 3 units in 15 minutes. One unit every 5 minutes. And that is my takt time. (This is an oversimplification since I did not subtract break times to make the math easier to make the point.)

Thinking of it this way gives the people doing the work a quick way to know, very quickly, if they are ahead or behind. They can ask, “How long did this unit take?” and compare that with, “How long did we have?”

A Point of Comparison

Which brings us to the “Why.”

If I measure the time between units output at the end of the line, I can compare the actual time interval (the cycle time) with the required time interval (the takt time).

  • If we need to complete a unit every five minutes (takt time), AND
  • We know that our process can do that when there are NO problems, THEN
  • We can see very quickly if there IS a problem. We have to attack a source of variation and work on stability.
This image has an empty alt attribute; its file name is Heartbeat.png

On the other hand,

  • If we need to complete a unit every five minutes (takt time), and
  • We know that our process is not capable of doing so even when running smoothly, then
  • We know we have to change the entire system to make rate.

Distinguishing between these two conditions is the main benefit of building a cycle time run chart (step 3 in the Starter Kata of Grasp the Current Condition.) That is a topic for another post, or just get a copy of the Toyota Kata Practice Guide ;).

The issue comes when people don’t see a steady rate of demand.

Sometimes they generally know how much time is in the day, but they see demand fluctuating all over the place.

This is true in manufacturing work as well as other cases, such as engineering work, software development, and a lot of cases in health care. The time to complete one “unit of work” varies, so it is hard to see any kind of cadence to the output even if the work is steady.

Key Question: Are you ahead or behind?

And how can you tell?

Regardless of all of the variation, though, we still want to know the answer to questions such as “Are we on track to get everything done today?” or “Has my load exceeded my capacity?” or “Is the backlog increasing, decreasing, or holding steady?” unless we are simply relying on luck. Asking and answering these questions is the purpose of many of the “lean tools” – including takt time.

When to Bring it Up

Everything above, though, is information for the coach to keep in mind. What a lot of us (myself included) do all too often is take beginners into advanced application way too fast. We forget what it is like to be overwhelmed with just getting through the day, and the limits that places on anyone for taking in new concepts.

I bring it up for the coach because I think the chances of the learner discovering it on their own are significantly lower (perhaps close to zero) if the coach is starting in the same place.

If you are getting pushback on the concept, it might be time to back off a bit and give your learner some space.

Steve Medland had a mini (5 minute) presentation at KataCon 2020 that briefly addressed some of his experience with this situation.

He pointed out that the default worksheet templates for Grasp the Current Condition and Establishing a Target Condition emphasize process timing and cadence pretty heavily.

From Steve Medlin’s KataCon presentation
From Steve Medlin’s KataCon presentation

And the alternative is a blank template:

From Steve Medland’s KataCon presentation

Steve makes a good case that there ought to be something that provides a more general structure without removing all structure. I agree – as a coach, structure is one of the things you are bringing to the table. Any learner, at any level of expertise, is more deeply embroiled in the process itself than in the process of improving the process. Having some structure really helps.

The key is to adjust the structure to fit the situation.

From Steve Medland’s KataCon presentation

With beginners, the concept of takt time can be distracting, even paralyzing. Even more so if we use alien jargon like “takt time.”*

Using a hybrid structure like Steve proposes can get the learner moving into process analysis without getting wrapped up on terminology, or struggling with something she sincerely believes has nothing resembling a cadence.

Then, when the opportunity arises, the coach can still gently, but persistently, ask “How often does this need to be done?” and “How do we know if we are ahead or behind?”

Often the resistance is less about knowing there is some kind of schedule, and more about just being overwhelmed by all of the chaos that prevents any kind of stability.

Steve and I agree that timing is important. And I agree that it is important enough that it might be best to hold off on introducing it as a concept so we don’t create resistance unnecessarily.

But please don’t completely throw away measuring time just because it is hard. In fact, the harder it is, the more important it likely is. When it is easy to determine takt time, we likely already have an idea how long things are taking. The less appropriate takt time seems, the more critical it becomes to dig deep into where the time is going.


*Believe it or not, Godwin’s Law can even be applied to “takt time” if you research your history enough.

LEI Book: Getting Home

“Are you ahead or behind?” seems an innocent enough question.

But when asked by a Toyota advisor, the simple process of becoming able to answer it launched Liz McCartney and Jack Rosenburg on a journey of finding consistency in things that were “never the same” and stability in things that “always changed.”

Getting Home is, first and foremost, a story. And, with the “business novel” being an almost worn-out genre, seeing a non-fiction story was refreshing. So when Chet Marchwinski from the LEI offered a review copy to me, I accepted.

For the story background, I’ll leave it to you to read the blurb on Amazon.* Better yet – read the book – and it is worth reading. I’ll say that right up front.

Yet with stories like this it is all too easy to dismiss them because they have different circumstances from “my” specific case and say “Yeah, it worked there, but won’t work here.”

I would contend, however, that in this case “it worked” in situations that are far more difficult than anything we are likely to encounter in most organizations.

What I want to do here is help pull their specific achievements into more general application – what lessons are here that anyone can take away and apply directly.

What They Achieved

I can’t think of a lot (any?) business circumstances that would have more built-in variability and sources of chaos than the process of rebuilding communities after a disaster such as a hurricane or flood.

Every client has different circumstances. The make, mix and skill levels of the volunteer workforce changes continuously. Every community has different bureaucratic processes – not to mention the various U.S. government agencies which can be, well, unpredictable in how and when they respond.

Yet they have to mobilize quickly, and build houses. This means securing funding, getting permits, mobilizing unskilled and skilled labor, and orchestrating everything to meet the specific needs of specific clients on a massive scale… fast.

How They Achieved It

When they first connected with their Toyota advisor, the simple question, “Are you ahead or behind?” prompted the response that drives all improvement, all scientific advancement, all innovation:

“We don’t actually know.”

Actually they did, kind of, but it was in very general, high-level terms.

And that is what I encounter everywhere. People have a sense of ahead or behind (usually behind), but they don’t have a firm grasp on the cause and effect relationship – what specific event triggered the first delay?

This little book drives home the cascading effect of ever deepening understanding that emerges from that vital shift from accepting things as they are to a mindset of incessant curiosity.

Being able to answer “Are you ahead or behind?” means you have to have a point of reference – what is supposed to happen, in what order, with what timing, with what result. If you don’t know those things, you can only get a general sense of “on track” or not.

They had to develop standards for training – what to train, how to train – volunteers! – , which meant challenging assumptions about what could, and could not, be “standardized.” (A lot more than you think.)

A standard, in turn, provides a point of reference – are we following it, or are we being pushed off it. That point of reference comes back to being able to know “Are we ahead or behind?”

 

It Isn’t About the Specific Tools

Yet it is. While it isn’t that important about whether this-or-that specific tool or approach is put into place, it is critical to understand what the tools you use are there to achieve.

As you read the book, look for some common underlying themes:

Information as a Social Lever

The project started revolving around the ahead/behind board.

In the “lean” world, we talk about “visual controls” a lot, and are generally fans of status boards on the wall. We see the same thing in agile project management (when it is done well).

These information radiators work to create conversations between people. If they aren’t creating those conversations, then they aren’t working. In Getting Home it was those conversations that resulted in challenging their assumptions.

Beyond Rote Implementation

Each tool surfaced more detail, which in turn, challenged the next level. This goes far beyond a checklist of tools to implement. Each technical change you make – each tool you try to put into place – is going to surface something that invites you to be curious.

It is the “Huh… what is happening here?” – the curiosity response – that actually makes continuous improvement happen. It isn’t the tools, it is the process of responding to what they reveal that is important.

Summary

Like the tools it describes, Getting Home is an invitation, and that is all, to think a little deeper than the surface telling of the story.

My challenge to you: If you choose to read this book (and I hope you do), go deeper. Parse it. Ask “What did they learn?” ask “What did this tool or question reveal to them, about them?” And then ask “What signals did they see that am I missing in my own organization?”

 

 

———-

*This is an affiliate link that give me a very small kickback if you happen to purchase the book – no cost to you.

It will feel worse because it’s getting better.

image

The line is starting to flow, or at least there is more time flowing than not flowing. The places where it isn’t flowing well are now much more evident.

Things are speeding up. That is placing more stress on the engineering and materials supply processes where, before, they were shielded by a rough start-up that was always behind schedule.

They are catching up on the backlog, closing in on “on schedule shipment.”

“John” forgot to send a batch of parts to an outside processor. Before that would have been no big deal, it would be a day or so before those things were actually needed. But this time it briefly stopped the line and forced a work-around.

When everything was a work-around, nobody noticed. This time it got on the radar. It feels worse because the system is sensitive to smaller problems now, and there are plenty of those.

It isn’t “John’s” fault. He is flooded with a constant flow of things he needs to react to. There isn’t a structure for him to work within. That is the next opportunity.

Thus, it is critically important to remember a Toyota mantra:

‘No problem’ is a big problem.

If problems are not coming up, then your system is hiding them, plain and simple. You have stopped learning, stopped improving, stopped growing.

It is an easy groove to get into because we get all kinds of feel-good brain chemicals when things are going smoothly. We want more of those, less of the ones that call us to action.

But it is those “call to action” things that drive us to get better.

Target Condition vs. Target

This search question landed someone on my site yesterday, and I thought it would be a good one to try to answer specifically:

why is lean manufacturing preferred to implement target condition as compared to target?

In other words, what is the difference between a “target” and a “target condition?”

Where this gets sticky is that there isn’t any canonical definition of either term. There are people who use “target” to describe what I mean when I say “target condition.” So I think it is probably best to focus on that term: “Target Condition.”

“Target Condition” = “Target Process”

A team I am working with is bringing up a new (to them) product line. Their short-term target is to complete 8 units / day. But just saying that doesn’t describe the way they want the process itself to operate.

The Target Condition for the line is unit-by-unit flow in critical parts; with order-by-order flow in others (where we can’t overcome batching at the moment). To that end, we have created some guidelines for the layout and movement of work; limits on work-in-progress inventory, etc.

Block diagram of flow line

We know that this can’t be achieved right away, but aren’t sure what problems will surface as we try. Thus, the effort is focused on trying to operate to the target process in order to surface those obstacles so they can be systematically addressed.

So – to answer the question “Why [does] lean manufacturing prefer to implement a target condition as compared to a target?” – Unless we know how we want the process to operate, we have no point of comparison for how it is actually operating.

Without the ability to compare “What should be?” with “What actually is?” we cannot identify the gaps we need to close, the problems we need to work on to get there.

Thoughts on Failure Modes of Kaizen Events

The common frustration in the weeks following a classic 5 day “kaizen event” (which go by many names) is that the follow-on actions are not completed, and the changes that were made erode quickly.

Recently I have asked myself why it works so well during the actual workshop, and then fades so quickly afterwards.

Mike Rother has a great graphic that starts this conversation:

The question I am exploring today (and bringing you along as I reflect on it) is “Why do the ‘lean tools’ work so much better during an event than during “business as usual?”

Hanging this on my current working theory, I think it comes down to different patterns of interaction.

What Happens During the Event

Look at how the structure of these events drives how people interact with one another.

The workshop preparation usually involves establishing a clear bigger-picture sense of the problem to be solved. Even if it isn’t specific, the team education establishes a sense of direction, typically toward 1:1 flow at takt, and a pull process that limits lead times.

The structure of the workshop itself has the team working together studying the current flows, seeing the problems for themselves, and working in pairs or small groups on proposed solutions.

Those proposed solutions are usually structured as experiments – “let’s try this.” At the end of a typical day there is some kind of structured reflection on what we tried, what we learned, what we are going to try tomorrow, and what we expect to achieve.

So – we have small groups of people, collaborating to solve a specific problem, running experiments and learning what will work.

Unfortunately the team usually comes up with more ideas than they can actually try out. Those end up on a to-do list for follow-up.

After the Workshop Week

There is a fundamental shift in the dynamics after the pizza party on Friday.

The team members go back to their regular jobs. The problems they are focused on are different. The leftover items from the workshop are added to the “stuff I need to do” list that nearly everyone in every workplace has.

Rather than continuous collaboration, there might be periodic meetings to talk about the status of these “action items.” But there isn’t specific time carved out to work on them.

If this is what happens then “Business as Usual” couldn’t be more different than the working structure that created all of these improvement ideas. Business-as-Usual is not creative, does not allow for experimentation, and is optimized for repeating what we already know vs. learning something new.

I’d like to point out here that I have seen exactly the same situation in companies that many others consider “lean” benchmarks. What I saw in those companies was a much heavier infrastructure of dedicated lean specialists who were doing the heavy lifting. It still wasn’t embedded in “business as usual.” Instead it is a parallel process that is running improvement events about as fast as the day-to-day processes erode the improvements.

In fact, to this day, after being after this for two decades, one of those companies still has to hire “lean experts” from outside. Why? What is the business-as-usual day of a supervisor that they never learn this stuff?

In summary: During the kaizen even week, we organize and interact in a way that works for creative problem solving and making improvements. Then, the next week, we stop.

It shouldn’t be a surprise that the dynamics shift from “experiment to solve the problem” to “get this stuff done.” Business-as-usual is represented by “get this stuff done.”

 

 

Lessons from Driving a Forklift

The spring and summer of 2000 were a long time ago, but I learned some lessons during those months that have stayed with me. In fact, the learning from that experience is still happening as I continue to connect it to things I see today.

I was a member of a team working hard to stand up a new production line of a new product. The rate pressures were very high, the production, production control, and quality processes were immature.

At a high level, the parts flow was supposed to work like this:

Steel parts are fabricated and welded, based on the production schedule for various configurations.

Unit sets of parts were sent to outside paint. (We didn’t have our own paint system yet.) In reality, unit sets would be broken up as some parts went to sister plants, others went to outside vendors, each with their own lead times and flow times.

Parts return from outside paint. Because of the different vendors and lead times, different parts arrive on different days.

On assembly day, kits are built for the parts required at each entry point on the assembly line. Those kits are delivered based on a pull. The assembly line had a number of entry points and feeders, so for each takt time cycle, though only one “unit’s worth” of parts were actually delivered, those parts were for different units, as feeders had different lead times into the main line.

image

The innocuous challenge was to develop the kitting process (in red) that broke down the parts into  kits and got them delivered to the line.

I got pulled in on Thursday of a “kaizen event” that was supposed to develop this process. What had actually happened, though, was analysis paralysis, a lot of theoretical discussions, a lot of drawings on a white board, but nothing had actually been tested or tried. My assignment was simple: Organize this and get it going on Monday.

I had four people working for me, though they were not officially direct reports. They were an eclectic mix of personalities and styles.

A few things became apparent very quickly:

The process of scheduling which parts needed to be fabricated and welded to be sent through painting on any particular day was broken. Result: What was needed wasn’t necessarily what got sent to paint.

The processes of keeping parts organized during the various outside paint operations was broken. Result: Unit sets got mixed together, parts went missing.

As a result this is what my days looked like:

I came in before a hint of dawn at 4:45am to prepare for the assembly line starting at 5:40. I would go out into the parts yard with the day’s production schedule and a flashlight. My goal was to answer a simple question:

What units on this list can I build with the parts that are here?

I would re-sequence the production schedule to front-load the units that looked like we had everything we needed. (This caused all kinds of problems with serial number sequences and engineering change control, but that is a different story.)

We would start pulling in those parts, and breaking them down into the kits. We set up FIFO lanes for each entry point on the assembly line, and worked as fast as we could to build up about a three hour backlog. Why? Because it took about three hours to expedite a missing part through paint. Once we had that queue built up, as we discovered shortages (or parts painted the wrong color!), we had a chance to get the situation corrected and have a shot at not creating a shortage on the line.

We were working 10 hour shifts, I was typically there for 12-14 hours. Even though I was a “lean guy” my daily work was orchestrating all of this chaos, expediting and delivering parts, and I spent at least six of those hours every day driving a forklift. I got really good at forktruck operation that summer.

At the end of the day, I might sit and chill for a little while, then would get in my truck, go home, and do it all again tomorrow. One of those days as I went to back out of the parking space, I hit the turn signal to put my stick-shift truck into reverse – because that’s how the forklift controls worked.

What I Learned

I actually continue to learn. But here are a few things that have stood out for me.

Shop Floor Production Supervisor is a really hard job. I wasn’t a supervisor, but I was doing many of the things that we asked supervisors to do. Making my people take their breaks. Slow down on the pallet jack. Listening to a frustrated guy who was ready to quit – understanding his paradigm, and helping him re-frame his experience. Constant radio calls to places in whatever building I wasn’t in at the time. Operating within a system that functions only with continuous intervention.

I totally knew how to set up a workable, stable process. I knew how to get all of these processes linked together to pull everything through. I knew how to build in effective quality checks.

What I was able to do was spend a few minutes at the end of my day, or during my lunch breaks (instead of eating) trying to implement some kind of simple visual control that mitigated against repeating a mistake we had just made. We attached a tag with a production sequence number (000 through 999, repeating) to each kit. That let us, and the people on the line, see if we had delivered something out of sequence.

Then, after I had delivered a yellow painted kit to go onto an otherwise blue painted unit (oops) we made a board with the production sequence numbers and the associated colors for the major components.

Then… after I had delivered (note the theme here) the wrong size of a major component to the line, we added that information to the board AND tagged those components so we could quickly distinguish one from the other.

But I was never able to address the upstream issues that were delivering short kits to us in the first place. All I could do was add steps, add time, add inventory to protect myself from those things and do my best to fix it before the main line got stopped.

We had a saying in the Army: “When you are up to your a$$ in alligators, it is hard to work on finding the best way to drain the swamp.”

Thus:

It is unreasonable to expect systems improvements when everyone is scrambling to make the system function at all. It isn’t that they don’t want to make improvements. It isn’t that they don’t know what to do. It is that there is barely time to breathe before the next problem needs to be stamped down.

And finally: A five person job requires five people. I had four people working for me. That wasn’t enough. Guess who had to fill in the rest of it? I tried my best to handle the problems so they could get into some kind of cadence on the stuff that wasn’t a problem. But (Routine+Problems) = (or greater than) 5 people in this case, and it took all of us just to navigate the rapids without dumping everyone out of the boat. If everything was running smoothly, it was probably a three person job. If we could have set up a sequenced pull from assembly all the way back through weld, it would have been a two or even one person job.

Reflection

That forklift key is still on the keyring in my pocket as a reminder of that time. What follows are some of the bigger-picture things that come to mind as I continue to construct, tear down and reconstruct my own thinking.

Attribution Error

There is a strong tendency among us humans to attribute our own failures to a poor environment, but to attribute other’s failings to individual character or capability. Yet in many cases, simply changing the venue or circumstances can allow a previously low-performer to blossom. We see this (and the opposite) all of the time in professional athletics.

Making this error is easy when we are talking about “they.”  If only they… Why don’t they… They don’t get it… “They” are people who are likely doing the very best they can within the context of the system they are in. And, as I pointed out above, changing the system from the inside is hard.

Actually that isn’t quite accurate. Changing the system is hard work.

The Pace of Change

The organization I was describing above was experiencing circumstances at the time that outpaced their ability to experiment, reflect, and adapt. Every organization has a rate at which they are able to change.

Just to make things more complicated, it is possible to learn what must be done much faster than those things can be put into place. This frustrates a lot of change agents. They see the technical changes that must take place, but often struggle against cultural barriers and obstacles. These things take much longer, and it is pretty much impossible to put them on a fixed timeline or project plan. Thus, we frame them as “resistance to change.” We know what must be done, but “they” don’t do it.

Organizations Under Stress

When an organization is under stress, there is fear of complete breakdown. People become very conservative and avoid the uncertain and unfamiliar. If they become overwhelmed just trying to get their task done, they are going to shut out any information that isn’t relevant right now. Horizontal communications break down, and the feeling of isolation increases.

At this point, all coordination has to funnel upward and then downward through the vertical linkages, as cross-functional coordination largely isn’t happening.

Now the higher leader gets overwhelmed, feeling she has to micro-manage every detail- because she does. “Why don’t they talk to each other?” Well, the structures for that were probably very informal, and now have broken down.

This Isn’t About “Them”

As I mentioned above, it is really easy to attribute the perception of dysfunction to individuals. And as people become isolated within their own task-worlds, avoiding a mistake becomes the dominate motivation. This happens even in organizations with the most benign intentions.

If you are a leader, pay attention to the emotions. If people are snippy, are pushing back on ideas as “just more work” then that saturation point may well have been reached. Pushing harder isn’t going to make things go faster, it is going to slow them down.

image

Overproduction vs. Fast Improvement Cycles

A couple of weeks ago ago I posted the question “Are you overproducing improvements?” and compared a typical improvement “blitz” with a large monument machine that produces in large batches.

I’d like to dive a little deeper into some of the paradoxes and implications of 1:1 flow of anything, improvements included.

What is “overproduction” – really?

In the classic “7 wastes” context, overproduction is making something faster than your customer needs it. In practical terms, this means that the cycle time of the producing process is faster than the cycle time of the consuming process, and the producing process keeps making output after a queue has built up above a predetermined “stop point.”

If the cycle times are matched, then as an item is completed by the upstream process, it is consumed by the downstream process.

If the upstream process is cycling faster, then there must be an accumulation of WIP in the middle, and that accumulation must be dealt with. Further, those accumulated items are not yet verified as fit-for-use by the downstream process that uses them.

The way this applies to my “Big Improvement Machine” metaphor is that we are generating “improvement ideas” faster than we can test and incorporate them into the process.

“Small Changes” Doesn’t Mean “Slow Changes”

No matter how good your solution or idea, it is just an academic exercise until it is anchored as the an organizational norm. The rate limit on improvement is established by how quickly people can absorb changes to their daily, habitual routine.

Implementing and testing small changes one-by-one is generally faster than trying to make One Big Change all at once. When we do One Big Change, it is usually actually a lot of small changes.

I hear “we don’t have time to experiment,” but when I ask what really happens if a big change is made, what I hear almost every time is they had to spend considerable time getting things working. Why? Because no matter how well the Big Change was thought through, once you are actually trying it, the REAL problems will come up.

Key Point #1: Don’t waste time trying to develop paper solutions to every problem you can imagine. Instead, “go real” with enough of the new process to start revealing the real issues as quickly as possible.

In other words, the sooner you start actively learning vs. trying to design perfection, the quicker you’ll get something working.

Slow is Smooth, Smooth is Fast

Your other objective here is to develop the skill within the organization to test and anchor changes quickly, as a matter of routine. This will take time.

When we see a high-performance organization making rapid big changes, what we are typically seeing is making small changes even more rapidly. They have learned, through practice over time, how to do this. It isn’t reasonable to expect any organization to immediately know how to do this.

Key Point #2: If managers, or professional change agents (internal or external consultants, for example) are telling people exactly what to do, this learning is not taking place.

It is critical for the organization to develop this learning skill, and they are only going to do it if they can practice. Learning something new always involves doing it slowly, and poorly at first. If your internal or external consultants are serving you, their primary focus is on developing this basic competence. Their secondary focus is on getting the changes into place. This is the only approach that actually strengthens the organization’s capability.

The same is true for an operational manager who “gets” lean, but tries to just direct people to implement the perfect flow. It will work pretty well for a while. But think about how you (the operational manager) learned this stuff: Likely you learned it by making mistakes and figuring things out. If you don’t give your people a chance learn for themselves, you limit the organization in two ways:

  1. They will never be any better than you.
  2. They will wait to do what they are told, because that is what you are teaching them to do.

Think about what you want your people to be capable of doing without your help, and make sure you are giving them direction that requires them to practice doing those things. It will likely be different than telling them what they layout should look like.

Improve your Cycle Time for Change

Coming back to the original metaphor, if you want fast changes to last, you have to work speeding up the organization’s cycle time for testing improvement ideas. Part of this is going to involve making that activity an inherent and deliberate part of the daily work, not a special exception to daily work.

Part of that is going to be paying attention to how people are working on testing their ideas. The Improvement Kata and Coaching Kata are one way to learn how to deliberately structure this work so that learning takes place. Like any exponential curve, progress seems painfully slow at first. Don’t let that fool you. Be patient, do this right, and the organization will slingshot itself past where you would be with a liner approach.

Small changes, applied smoothly and continuously become big changes very quickly.

Are You Overproducing Improvements?

Imagine a factory with a large monument machine. It takes several days to set up. When it does run, it runs very fast, much faster than you can actually use its output. Therefore, you take the excess output and store it to use later. Actually, you don’t know how many items you need to make, so you make as many as you can while the machine is available to you.

image

Some of that excess output may prove to be less useful than you thought, but there is pressure to use it all anyway since it was so expensive to produce.

After a run making items for one process, you change it over to make items for a different process, and build up a queue of output there.

When all of the output is used, it all may or may not work the way you expected it to.

Most of us would see this as a classic case of “overproduction” – overwhelming the system with excess output that hasn’t been checked for quality, that isn’t needed right now, and might or might not be useful in the future. But it seemed like good efficiency to make it while we could.

Our lean thinking tells us we want to do a few things here. Ultimately, we want to work hard to break up the batches, and make the value flow more evenly to each of the customer processes, and ultimately to the end customers. The work we must do to keep things moving smoothly and evenly will pay off in both tangible and intangible ways.

One of the primary reasons we push hard for 1:1 flow in the lean world is to enable one-by-one confirmation.

We want to test each item of output to confirm that it actually performs as expected rather than making lots of them without knowing if they are any good.

How Do You Produce Improvements?

Now, imagine doing improvements this way. What would it look like?

A process would be scheduled to receive the rapid output of the Improvement Machine.

The Improvement Machine would be set up over a period of several days to produce improvements for the target process.

Once it was running, we would run the Improvement Machine very fast for a week or so. It would produce improvements faster than the target process can really absorb them.

At the end of the run, we might test the improvements as a batch. We might not test them at all, but rather report that they have been implemented with the assumption that they will work. We would also have excess improvements stored on a to-do list for future use.

Those excess improvements might, or might not, prove to be useful, but we would have huge pressure to implement them because they are on the list.

Once the machine was done producing improvements for one process, it would be set up to produce improvements the same way for another.

We would measure how many times we were able to run the improvement machine in a year, not so much the actual sustained impact we were making.

Improvements that were made without the machine might not be measured or credited at all. Or worse, these rogue improvements might actually be discouraged since they are made by people who aren’t certified to run the machine.

Now… substitute “kaizen event” for “improvement machine” and see if it makes any sense.

Why Are Big Batches Necessary?

The reason the Large Monument Machine has to cycle batches of output to different customers is because those customer processes don’t have the internal capability to do what it does. We need an outside resource to do it.

The countermeasure we strive to apply in these cases is to identify the capability that the customer process does need. We then work hard to develop it on a scale they can incorporate into their daily work. This is typically smaller, more specialized, and scoped to their needs.

My purpose here, though, is to apply a metaphor, not to discuss the economics of large capital equipment.

When we “batch improvements” it is often for the same reason: The area that is being improved can’t do it themselves, so we have to dedicate a scarce outside resource – an improvement expert – to lead them through it. Since that improvement leader can’t be there 100% of the time, he has to work as hard and fast as he can when he IS there.

Making Improvements vs. Teaching How to Make Improvements

The countermeasure in both scenarios is the same: Develop the capability within the process. In the case of making improvements, this means asking ourselves “Why can’t they do it?”

All of these are harder than just doing it for them. But if we want improvement to flow, this is the work that must be done.

Think Big, Change Small

Anton, my Dutch friend, had a study mission group of Healthcare MBA students from the University of Amsterdam visiting Seattle last week.

Friday morning I spent about four hours with them going through the background and basics of the Improvement Kata and Coaching Kata, and worked to tie that in to what they observed in their visits to local companies. They were a great, engaging group that was fun to work with.

One thing I do to close out every session I do with a group is ask “What did we learn?” and write down their replies on a flip chart. I find that helps foster some additional discussion and consolidate learning. It also gives me feedback on what “stuck” with them.

Sometimes I get a gem that would make a good title for a blog post. The title of this post is one of those.

Think Big

Alice and the Cat

Alice went on, “Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where…“ said Alice, “…so long as I get somewhere,” Alice added in explanation.

“Oh, you’re sure to do that,” said the Cat, “if only you walk long enough.”

The question, of course, is whether or not where Alice ends up is where she intends to go. A lot of continuous improvement activity takes this approach –  Look for waste. Brainstorm ideas. Implement them. Just take steps. And, like Alice, you will surely end up somewhere if you do this enough.

I had a former boss (back in the late 90’s) advocate this approach. “We are painting the wall with tennis balls dipped in paint.” The idea, I think, was that sooner or later all of the splotches would start to connect into a coherent color. Maybe. But, at the same time, he was also very impatient for tangible results. Actually that isn’t true. He was impatient for tangible activity which is not the same thing at all.

Direction and Challenge Establish Meaning

In her journeys through Wonderland, Alice learns that objective truth has no meaning in a world of random nonsense. The story, of course, is a parody of the culture and times of Victorian England. It does, however, reflect the frustrations many practitioners can feel when they are just trying to “make improvements.”

As one thing is “fixed,” another pops up for any number of reasons:

  • The “new” problem may well have been hidden by the “fixed” one.
  • Leadership may be chasing short-term symptoms and constantly redirecting the effort.

Day to day it just seems like random stuff, and can get pretty demoralizing.

The point of “Think Big” is that being clear about where WE (not just you) are trying to go helps everyone understand the meaning of what they are doing. That is the whole point of “Understand the Direction and Challenge” as the first step of the Improvement Kata. “What is the meaning behind what you are working on?” It is really a verification check by the coach that the coach has adequately communicated meaning to the learning.

Establish “Why” not “What”

At the same time, it is important for the organization to be clear on why improvement is necessary. I have discussed this a number of times, but keep referring back to Learning to See in 2013 where I ask “Why are you doing this at all?” as the question everyone skips past.

“Where we are going” should not simply be your model of your [Fill Company Name In Here] Production System.

No matter how well explained or understood, a model does not directly address the “Why are we doing this at all?” question that provides meaning to the effort.

It may well establish a good representation of what you would like your process structure to look like, but it does not give people any skill in actually putting these systems into practice, nor a reason to put in the effort required to learn something completely new.

Change Small

Small changes = fast progress as long as there is a coherent direction.

The classic 5 day kaizen event is often an attempt to make a radical improvement in a short period of time. Things usually look really impressive at the end of the week, and even into the next few weeks. What happens, though, is that the follow-up is usually more about finishing up implementation action items than it is working to stabilize the new process.

The problem comes from the baseline assumption that we already understand all of the problems, and our changes will solve them. We line things up, get 1:1 flow running, and yes, there is a dramatic reduction in the nominal throughput time simply because we have eliminated all of the inventory queues.

There is tons of research that backs up the assertion we can’t expect people to be creative when they are under pressure to perform. They are going to revert to their existing habits. During the event itself,  the short time period and high expectations put pressure on people to just implement stuff. People are likely to defer to the suggestions and lead of the workshop leader and install the standard “lean tools” without full understanding of how they work or what effect they will have on the process and people dynamics.

Come Monday morning, we put all of those changes to the test… at once. The people are working in a different way. The problems that will be surfaced are different. The tighter the flow, the more sensitive the system will be to small problems. It is pretty easy to overwhelm people, especially the supervisors who have to decide right now what to do when things don’t seem to be working.

That same pressure to perform exists, only now it is pressure to produce, and possibly even catch up production from what was lost during the previous week. Once again, we can’t expect people to think creatively when these new issues come up, they are going to revert to what they know.

When we do see successful “big change” it is usually the result of many small changes that have each been tested and anchored.

So why is the “blitz” approach so appealing? I think I got some insight into the reason in a conversation with a continuous improvement director in a large corporation. He had so little opportunity to actually engage and break things loose that, when he did, he felt the need to push in everything he could.

My interpretation of this goes back to the first line above: Small changes = fast progress as long as there is a coherent direction. In his case, there wasn’t coherent direction. He had a week, maybe two, to push as hard as he could in the direction he felt things should go. The rest of the time, things were business as usual.

This is why “think big” is important. It provides organizational alignment, and reduces the pressure to seize a limited opportunity and, frankly, inject chaos.

Small, Quick Changes

Because we often don’t see just how long it takes to stabilize a “quick, big change,” we tend to think that quick small changes are slower. I disagree. In my experience the opposite is true.

When there is a clear Challenge and Direction, and frequent check-ins via coaching cycles (or less formal means) on what changes are being made, no time is wasted working on the wrong things.

When small changes are made and tested as part of experiments vs. just being implemented, then there is less chance of erosion later. Rather than overwhelming people with all of the problems at once from a bunch of changes, one-by-one lets them learn what problems must be dealt with. They have an opportunity to always take the next step from a working process rather than struggling to get something that is totally unfamiliar to work at all.

That, in turn, builds confidence and capability.

In a mature organization that has practiced this for years, an outside observer might well see “big changes” being made. But that organization is operating from a base of learning and experience, and what might look big to you might not be big to them. It is all a matter of perspective.

What Do You Think?

I’m throwing this out there, hoping to hear from practitioners. What have you struggled with getting changes made that actually shift people’s behavior (vs. just implementing tools and techniques). What has worked? What hasn’t worked? I’d love to hear in the comments.