Author: Mark

Posted on

Recovering a Failed ERP Implementation

I was working with this company mainly on their shop floor processes: Quality, Process Improvement, Daily Management – classic stuff. It was a medium sized plant (a few hundred people) that was part of a larger company with significant business footprints in Europe and North America.

They hadn’t involved me in their upcoming ERP implementation. Heck, they hadn’t even told me they were switching systems. I just heard about it in the course of the day-to-day conversations. My feeling was they were treating this as background noise in their daily business, and I told them. “Focus on this, it will be one of the hardest things you have ever done, and if you treat it casually it will bite you” (or words to that effect).

I was assured that everything was under control.

Over the ensuing weeks I saw a conference room full of outside people all sitting at laptops. I also saw “training” sessions that were mostly lecture and demonstration of the features of the new software. I picked up on conversations that circled around “How will the new system ___(fill in one of their perceived necessary work tasks)___.”

I wasn’t on site on the day the cut over to the new system – and simultaneously cut off their legacy system.

I was on site during the aftermath.

Work orders were released without materials available.

Shipment manifest errors were causing customer rejections.

There were surprise shortages of basic commodity supplies.

The production planners were really struggling.

Sales revenue dropped. Revenue dropped. The bottom line impact was, to say the least, significant.

Corporate’s response was to assemble a team of experts from the global operations and parachute them into this site to get things working.

They asked me to organize that intervention.

It’s WORKFLOW, not FEATURES

The first step in this was for each stakeholder (the area managers, such as supply chain) to identify, exactly, what problems they had.

First we had them write what they thought the problem was. On the first pass, these were usually things they wanted the system to do. In reality, in most cases it was something they didn’t know how to do, but that is getting ahead of the story. Each of those items was written on a single 5×8 inch index card.

Then we had them write their definition of “Solved” as in, “This problem is solved when ___.” and that had to be something that their Team Members could demonstrate back to the stakeholder / manager. We did it this way to make sure that the stakeholder had a clear criteria that, when met, they would verify that this was no longer a problem for them.

Part of that was to remove ambiguity. Part of it was for the stakeholder to accept accountability for the solution vs. saying later that they were not happy.

We then had the outside experts review the cards and accept the ones they would help with.

Now comes the interesting part.

We established a vertical column on the wall for the work of each outside expert.

The stakeholder / managers now had to get together and agree on the priority order among themselves. The stakeholders controlled the priority. The cards were taped to the wall in priority order, top to bottom.

What we had now was stakeholder agreement on:

  • What problems needed solutions.
  • What “solved” means in clear terms from the perspective of the stakeholder.
  • The priority sequence of work for each helping outside expert.

This meeting, by the way, wasn’t necessarily pretty. But they needed to work through the conflicts themselves. No outsider could do that except to impose something, which would reduce the ownership of the process.

All of this effort was to make sure we were focused on workflow, not simply software features. All solutions had to be in the form of what someone had to do in order to advance the work.

Daily Management

We used sticky dots to indicate the status of each card. The colors were based on nothing more than the box of stickers I could find at the local wally-world.

When the outside expert began work on a particular problem, they would put a pink dot on the card. This signaled to everyone that this problem was “in work.”

If they encountered any issues or delays, they would put a post-it on the card saying what question needed to be answered, or what was needed to resume work. This indicated “Stuck” status and what must be done to get it “Unstuck.”

They typically worked with the individual Team Members who had to use the system to do their work. Sometimes, though, they had to get answers from outside, or even facilitate modifications to the system.

When the outside expert believed the solution was Ready to demonstrate to the Stakeholder for buy-off, they put an orange dot on the card.

They also moved the card to another column on the wall under the stakeholder’s name. This established the work queue for the stakeholders. It was now their responsibility to initiate the next action. It was clear who was waiting for who.

Once the stakeholder was satisfied with the solution, they (and only they) applied a green “Verified / Complete” dot, and the card was moved to the “Completed Items” section of the wall. That showed we were making progress.

Process Guidelines

We also established agreement around workflow guidelines, a set of loose standards to strive for in a solution.

Staying Aligned

We established a daily standup every morning at 10:00.

The purpose was to align on status. It was NOT to solve problems. The meeting took 10 minutes or less, each person speaking for less than 60 seconds. This was the time to mention if you were blocked on making progress, or if you needed help.

To facilitate the structure we used a “talking stick” – something that was passed from person to person indicating it was their turn to talk, and that everyone else’s task was simply to listen. Question, discussions, possible solutions, etc. were, “I can help with that, let’s meet after” and the meeting was typically followed by quick 2-3 person huddles.

Transparency = Progress

By having everyone working toward a shared Truth that was displayed for all to see, there was no opportunity for speculation, wondering who was working on what, why progress was stuck.

Possible solutions were investigated, and results reported at the daily standup, AND on sticky notes on the cards.

Everyone know if the next step was their responsibility (because the card was on the wall under their name).

There were no action item reviews, no “I’ll have that done next week.” Every task was on a timeline of Today and Tomorrow.

At the same time, this process was a shock to the organizational culture which was pretty much the opposite of everything I just said.

Posted on

The (Futile) Search for the Perfect Model

Many years ago I worked with a senior manager. He was very savvy about continuous improvement and TPS – he had been engaging in the space for many years before the word “lean” entered the lexicon. He understood it at a deep systems level, saw how all of the pieces interacted into a coherent whole, and was incisive in his observations (in spite of his disarming demeanor that led one to (wrongly) conclude he only saw superficial things.)

Like many of us, though, he was searching for a concise way explain how it all works to others. I think his underlying assumption was something like, “If they could just understand the system, then they would adopt the principles.” That, then, translated to, “If I could just explain it well enough, they would understand it.”

What I saw was that he was continually trying to create the ideal model, diagram, that he could use to create this enlightenment.

It seems so simple. The foundational principles are simple. It is putting everything into consistent practice that is daunting. The organization, as a whole, has to learn to think differently.

I used to do the same thing – maybe because he was a bit of a mentor to me, and I was often a sounding board for his latest models. Those were incredibly [some superlative word here] conversations because I, like he, really enjoyed having my systems thinking pushed by someone willing to challenge it (and vice-versa).

In the end, though, I think this is a futile exercise. He and I could have that conversation because we both deeply understood what we were attempting to explain. But our understanding was gained through years of trying it and learning from whatever results we observed.

What I know today is the nature of the questions to ask, with the intent of provoking thought, but I am carrying the belief that my role is to help shape their journey through their own discovery of how it all works.

What has been your experience with the perfect model?

Posted on

Using the Coaching Kata Outside of the Improvement Kata

The client organization was working to incorporate the Toyota Kata mindset – scientific thinking / systematic problem solving – into their daily routines. This was early on in my journey as well, we were all learning.

The company had a structure for how they wanted to go about it. My role was to advise, coach, and be “the expert” in the room. After some initial awareness training and exercises, they set up storyboards and started trying to apply the concepts to actual challenges.

Learning groups of three would practice by doing round-robin coaching, with one in the role of the learner, one in the role of the coach, and one in the role of the 2nd coach.

I would spend about a week a month working with them to help them stay between the guard rails. As long as they were serious about their reflections, and kept the mindset that they were all working to learn something unfamiliar, it worked pretty well.

Then something really cool happened.

One of the managers related that he had used the Coaching Kata to work with one of his employees who was on a PIP.

For those who don’t know, PIP stands for “Performance Improvement Program” and, bluntly, is usually a pro-forma process that ends with the person being fired. The idea is that they are told what changes they must make in their behavior and given a deadline to make them. There are lots of ways to do this in ways that the victim, I mean subject, simply cannot succeed. In general, I consider the entire process disingenuous.

But that’s not what happened in this case. Rather than laying out a checklist of criteria, the manager started coaching.

He took his employee through “Grasping the Current Condition” and had him describe the behaviors(s) that were getting him into trouble. The employee was asked to begin keeping track of those things during his day.

Rather than telling him what must be changed, the manager asked the employee about a Target Condition: What are you working on now? What obstacles do you see that are in the way?

They met every day and reviewed what the employee intended to do, what he expected, what actually happened, and what he learned in the process. Every. Single. Day.

At the end of the 90 day process the guy had changed – to the point of being a totally different person at work. He kept his job, and became a real contributor to the team.

What really impressed me was that this was a novice coach, he had been exposed to Toyota Kata a few months before. And, honestly, it was a low-risk situation for practice (at least for the manager) – they had already written this employee off. But this manager, instead, made a commitment to do the hard work beyond just being critical and documenting every transgression. He had his employee doing the documenting and reflecting as he went.

What Was Different?

One of the ways we distinguish technical work from adaptive work is asking, “Who’s job is it?” In other words, who has to do the work?

While we are fond of saying things like, “If the student hasn’t learned, the teacher hasn’t taught,” the truth is that it is only the “student” who can learn, and learning requires an intrinsic motivation to do so. If the motivation isn’t intrinsic you may gain compliance, but that is the best you are going to do.

The coach in the story above created an environment where his Team Member was the one who had to understand the current condition, had to make decisions about what he wanted to change, and had to decide how he was going to try to make those changes.

It wasn’t a case of telling him what to do. There is a big difference between being told, “You need to…” and saying out loud, “I want to…” The coach gave his team member the opportunity to turn that “need to” into a “want to” and then provided structure for doing it.

At the same time, the coach was willing to put in the work to hold that structure in a way that created safe space for the team member to reflect on his own behavior and learn.

This Is the Improvement Kata

And finally – my title is misleading. This is the Improvement Kata. The only difference is in context. Rather than working to improve a process as an outside observer, the Team Member was working to improve the process of his own behavior. The fundamental steps are exactly the same:

  • Agree on the overall challenge.
  • Reach agreement on the current condition, including cause and effect.
  • Establish a concrete goal (Target Condition) and identify obstacles.
  • Engage in experiments, with discrete learning and feedback, to overcome the obstacles.

Have you had cases where you have used a similar process to help someone through real change? I’d love to hear about them.

(Click on the coaching cards below to download your own if you want.)

Posted on

Project Management is Daily Management at Menlo Innovations

Last fall I got to spend another week hanging out with the awesome team at Menlo Innovations in Ann Arbor. My last visit there was scheduled for early April 2020… but we probably all know what happened back then.

I am saying all of that because I am going to use their project management system as a benchmark in this article, and I am most assuredly not an unbiased observer. Maybe I was the first time I spent time there, but today they are friends.

What makes Menlo’s project management system stand out to me is captured in the title of this post: Their project management system and their daily management system are one-in-the-same. In retrospect, I can’t think of any other way that project management would be effective.

Getting Stuff Done

In spite of the wishes of some business leaders, there are only so many hours in a week, and there are only so many people available to get things done.

People are busy on stuff. Giving them more to do means something else is not going to get done. The very foundation of Menlo’s culture is making absolutely sure these conflicts are resolved by removing all ambiguity around what is the next most important thing at any given moment.

The other thing their process accomplishes is absolutely eliminating informal scope creep. Rich Sheridan calls this “hallway project management.” It sounds like this, “Hey Mark, I know you’re busy, but do you think you might be able to do this thing for me?” If I answer with an open “Yes,” I have just signed up to do something I may, or may not, have time for. It is now up to me to decide whether it is more important than other things I need to get done. Ultimately that means I have to decide what is not going to get done today.

Who makes that decision in your organization? The decision of what doesn’t get done? The decision of what gets done instead of working on the Main Thing? If that is left to the individual software developer, the individual design engineer, then does management later second-guess that decision? If so, this is the very opposite of “Respect for People.”

Another fundamental principle is that a person cannot actually work on more than one task at any given time. What we call “multitasking” is actually quick steps of starting, stopping, figuring out what task to work on next, starting that, etc. I can’t simultaneously work on this post and pay attention to someone else.

There is a non-trivial time and attention overhead involved every time continuity must be regained. That discontinuity also creates potential for quality issues like leaving things out.

Having a pile of tasks to work on all at once also makes it easy for a task to keep getting pushed off until the time left to do it is insufficient, and can conceal problems that get in the way of the work going smoothly

Menlo’s System

(At least my interpretation of their system.)

Like any project management system, Menlo’s up-front planning process breaks down the overall project into individual tasks, things that need to get done to make progress. They document those tasks on “Story Cards” which are physical cards that each represent a single feature to build into the software. One story card represents one task that advances the project.

One key feature of a story card is that there is little ambiguity. Adding to that, it is a core part of Menlo’s culture that if someone does encounter ambiguity the response is asking, not guessing.

Here is a “live” story card I photographed (with their permission) last fall:

Estimating Time

In the upper right corner of a story card is the estimate in hours. Both of the above examples happen to be 16 hours.

There are two critical keys here.

  1. The people who are going to do the work are the ones who make the estimates.
  2. Those estimates are not second-guessed or adjusted by others.

These estimates are based on, “Once we start on this, how long will it take to get it done.” The assumption is that there is no multi-tasking. This isn’t “When can I finish it.” It is “How much time must I spend to do it.” That may be different from what you are used to in your projects, but it is critical to make this work.

Estimates Are Wrong

Menlo generally does a pretty good job with this because they collect “actual actuals” as they are working. That gives them a good reference library of analogous work they have done in the past.

But, that being said, the estimate is made when the actual knowledge of what will be required is at its lowest. This is true for ANY time estimate, no matter where or who you are.

In many organizations a time estimate becomes a firm commitment and, worse, there are negative consequences if the task ends up taking longer than estimated. This inevitably leads to people padding the estimate, which then leads to the game of project managers cutting the time allotted. That does not happen at Menlo. Rich Sheridan tells the story of why that does not happen there far better than I can in this clip from a talk he gave some years ago. (Link here for the entire talk)

(As an aside, the first time I visited Menlo (for a week), I actually witnessed some fairly bad news get shared in the daily standup. The response was a quick huddle, lasting a couple of minutes, between the developers and the project manager immediately after the daily standup to discuss communication with the customer. Then everyone got back to work.)

Time Bounded Work Planning

Menlo’s basic project management cycle is a work week (typically 5 days). Menlo calls this an “iteration,” but the jargon doesn’t matter. Each week they:

  • Review the cards (tasks) that have been completed.
  • Decide with the customer what cards will be scheduled for the next week.

This is irrelevant to you at the moment, but Menlo’s developers work in pairs. One pair working for one week is the basic unit of capacity for planning purposes.

There are 32 productive hours in their week, plus 8 hours of overhead such as standing meetings, project support tasks, reviews with the customer. Thus, for one pair, they can schedule 32 hours worth of cards. No more.

The process they use is ludicrously simple. They call it “planning origami.”

For each pair of developers (what you might call a “resource” in traditional project management terms), there is a physical sheet that is sized to represent 32 hours.

Using photocopies of the story cards – the size of one card represents 16 hours.

If the card is estimated at 8 hours, they fold the card in half. A 4 hour card is folded in half again.

A 32 hour card is taped to a full sheet of paper that takes up the entire 32 hour space.

At Menlo the customer is the one making the decision about what gets done, and what does not get done, this week. THEY must choose the cards (with help from the Menlo, obviously) and fit them into the planning sheets which represent the resource capacity available to them.

If someone (the customer) insists on adding something, something else has to come off. The capacity is fixed. What gets done with that capacity is entirely up to the customer.

THIS IS THE ONLY WAY WORK GETS INTO THE “TO DO” QUEUE.

Thus, everyone knows what is expected to get done and, more importantly, what we are NOT going to work on this week.

Now… sometimes things go really well. The customer can prioritize “pull ahead” cards in case things go faster than expected (underrun the estimates), and there is additional capacity.

Daily Management

All of this was to set up the daily management system.

At the start of each week, the planned cards are placed, in order, on the “work authorization board” which is a tack board on the wall. The name is literal. This is the work that is authorized to be done this week.

But this is more than a task list. The work authorization board is a live reflection of what is actually happening vs. what was planned.

Each column on the board represents one unit of capacity, in their case one week of work for one programming pair team.

The developers work on the cards from top to bottom, in order.

When they start work on a card they put a yellow dot on it.

When they think they are done, they put an orange dot over the yellow dot. This signals the Quality Advocate to verify that the code accomplishes the intended function. If it passes, the card gets a green dot and the developers start on the next card.

If something is stopping progress, the card gets a red dot (and the Project Manager is informed).

Each day’s estimated work is clearly identified. There is a piece of yarn across the board that is moved down each day. Thus, if there are incomplete cards above the yarn, they are behind. If there are completed cards below the yarn, they are ahead.

Nobody has to ask a pair what they are working on. It is the card with the yellow dot on it. Status is clear to all.

If you were to visit Menlo with the above information, you would be able to grasp the status of all of their projects just by walking around the perimeter of the work area.

It. Is. That. Simple.

This process manages the project at a low level of tasks rather than more abstract “milestones.” Yes, there are milestones, but the level of management is every day. This allows the people who are doing to the work to tightly manage the progress of their work. The Project Manager is freed up from trying to keep track of everything simply because it is insanely easy for anyone to see the status in real-time during the course of any given week.

Accountability

There are two basic rules for accountability here. Rich goes through them in the video embedded above.

  1. The developers will never, ever, get any negative feedback, real or implied, for reporting that they blew an estimate and just discovered something is going to take a lot longer than they thought. This is accountability from management, which MUST come before asking for accountability from anyone else.
  2. The developers must inform the Project Manager immediately when they realize something will take longer than they thought.

Rule 2 will not work without Rule 1 because otherwise people would pad estimates, not report bad news, or otherwise try to protect themselves.

This measures TASKS, not milestone dates. If the tasks get done, we will hit the milestones. Missing a milestone is too late to recover.

There are still milestones, but they day-to-day work is reality, and milestones may well be adjusted to reflect reality as everyone learns more. Remember, project milestones are established when we know the LEAST about what work is actually entailed! That is true for ANY project management system.

Handling Emergent Work

If someone approaches a developer with a “can you just do this too” kind of task, the developers have a practiced, rehearsed, response: “Yes, absolutely. Let’s get it on a card and estimated so we can get it into the schedule.”

Thus, if something is going to be added, something else has to come off. The work authorization board only holds 32 hours of cards / week for each programming pair.

More Management Accountability

Management is accountable to stand behind the system. This, again, is demonstrating respect for people. Management refuses to override “just this time,” There is not time for “just one more little thing.”

Weekly Cadence

At the end of each week, the developers and the customer meet to review progress. Menlo typically has the customer demonstrate software features back to the developers. This gives the developers better feedback on whether or not the customer’s needs are being met. It also validates the design decisions about how intuitive the user interface is.

Then the Planning Game repeats.

So based on what is actually done and what is actually remaining, the weekly planning process is repeated for the next week.

Back to the Title: Project Management IS Daily Management

What this system does is tightly link project management to actual, daily, task execution. This is the key to making it work.

The only way to hit the long-term goals is to track execution at a level of granularity that allows you to see problems and delays while they are small enough to deal with, and have a robust system for actually dealing with them.

If your project tasks have vague definitions of “done” and estimates based on completion dates you are inviting additional work to creep in unnoticed.

Menlo’s system acknowledges the one thing that is hard: There is only so much capacity to get things done, and we must plan to that limitation.

Doing that requires management discipline to the process, and that generally is the hardest part.

Further Reading for Context

I highly recommend reading Rich Sheridan’s book Joy, Inc for the back-story of why it was important to create this process in the first place. (The link as an Amazon affiliate link, if you choose to buy the book I’ll get a small kickback, no cost to you.)

Question for YOU

How does your project management process stack up against this benchmark? Leave a comment – let’s get a discussion going, there are a couple of thousand of you out there subscribed to these posts.

Posted on

Follow-on thoughts (What I Missed!): Improvement Kata and DMAIC

Last week’s post about The Improvement Kata and DMAIC prompted some interesting discussions during the week, and I’d like to share some additional thoughts.

Before you read on, reflect a bit on what you think I totally missed. Does this post go where you expected it to? Does it confirm, or refute, your hypothesis about whether Mark was right or not?

What I Totally Missed!

I was too focused on the structures within the Improvement Kata and trying to draw lines between them and DMAIC.

Though we talk about the high-level structure of the Improvement Kata as steps, I think it may be more useful in this discussion to think of that structure as representing four phases* of any improvement or problem-solving effort.

Let’s take the term “Improvement Kata” out of the discussion because, right now, I am finding it distracting. Instead, let’s look at problem solving and improvement in general.

Phase 1:

Regardless of the specific approach we are using, we want to begin by clearly understanding what problem we are actually trying to solve, and what “solved” looks like.

This is the case whether I am looking to improve a process to new levels; whether I am trying to hit some kind of KPI goal; whether I am trying to understand the root cause of a problem; whether I am seeking to develop a new product; whether I am trying to influence someone’s decisions or behavior. Diving into proposing solutions without this understanding can easily turn into an exercise in frustration.

As soon as that desired outcome is understood, it’s a good idea to start tracking it against the goal so we can see what progress we are making.** I tend to default to a run chart for this.

Phase 2:

Once the problem is well defined, the next phase is gaining understanding of what is actually happening so that we can explain any gap between the current condition and the ultimate goal. Depending on the specific high-level problem, we may be trying to understand the relationship between the underlying process and its performance; the relationship between product design characteristics and product performance; the relationship between the user interface and errors; the relationship between the work culture and someone’s behavior; the relationship between the characteristics of whatever we are investigating and the phenomenon we are trying to influence.

We are working to understand the factors that drive the dependent variable of outcome.

Even as we gaining that underlying understanding, we have to be aware of hard-wired human nature to assign meaning to anything we are perceiving. It is really easy to fill in gaps and jump to conclusions. It is important to resist that temptation. Any conclusion being reached should trigger another question along the lines of, “What evidence do I actually have (or need)?” and prompt another level of inquiry.

Phase 3:

Even with my caveats above, the line between understanding what is happening and assigning meaning is more blurred than most practitioners would care to admit.

The formal process of making meaning is analysis. But as we go, it is very common that things we want to address will emerge. Sometimes the thing we need to address is another level understanding. My favorite quote from Steve Spear is, “The root cause of all problems is ignorance.” There is something we do not understand well enough.

At this (some?) point we can propose a hypothesis: If I change x, then I expect to improve (or learn more about) y.

Our analysis may find lower level, operational, metrics that are driving the outcome. For example, if the outcome is a level of productivity, we will probably find some combination of total cycle time and / or sources of delay that are driving output. Or quality yield. Whatever it is, we are starting to build a hypothesis of cause-and-effect between the outcome and the things that are driving it.

We set an intermediate goal based on that hypothesis, perhaps sketch out how the process needs to look, or changes in the product that would be required. Then we look with more focus and ask, “What is making it hard to actually do this?” and propose what problems we might have to solve to get there.

The key is that we (think we) know what we want to try changing, what impact we think that change will have, and what problems have to be solved to make that change actually happen (and, once we prove it works, sustain).

Phase 4:

Then we can pick off one of those problems and start to propose solutions – though it is also common to begin with a need to learn more about it. But those proposed solutions need to be tested. So we propose any action we intend to take as an experiment: We are going to _____, and we expect that ( something we will learn ). That learning may be more information, it may be simply learning that this idea works, doesn’t work, or works in a way we did not expect.

As thorough as we have been, we will likely discover that our information is incomplete. That doesn’t mean we have been sloppy. It means that as we narrow our focus or start making changes we are very likely to discover things that we didn’t see before. It is critically important that the goal of learning takes precedence over proving we are right.

That learning may take us into a different domain than the one we started in. For example, we might be working on something like process cycle time and run into something about the engineering design of the product itself that is an obstacle to improvement. The process is agnostic – it doesn’t respect organizational or functional boundaries. Nor does it respect organizational politics. It just tells you what is in the way of making the change you want to make.

“You don’t have to like your reality, but you have to deal with it.” – Brian Bakke

Back to the top.

Regardless of how the specific approach is structured, reality usually makes it iterative, often at multiple levels. Each change I make is going to have rippling effects on the overall process. Each change is going to bring out more understanding in the obstacles. Even after I have a solution I am pretty sure will work, trying to get it into place and stable offers up a new set of problems. You haven’t solved the problem until the solution is in place as the new routine.

So even if you reach that initial or intermediate goal, there is probably more work to do. Go back to the top, review your understanding of the problem, re-confirm your understanding of the current condition (you may have to dig in again if you have been narrowly focused), develop a cause-and-effect on the CURRENT condition (not just the one you started with), and start working toward that – always anchoring changes are you go.

My Revised Hypothesis

To summarize, although my last post was trying to map DMAIC into the Improvement Kata steps, what I now think I am proposing is that all approaches to problem solving and improvement that work follow a similar underlying pattern. The mechanics may be different, the jargon is certainly different, but at the end of the way we are all trying to take a scientific, fact driven approach to gaining deep understanding before just twiddling knobs and changing stuff.

The Other Thing I Totally Missed

It is really easy to fall into the trap of thinking that the Improvement Kata is just another structure for problem solving. That is, honestly, because when we look at the Improvement Kata as a stand-alone process, it is. That is the other mistake I made.

But the Improvement Kata is not intended to be stand-alone. It is one side of a larger structure.

The thing that Toyota Kata brings in is that coaching is an inherent, embedded, part of the process.

Intended Outcomes

Going back to the origin of Six Sigma, before there were different colors of “belts,” the role of the “Black Belt” was that of the professional problem solver. They would find (or be assigned) a major problem to solve, and go through the process defining it, measuring it, analyzing it, proposing and implementing solutions, and leaving the stakeholders with a “control plan.” Yes, that is an oversimplification, but that is also what I have seen in the wild at a number of companies with active Sigma programs.

So I think the focus here is on how an expert practitioner goes about “solving the problem.”

This legacy goes back a lot further than Six Sigma – with industrial processes we can go at least as far back as Frederick W. Taylor’s (and others) work over 100 years ago. The structure of TWI Job Methods (which was heavily influenced by Frank Gilbreth who was, in turn, an acolyte of Taylor though he had some philosophical differences) is that of a supervisor working largely on their own to streamline the work.

Regardless of whether it is DMAIC or something else (even traditional kaizen events), the classic approaches to improvement don’t have active, daily, coaching conversations built into their very structure. YES, it is absolutely possible to introduce them, but those structures are not there by design – except where they are.

In his early research on Toyota’s culture, Steve Spear talks about them “creating a community of scientists.” Their day-to-day process of improvement goes beyond just soliciting ideas from everyone. There are structures to the process design, and structures in the conversations about improvement, that facilitate becoming a better problem solver.

Toyota Kata is the result of Mike Rother’s research into the nature of those conversations, and then (most importantly!), how other companies might structure THEIR conversations to learn to do this. (Toyota does not follow Toyota Kata! Nor has anyone (who knew what they were talking about it) every claimed they did. Toyota’s intrinsic, unseen routines were parsed out and turned into visible routines that others can learn by practicing the basics.)

What is Toyota Kata For?

Maybe the real question is who is Toyota Kata for?

The way the Improvement Kata steps are usually described in books and training material (mine included, at least up to this point) are as things for the learner (the problem solver; the improver) to do. And, yes, they are… but

This is still (somewhat) controversial within the Toyota Kata community, but I am continuing to reinforce my belief that the structure and specifics of the Improvement Kata are more for the primary benefit of the coach, especially someone who is just developing those coaching skills.

“Why don’t you go do a kata on that?” is good a way to assure that this won’t work any better than to say, “Hey, go do an A3 on that.” Those assignments are neither delegating nor empowering. They are more akin to abdication of any responsibility to develop the skills of the person you are asking to solve the problem.

It is the coach who asks the improver to use those Starter Kata tools. Here is my working example – drawing from my skiing metaphor, but this is true of any coach who is working to improve someone’s technical skill.

A long, long, time ago I took up skiing again after a 15 year hiatus. I quickly remembered why I had stopped – it was a real struggle. This time I resolved to get better and signed up for a half-day lesson at Whistler, BC.

The first thing the instructor (coach) had us do was ski down the hill and cut some turns while she watched. She was evaluating each of us against her internal reference standard of a “perfect turn.” But rather than offering general critique she gave each of us a specific drill – one thing to practice – that would help us get to the next level. Not to perfection, but demonstrably better than we started.

My working hypothesis is that she had a repertoire of those drills in her mind, and based on where she found our “threshold of knowledge,” she pulled one of them and assigned it to us to practice. Mine was a drill that forced me to keep my upper body facing straight down the “fall line” as my hips pivoted underneath me. I can say that, after about an hour of practice, it worked. I became a much better skier that day.***

What about a someone who is just learning to be a ski instructor? I imagine that part of their learning is going to be a baseline of those drills. “If you see this, then assign that.” It is enough to get them started as they learn and develop their coaching skills.

I’m looking at the Starter Kata within the Improvement Kata (the detailed steps of Grasp the Current Condition, the structure of the storyboard, the obstacle parking lot, the experimenting record to name most of them) through the same lens.

Those are structures that a beginning coach can use effectively to help their learner through the framework of improving a process through the rigor of learning and experimenting with scientific structure.

The whole goal is to get someone who is reasonably competent at using those improvement tools up to speed as coach who is, in turn, working to develop someone else to use them effectively.

And there is the key divergence of Toyota Kata. It isn’t just about solving the problem. It is about getting problems solved in ways that develop peoples’ problem solving skills. This is how we create this problem-solving culture that is so elusive in most companies.

We can’t do that by just showing people good problem solving. We have to teach it deliberately in ways that allow people to practice, with correction, the process of problem solving.

But, as I said last week, the Improvement Kata is actually neither prescriptive nor proscriptive about any particular Starter Kata.

So, if you want to use the tools from Six Sigma and DMAIC instead, go for it. But make sure you are doing so with the goal of teaching them, vs. expecting immediate competence! Be ready to work side-by-side with your learner, or break the task into smaller bits. If they are left feeling incompetent or put on the spot they are less likely to return for more learning.

This is how you can move from the culture of the “Black Belt” expert practitioner toward a culture where everyone is applying the basic structure to everything. Sending people to “Green Belt” classes isn’t going to do that on its own. There has to be structured practice using the logical structure until it is habitual. It isn’t part of the culture until (nearly) everyone talks that way.

The Coaching Kata

The “5 Questions” of the Coaching Kata are designed to give a minimum viable framework as a launching point for someone who is learning to coach in order to develop people’s problem solving skills.

That’s the key: This isn’t about the boss knowing the technical solution. It is about learning the mindset behind teaching and coaching someone else through discovering the technical solution. This is the part that is adaptive – the coach is often the stakeholder, and they have to adjust their behavior, assumptions, and maybe even values about what is most important for this to work well.

If they “coach” by leading with, “Why don’t you just…?” or “Have you thought about…?” they are disguising direction as curiosity.

A skilled coach is going to be patiently persistent, questioning the learner through deeper and deeper understanding, often having them go back for more understanding in the process. The coach has to know the point at which the learner starts speculating, and ask about how we are going to verify or confirm that.

If the coach sees the understanding gap, they can pull from their repertoire of things for the learner can use to gain more knowledge. That might be “build a block diagram, but let’s go watch the process so we can see what is really happening.” It might be, “Great data points, can we put them on a run chart so we can better see the patterns?”

You can’t do this in a conference room – once the threshold of knowledge is reached, the only place to get more understanding is back where things are actually happening.

But the whole point here is that we are working to establish patterns of conversation within the organization. We are working to build problem solving capability so that more problems can be solved, closer to the point of origin. This is, I think, fundamentally different than a parachuting in a professional problems solver to do the heavy lifting.

As a Change Agent

IF you are working to shift the organization’s normal patterns toward collaborative problem solving (not everyone is), then I think a Change Agent is better served by understanding (Grasp the Current Condition!) the existing problem-solving structure, and then adapting any adjustments you are thinking about to minimize the change you are asking people to make. Make those adjustments as deliberate experiments. Prepare yourself to be surprised when people respond differently than you thought they would. You can make a lot of change over the long arc, but the right now change should be based on improving something that already exists.

Contrast that with the new “Lean Program” or “Now we are going to do DMAIC” that takes everyone through classes, uses alien words with pedantic definitions. The message buried in that approach is, “You aren’t competent, and I am, so let me show you what I know.” My name for that is “Creating resistance as you go.”

If I adapt whatever terms they use, and start asking intensely curious questions that nudge things away from rote application, and deeper into actually thinking about what they are seeing and learning, then I am leveraging what they already know and building on it.

Big difference.

*Yes, for Kata purists, we have the “Planning Phase” and “Execution” (or “Striving”) phase. I’m expanding the “Planning Phase” into three “phases” each corresponding to one IK step.

**There are a few use cases where the outcome is binary. The one that came to mind was an investigation into the cause of a single incident. There isn’t necessarily a continuous metric as they converge on root cause and countermeasures in that case. Still, the underlying logical structure of that investigation is going to follow the same general pattern I am outlining here.

***What I just realized as I was reviewing this for publication is that in the years past I had been taught the basics to get a beginner skier going, but had not been taught anything else. Thus, I had been trying to apply those beginner drills in more challenging situations – without that coaching that would have helped me progress through each limitation as I pushed my abilities. In skiing terms, wedge turns don’t work on intermediate / advanced slopes. At least not very well. I was stuck as a beginner trying to use beginner’s techniques in more advanced situations.

This is an important lesson for the Toyota Kata community. The starter kata are just that. There are real-world situations that require more sophisticated tools to uncover what is actually happening. We (as coaches) have to be prepared to help if (when) a learner gets in over their head.

Posted on

The Improvement Kata and DMAIC

I am going to start off by acknowledging that my background with Six Sigma and its other x-Sigma flavors is mostly anecdotal. I have read the books, I have worked as a Quality Director in a company with a lot of Six Sigma background, and I have done a lot of continuous improvement work with people who had Six Sigma context. I understand most of the mechanics, but I have never personally used the pure DMAIC process to do a “project.”

With those caveats out of the way – I’ve been having some rich conversations about bringing the Toyota Kata framework into a Six Sigma culture without making Kata something foreign and alien.

I actually kind of addressed this back in 2014 with this post. But the recent discussions have had me think about it more, and it’s been 10+ years, so let’s go through it again.

And finally, before I get into the meat, PLEASE comment and discuss. I’m not putting this out there as fact, but more as a possible hypothesis. I am here to learn. If enough people show interest, we can even set up a Zoom call and dig in more if you want.

The Improvement Kata

This part will go into a lot more depth than I originally intended to, but I felt the need to establish some kind of fundamental baseline of the Improvement Kata for the Six Sigma audience that might have come here thorough a search engine. That being said, this is a brief overview of what the Improvement Kata is about, not a comprehensive reference.

The Improvement Kata has four major steps. What follows is my interpretation which has been developed over the last 15 years of trying to apply them and teach others to do so.

These are steps that we coach the learner / improver through as they are trying to tackle a challenge.

Understand the Direction / Challenge

The key word here is understand. One way an organization with a strong culture of developing people does so is by challenging them to take on something that is going to stretch their capability. This is different from a traditional “stretch goal” that might have some kind of bonus attached to it, because this challenge comes from a leader / coach who is taking on the responsibility of making sure the improver succeeds. I think the best story of how this really works is in The Toyota Way of Lean Leadership by Jeff Liker and Gary Convis. (The book links in this post all take you to the Amazon listing. If you click through and buy something I get a small kickback at no cost to you that helps me run this site.)

Mike Rother’s first book, Learning to See describes the process of mapping a “value stream.” An outcome of that process is understanding the things that must change or improve for the Future State to work the way we have designed it (the “kaizen bursts”).

The value stream map clip on the right side of this picture is taken from the book. On the left is the conversation a manager / coach might have with the supervisor of the stamping area.

Toyota Kata Culture by Gerd Aulinger and Mike Rother offers a good example of this. This is a video of Gerd’s presentation to Kata School Cascadia on the process of developing problem-solving capacity and cascading goals.

There is an alternate form of this step, where it is up to the learner to determine their challenge. In a corporate world that is much less than ideal. It is appropriate, though, for people working with a coach to practice the Improvement Kata on a personal goal of some kind.

In either case, we want to end up with a way to know when we have met the challenge. We usually call this the outcome metric. I like to say that the outcome metric is what bridges between the Challenge and the Current Condition.

Once the outcome metric is understood, we should immediately start charting it. This is the first step of Grasp the Current Condition.

This example shows a hypothetical changeover time as the learner progresses through a few Target Conditions on their way to the ultimate 10 minute challenge.

Grasp the Current Condition

In this step we (the coach) guide the learner through a series of steps designed to help them gain understanding of what is actually happening in the process. We want to go beyond outcomes and results, and understand the dynamics of the system. Ultimately we want to develop a cause-and-effect understanding between the process itself and the results that we want to improve.

The starting point is to understand how we are going against the challenge, and then to understand what the customer needs and when they need it. Then we dig into understanding the “normal operating patterns” within the process itself.

It is really important here to exercise some discipline and resist the urge to start brainstorming ideas of things we can change. This can be challenging in an organization with an “action now” bias, and it is up to the coach to keep a gentle but firm foot on the brake pedal to keep things from careening down the mountain.

The goal of this step is to get enough information to make an informed choice about what we want to work on next. This is not necessarily exhaustive information about everything. One advantage of this approach is that by progressively narrowing the focus, we can keep the details relevant to the problem we are trying to solve right now.

Establish the Next Target Condition

This is a point of decision: What are we going to strive for next? Often the challenge is daunting. A Target Condition narrows the scope, and brings the timeline down to (usually) a couple of weeks. In the example run chart above, the Learner likely saw that the current changeovers were wildly inconsistent, and made a decision to go for stability first. That is usually a good place to begin. Until there is some stability it is hard to see the effect of future improvements.

Process Metrics

A key component (maybe THE key component) of a Target Condition is what we call a process metric. That is the thing we are actually working to change.

Often (almost always) the Challenge (which we are measuring through the Outcome Metric) is a dependent variable – something we cannot directly impact. For those of you who have not tired of sports analogies, this is the score of the game. In the words of a local celebrity sports commentator from the late 90s here in Seattle, “All you have to do to win every baseball game is score more runs than the other team.” True, but not actionable.

The process metric is usually an independent variable – something that is driving the outcome. In other words, something about the way the game is played. These are things we can affect.

I can’t just say “we are just going to make more units per shift” but I can work on improvements that impact the cycle time. I can’t just say “we are going to make the changeover 10 minutes,” but I can work on reducing the tasks that must be done while the machine is stopped.

Obstacles

Part of establishing a Target Condition is to ask some form of, “Why can’t we just do this now?” What we are looking for is Obstacles – the characteristics of the current process or environment that make it hard to change the process metric. In the language of TPS, those are problems. Another company I work with chooses to call them “issues.” The words matter a lot less than the understanding – these are the things we need to work on.

It is also common (normal?) for the initial obstacles to be more about things we need to understand better before proceeding. Our focus is narrowed now, and we may have to go back into Current Condition mode, just with finer granularity. “Where does the time actually go?”

Experiment Against Obstacles

Mike Rother’s book The Toyota Kata Practice Guide describes everything up to this point as the “Planning Phase,” and the actual process of experimenting (really LEARNING) as the “Execution Phase.” My awesome friend and amazing Kata Girl Geek, Gemma Jones, has started calling this the “Striving Phase” and I think that describes what we are doing much better.

(My original review of the Practice Guide from when it was first published is at this link. )

The simple fact is that we don’t know the answers or solutions that are going to get us there. They need to be discovered, to be learned. We learn by running experiments to test ideas, to get more information.

One key thing that distinguishes Toyota Kata from other similar descriptions of PDCA is that Toyota Kata makes the iteration explicit. This isn’t a one-and-done process.

An experiment is an action step the learner plans to take AND a prediction of what will be learned, or what impact that step will have on the process (metric).

Each experiment is followed by reflecting on what actually happened vs what was predicted and what was learned. That learning, in turn, informs the next step.

Iterate

The Improvement Kata is a process of nested iteration. We are iterating experiments against obstacles on the way to a Target Condition. Once a Target Condition is achieved (or the achieve by date reached without achieving the TC), first pause and reflect on what we have learned, then we iterate back through confirming our understanding of the challenge, grasping the current condition, and establishing the next target condition.

It is important to do this because we have been narrowly focused, and it is likely that the changes we have been making have had an effect on parts of the process we have not been explicitly working on. No matter what, the Current Condition has changed, so it is important to use up-to-date information to establish the next Target Condition.

Coaching

The whole point of this process is to solve the problem in a way that improves peoples’ problem solving skills. This is where the coach comes in.

Where the learner is working on the focus process of the challenge, the coach is working to improve the process of how the learner thinks. That is why we often give the challenge to someone who needs to grow into handling it.

The coach’s main job is to keep the learner between the guard rails of good scientific thinking. The structure of the “5 Questions” Coaching Kata is a starting place for the coach to develop the skills required to help others think more clearly.

Mapping to DMAIC

Another term we use in Toyota Kata world is “threshold of knowledge.” This is the boundary between, “things I actually know” and “things I might be speculating about.” That boundary notoriously easy to cross without knowing it. It is easy to start treating our assumptions as known facts.

I said all of that because I am talking about DMAIC, and I am way beyond my threshold of knowledge about the nuts and bolts. Feel free to correct and enlighten me where I have gotten something fundamentally wrong. However I am trying to keep this at the level of the principles, so I’m not going to go into the gritty details of statistical tools at all.

Define

As I understand it, the main goal of the Define step is to be clear about the problem we are actually trying to solve. I do not see a fundamental difference between this step and the “Understand the Direction / Challenge” step of the Improvement Kata. I believe both should give us a clear outcome gap we are trying to close.

Measure

Right away the word “measure” can impose a limit on thinking. I believe there is a lot more involved than just numbers. Though the tools may be different, Measure maps pretty will in intent to the Improvement Kata step of Grasp the Current Condition.

The Voice of the Customer step examines the same things – what does the customer need, and when do they need it. Since Six Sigma has roots in the Quality Movement, there may be more depth here, which is awesome. The Improvement Kata is a starting point, and is not prescriptive (or proscriptive) of any tool or technique that helps us gain better understanding. The goal is the same.

We are still mapping the process, and working hard to gain understanding of where problems occur (for example).

Statistical tools can (sometimes) help gain more understanding. For example, the classic SPC chart can give us insight into whether a particular part of the process is operating the way we should expect it to (“common cause variation”) or if it is being continuously disrupted by outside forces and true anomalies (“special cause variation”).

That being said, MY caution here is that statistical tools can often become a “wrench in search of a screw to pound” – knowing them is not equivalent to needing them for any particular problem.

Analyze

Now we are looking at what we have learned and making decisions about where to go first (or next). DMAIC is not explicitly iterative, put in practice I think it is.

The outcome of my analysis is analogous to a Target Condition. Instead of obstacles, we have things like sources of variation, but those are still the problems we need to better understand and solve.

Improve

If I am doing this well, then I am running experiments. I have ideas, but I have to test them to see if they are worth pursuing, and then if they actually have the impact on the process that I expect them to.

So this isn’t just brainstorm a list of action items and implement them.

If I were coaching a Six Sigma minded person, instead of asking about “obstacles” I might ask, “What sources of variation are keeping you from reaching your Target Condition, and which one are you addressing now?”

Improve maps very well to the “Experiment Against Obstacles” step of the Improvement Kata.

Control

It is interesting (to me) that this is listed as a separate, discrete step. But “standardize” as a separate step is pretty common in a lot of “lean” circles. I doesn’t work that way.

The complaint I often hear from change agents is that “management” (or “they”) “are not supporting the changes.” What exactly does that mean? What, exactly, do you expect to be different? In other words, what changes have you made to the daily management system itself?

Let’s look at the goal of that statistical control chart. Yes, it is telling us if the process is “in control” or “not in control.” But what happens if it isn’t? A data point goes outside the control limits; or the mean actual mean has shifted to a point above the historic mean. What do you expect to happen now?

All the chart does is give us information, it doesn’t actually “control” anything. It tells us when intervention is appropriate.

All of the so-called lean tools do this. They are instruments that tell you if your process is operating as it should, or if something else is happening.

But unless that information triggers immediate intervention to learn more, correct back to the standard condition, and start to understand what we need to do to prevent that problem from recurring, then the process will inevitably erode. “You can’t just decide the freezer is cold enough and then unplug it.” You have to keep putting some amount of energy into the system just to maintain it.

Control, then, is a process, just like any other. This is the heart of your shop floor daily management system. If done well, then every day things run a little smoother. If not, well, they don’t.

So “control” is really part of “improve.” If they aren’t done in rapid iteration then you are unlikely to hold any gains.

A saying from one of my ex-Toyota coworkers was “No problem is a BIG problem.” If things are running smoothly it doesn’t mean there are no problems. It means your system is blind to them. Time to investigate further.

Conclusion

OK, I’m going to resist the temptation to go off on deep dive tangents and stop here. This is already too long.

Hopefully this creates some discussion. I’d love to hear from you.

Posted on

Kata School Cascadia Discussion: The Experiment Record

Following last week’s post about the Toyota Kata Experiment Record we did a bit of a deep dive on the same topic on the weekly Friday Zoom call.

I think the discussion was pretty rich – though rich discussions happen frequently in these sessions. If you weren’t there, and aren’t on the mail list for the recordings, here’s a (lightly edited) sample for you. FOMO Warning!

If you’d like to participate or lurk-and-listen, then hop over to https://kata-school-cascadia.org and register.

The same video is also up on our YouTube channel.

This week (Jan 24) we are going to take a deeper look at Obstacles and the Obstacle Parking Lot. Stay tuned.

Posted on

Toyota Kata: From Kaizen Newspaper to Experimenting / Learning Record

In a traditional kaizen event there is usually some kind of todo list for keeping track of progress implementing the ideas of the team. A common name for this form is “Kaizen Newspaper.” The below example is pretty typical. This is a real one from the early 2000’s.

Generic kaizen newspaper showing What, Who, By When, Status

This form reflects a bias in western (certainly USA) business to focus on getting stuff done. I think it might be helpful to reflect a bit on the assumptions that are built in to this structure.

One of my favorite quotes is from Grace Ng: “All customers have problems, all problems have solutions. But not all solutions have problems, and not all problems have customers.”

In the context of this form, the “What” or “Action Step” is usually a solution. We are going to do something. And once the “What” is decided, then the rest falls into place- Who is going to do it, by when are they going to get it done, and what is the current status? And it is all to easy to get pulled into the implement vortex without ever thinking about “Why?” are we doing this – what are we trying to accomplish? How will we know we have accomplished it?

This is also a typical structure for a management staff meeting, and even discussions about strategy – they devolve into “What are we going to do?” and often skip over “Why are we doing it?” In other words, “What problem are you actually trying to solve?”

The “Progress Wheel” tracking percent complete implies an assumption that there are multiple steps involved, and implies a conversation about what those steps are as that wheel is filled in. The quality of that conversation depends on the skill of the coaching and facilitation.

The “By When” or “Due Date” implies that days will pass before we expect this action to be completed. It might be tomorrow, but often is not in practice.

This means that we expect that we wouldn’t get everything done that week. These newspaper items frequently carry over and are supposed to get done as follow-up work after the kaizen week is over. In practice, these things often fall victim to the daily whirlwind and languish. The “newspaper” is now more of an archive. It isn’t about today anymore.

Here is form from another company in the same era. As an aside, this company added “Complexity” to their list of wastes, and perhaps we can see some of that reflected here. But it takes a step in the right direction by adding “Problem to be solved” and, through the “Target Reference” block tries to tie it back to an intended result. It also has a column for “Results” on the far right.

What neither of these forms does, though, is ask “What result do we expect? They depend on skilled facilitation and coaching to ask that question as the team is proposing the idea. One of the challenges we often face (again, in the West and especially the USA) is with our focus on action we don’t default to asking that question.

One exception I experienced in May 2001 was a Shingijutsu consultant (and I don’t remember who it was, unfortunately) who had us modify our kaizen newspaper that week to add a column that captured the cycle time we expected to save as a result of implementing that step. (I know the date because I did the modification on the original file and still have it in my archives.)

The idea was to make sure that we were implementing enough changes to deliver the cycle time target.

What it didn’t do, though, was capture the actual cycle time savings from the action.

What Are We Trying to Achieve?

A common assumption in many continuous improvement efforts is that if people participate in enough of these kaizen events they will experience a mindset shift. The challenge here is that the events themselves are usually focused more on results than on explicitly teaching and practicing the mindset1.

Don’t get me wrong – results are important, especially if you want to keep doing this. It is rare that any organization has infinite (or any!) patience for a lot of discussions around history, hypotheticals, or theory.

That means we have to actually solve real problems. We have to get stuff done. We have to at least look like there is a bias toward action if we want to survive as change agents in most organizations. The key is to solve the problems in ways that develop people’s problem solving skills.

That means making the mindset we want to teach more explicit.

This is the whole point of Toyota Kata.

Build the Coaching Into the Process

A highly skilled coach or facilitator brings teaching the problem solving / scientific mindset into the process, regardless of the forms and structure being used. But we can make this easier on both the coaches and the learners with adjustments to the structure.

While all of the artifacts of Toyota Kata are designed to do this, I want to avoid my tendency for scope creep and stay focused on one (really two) of them that fulfill the intended purpose of the Kaizen Newspaper in a way that develops peoples problem solving skills.

The Learning Record (aka the Experiment Record aka the PDCA Cycles Record aka the PDSA Cycles Record)

I call this form the “powered gear” that drives the entire process. Let’s look at the structure2. The form is structured in a way that turns action items into hypothesis tests.

The first, obvious, thing is that we aren’t just saying what we are going to do and by when. Each action, which we are calling a Step or an Experiment, has a specific predicted result or outcome. Separating the step being taken (the action) from the intended or predicted result helps people distinguish between the two. Allow me to elaborate.

I often see a result or outcome being listed as something that we are going to do. This can go as far as something like “Increase gross margin by 3%” as an action to take.

But that is an outcome (and an indirect outcome at that). It doesn’t say what we are actually going to do that we predict will produce that outcome.

One (the action) is cause. The other (the result) is the effect. Distinguishing between cause and effect is one of the core fundamentals we are trying to teach people who are making improvements or changes.

Explicitly separating what we are going to do from the result we expect helps people practice this mode of thinking. But the coach has to be prepared to ask good questions rather than just buying whatever is written in the boxes.

Taking this a step further, I have sometimes found it helpful to ask a learner to first decide what they want to learn, or the effect they are trying to achieve and write that in Box #2 first. THEN I ask, “What action are you going to take that you think will [ read what is in Box 2 ] ?” and write that action in Box #1.

I can also ask the learner to say, “I intend to [ read what is in Box #1 ] in order to [ read what is in Box #2].” For example, “I intend to rearrange the end of Alice’s work path in order to cut 3 seconds of walking from her cycle time.” If that sentence doesn’t make grammatical or logical sense, there is more thinking to do.

In general (this is a rule of thumb, not a hard rule) there are three kinds of actions that get listed here.

  1. A straight up hypothesis test – make a change with a predicted effect on the process, like the example with Alice’s work cycle above.
  2. Gathering more information – for example getting more detailed information about the current state of part of the process. This might be something like breaking down the cycle time of an individual operator into discrete steps. This could be where I learned Alice has 4 seconds of walking back to the start.
  3. Trying something in order to learn. For example, we have a target process that we can run, but we don’t have a good idea what the obstacles might be. The experiment would be something like “Run to the target process and carefully observe what actually happens” and the expected outcome would be “To learn what the obstacles are.” This is particularly effective for finding sources of process variation.

In general, and this is also more of a guideline, I want to see enough detail that we could give the sheet to someone familiar with the process and they could carry out the experiment from what was written. (This is just a thought experiment! DON’T actually do this. I can confidently predict that you’ll end up repeating the experiment because “what actually happened” won’t be what you thought – though that is an experiment in communication in its own right.)

The “Review / Coaching” line (yellow on this form) is the gate. We don’t cross that line until we have the coaching conversation, just to make sure everything I mentioned above is tight.

All we have at this point, of course, is a hypothesis. “If I do what is written in Box #1, I predict I will see (or learn) what is in Box #2.” Now we have to test that hypothesis. That is why we call this an experiment.

WAIT A MINUTE! Back up! What Obstacle Are You Addressing?

When you are running experiments, you are working to overcome some obstacle that is between you and your goal – your target condition. You want the process to operate in a new way (the target condition), but for [reasons] it can’t. Those reasons are obstacles.

This is different than the typical approach of just brainstorming a bunch of things to do and implementing them. We are targeting a specific way of operating (which is often an intermediate stage on the way to something more challenging).

We want our learner / improver to have an obstacle, problem, unknown of some kind, in mind. It may take – it usually takes – more than one experiment to learn enough to overcome that obstacle and move on to the next.

Address one obstacle at a time.

The Experimenting Record provides structure to reinforce this mindset by having the improver write the specific obstacle or problem in the space on the upper left corner before engaging any experiments. If they don’t know what the obstacles are, then write that as the obstacle, try to run to the new work pattern in order to learn.

“What problem are we actually trying to solve?” is a question that can often reign in an otherwise chaotic discussion about what to do.

The upper right corner has a space for a “process metric.” Without going off on another deep tangent, this is the attribute of the process result that we are trying to affect. The target condition should include a target value for the process metric so we can tell if we are actually making progress toward the target condition.

The process metric can be something like the cycle time of a particular operator; the minutes of exercise I am trying to achieve every day; the amount of variation in a process parameter we are trying to control. These are all things that we can immediately, directly, measurably affect by changing the process in some way.

Why did I address this part of the form second when it should be done first? Because it is very common to bleep over this part and just start writing experiments only to have the effort get diffused later.

Maybe my little digression was unexpected which might result in you remembering it a little better.

Now – Run Your Experiment

In the classic Plan-Do-Check-Act cycle we discuss “Do” and “Check” as sequential activities. In practice they are simultaneous, or nearly so. You should verify that the action you are taking is actually the action you planned to take. CHECK that your DO matches your PLAN.

If you ended up doing something different, you want to make a note of that, because you likely can’t say your plan didn’t work if you didn’t actually carry it out. What ACTUALLY happened? What did you experience? What did you see? What result did you actually get?

The things that we want to see written in Block #3 of the Experiment Record are objective facts. Please don’t just repeat what was in Block #1 in past tense. As a coach I want to see what you actually did as well as the actual outcome vs the planned outcome. And this includes outcomes that you didn’t anticipate. Sometimes those are good surprises – collateral benefit. Sometimes you learn that you need to pivot to a different idea.

Block #4 is subjective. What did you actually learn? There is usually more to this than what was simply in Block #2. This is also a good time to look at your obstacle list and make additions, deletions, and edits. Those are also things that you learned.

After Your Experiment

If you have had an impact on the current condition, update that. As I mentioned above, scrub your obstacle list and make sure it is up to date.

Have you achieved your target condition? If yes, awesome. Time to do a summary reflection, take a deeper look at your current condition, and establish a new target condition with new obstacles. (Same thing if you have reached the “achieve by date” without hitting the target condition.)3

If not, are you still addressing the same obstacle? If yes, then move to the next line on the experimenting record and fill in Block #1 and Block #2 for your next experiment.

In all cases, let what you have learned inform your next step. Notice how this is different than blindly executing a complex action item.

If you are addressing a new or different obstacle, then same thing, but please start a new form.

Why So Much Detail?

Our results-as-action-item corporate culture has a heavy bias to glossing over the details, and they are often not discussed or thought through. An action item might have a due date that is weeks in the future, and other than saying “It’s on track” not much will be discussed.

The Experiment Record is designed to have a small step every day (or nearly every day), discuss what was learned, and allow that to inform the next step so we aren’t blindly executing into something that has become irrelevant.

To be clear, a skilled, experienced coach can bring all of these questions out with a team using the traditional kaizen newspaper. The purpose of the Experiment Record is to make it easier for everyone, the coach included, to dig deeper into the kind of thinking we are trying to teach. It makes these questions explicit rather than relying on the experience and skill of the coach or facilitator.

Honestly, having these things explicit also establishes an expectation that the coach is going to ask about them. When a coach or facilitator starts pushing for more detail within the structure of a process that is overtly superficial they can, well, come across as a jerk. We call it “Socratic Teaching” but we have to remember what happened to Socrates. Better to have a process that makes the structure transparent to everyone.

Even outside of the Toyota Kata ecosystem, this process can bring a cadence of accountability to things as mundane as staff or project status meetings. The key is to not allow any step to go beyond the next scheduled meeting. “I can have that done in four weeks” becomes “What will we do before next Wednesday?” and “What result do we anticipate from taking that step?”

Back to the Kaizen Event

Try this experiment in your next kaizen event.

Throw away your kaizen newspaper.

Ask your team to list the problems that have to be overcome to achieve the goal for the week (which is really a target condition). Put those on a seperate sheet. You can use the Toyota Kata “Obstacle Parking Lot” but that is really just jargon. Call the problems whatever you want – just make sure they are problems and NOT actions to take, or things to implement. What is it about the process that makes it hard to change to the new way? What kind of issues come up that prevent the new way from working smoothly?

Then pick off one of those problems and start a rapid cadence of learning using the Experiment Record format. Keep those cycles quick. Can you do one every 15 or 20 minutes? Probably. The first experiment may well just be a simulation of sorts to learn if this idea is even worth pursuing. Cardboard, tape, holding things by hand to represent a fixture.

If you have a large team you might be tempted to work on more than one of these problems at a time. OK – but first convince me there won’t be any cross-talk between those problems or those experiments. It is really hard to learn when the conditions are changing under your feet because someone else is tugging on the other end of the rope.

At each major step you want to work to stabilize what you have before making the next change. Do this quickly, but incrementally. Doing otherwise is leaving a shaky process behind, and this is disrespectful to the people who have to deal with the aftermath.

At the end of the event celebrate, not so much the results, but what you have learned about making improvements. Wherever you are is where you should be.

Come Monday morning – here is the cool part – don’t stop. Maybe you only run one experiment a day vs. three or four every hour, but keep moving. Keep those coaching cycles running at least once a day.

Congratulations – you are now solving problems in a way that develops people’s problem solving skills.

What’s Next?

Did you find this helpful? Would you like me to go into similar depth on other pieces of the Improvement Kata, such as obstacles, process vs. outcome metrics, etc? Is there something specific you would like me to cover?

Leave a comment and let me know.

1 Another challenge is that most leaders only participate in these events a couple of times a year. The question, then, is what do they practice the other 48 weeks?

2 There are a lot of variations of this form, but those variations tend to be limited to phraseology. The fundamental structure remains the same.

3In a week long kaizen event you should really only have a single target condition to reach by the end of the week – if it is planned well – another deep digression I could go into.

Posted on

The Value of a Little Bit of Information

Shortly after 9am last Friday my home Internet went down. After doing my own troubleshooting, I was pretty certain it wasn’t anything in my control, so I called the technical support line of my provider.

The person on the other end (who I later in this saga learned was in the Philippines) was obviously reading a script as we went through reporting which blinkenlights were working (and not working) on the interface box (ONT – Optical Network Termination), doing a power cycle of same, “While ..we.. are.. waiting,.. Mark,.. how.. is.. the.. weather.. there.. in.. Everett?”

Whatever remote diagnostics they ran apparently didn’t detect anything out of norm with their system, and he said they would send a technician out “between one and five pm.”

Around 3pm I got a call from the technician, and went outside to meet him. He was still in his van in my driveway, obviously looking at something. When he looked up and saw me, he said, “I just figured out what the problem is. Does your interface box have a steady green power light, with the optical light blinking slowly?” Yes it does.

He showed me his notes. He had been sent to a number of customers with similar problems, and had connected the pattern to a couple of common hubs. My hub, apparently, was hub 1004. There was a failure somewhere upstream of those hubs. He left without needing to see anything in my house.

Fast forward a few hours and things weren’t resolved, so I was kind of wanting to know what was going on.

I got on the online chat (via my phone) with the provider, confirmed my account, and just as they wanted to run another (futile) diagnostic, I interrupted the script:

The tech that was sent out here said the problem was upline of hub 1004, do you know what the problem is yet?

Long pause, then I got more information:

The card in PON #1 has been replaced, they are still working in the cards in PON #3 and #4.

I thanked them for the update.

A quick online search (on my phone, no Internet, remember?) told me that a PON is a Passive Optical Network, so they were probably talking about the Optical Line Terminal (OLT). (Again, a little bit of knowledge can be leveraged into more.)

Illustration by user Riick from https://commons.wikimedia.org/wiki/File:PON_vs_AON.png

By leveraging a bit of information that they didn’t expect me to know (that the problem was upline of Hub 1004), I got more information. Now, in this case, that information was not actionable (to me), but it demonstrates how knowing a bit of accurate information can help you get more. If I were working to reverse engineer their network architecture I now have a working hypothesis that Hub 1004 is not part of PON #1 (since that has been fixed, and my Internet is still down), and is downline in either PON #3 or #4.1

What Does This Have To Do With Continuous Improvement Change Agents?

I’m glad you asked. Sometimes, probably most of the time, we are entering situations where we don’t have a great deal of information. And sometimes we encounter situations where people are not particularly forthcoming to our initial curiosity.

Sometimes asking about something specific will invite someone to open up and share more than they might have from a general generic “Can you tell me about this?” question.

If you show you know nothing, it is easier to dismiss you than it is if you show you know something.

This general technique is widely used in the world of intelligence gathering and law enforcement investigations, but it does not have to be deceptive. Having a little bit of information can open up the conversation because it simply shows you have already made an effort to learn.

“I think this process works like this [explain how you understand it]. Is there anything I am getting wrong?” invites the expert to correct your misconceptions rather than having to tediously explain everything from the beginning.

Each additional bit of information can be used to ask a deepening question as you extend your threshold of knowledge.

(Thanks to Craig for adding the following) Don’t be afraid to get it wrong when describing a process. In fact, people often feel more comfortable correcting you than confirming vague guesses. When someone says “no” they can feel more in control and are more likely to offer corrections or additional insights. As a change agent, that’s exactly the kind of dialogue you want.2

At some point, of course, you will likely bump into the threshold of knowledge for the entire organization – the point beyond which nobody really understands how it works. That can be our next obstacle, and the discussion can turn to “What do we need to learn, and what must we do to learn it?”

  1. Ultimately my Internet was down for about 32 hours, which is much longer than I would have anticipated. I also learned that the call centers get no information at all about estimated time to repair. It isn’t that they won’t say, it is that they are not told.

    I will not divulge my ISP in this case since, with this one exception, we have been very happy with the service we get. That being said, if your Google-Fu is good, you probably can leverage the information in this article into figuring out who it is.
    ↩︎
  2. This is also a good example of “Cunningham’s Law”: “The best way to get the right answer on the Internet is not to ask a question; it’s to post the wrong answer.” If you are willing to be corrected, you can gain a lot of insight. ↩︎
Posted on

Is Your Problem Technical or Adaptive?

Back in the early 1990s I was an avid skier, putting in 40+ days on the slopes every season. I was part of a group that did days in local (to Seattle) ski areas; annual trips to Whistler, BC (my favorite place); Mount Hood and Mount Bachelor in Oregon; and a semi-fateful trip to Red Mountain in Trail, British Columbia in March of 1993. Red Mountain is known for its challenging terrain.

March 13, 1993: Mark and the Red Mountain ski patrol

I was a pretty good skier, though not an expert. There were places where I would be in over my head. And I followed some expert skier friends into one of those places. To cut to the chase, I ended up learning how to spell “anterior cruciate ligament” and later on how to spell “arthroscope.”

My torn ACL was a technical problem, but not one I was (or am) qualified to fix. I outsourced the solution to a technical expert – an orthopedic surgeon and his team. They did a great job. Today that knee is better than the original equipment.

But the surgical, technical repair did not address the root cause of the problem. I could not outsource that. The work was mine, and mine alone, to do. Dealing with the root cause required me to change my own behavior. I had a few choices:

  • I could give up skiing entirely. Nope, too much fun.
  • I could take fewer risks, though that would mean plateauing my own learning.
  • I could work deliberately* to become a better skier so I can take on more challenging terrain with reduced risk of serious injury.**

No matter which of those courses of action I chose, they are not things I can assign to someone else to do for me. I have to do the work myself. Solving the problem requires a change in my own behavior.

I believe it was Ron Heifetz at Harvard who coined the term “adaptive leadership” to describe leading for behavior changes vs. simply guiding technical solutions. If you are a change agent, you are (or need to be) engaging in adaptive leadership.

In the context of continuous improvement, we are talking about the culture change that has to accompany any technical implementations if they are to stick for more than a few months.

Trying Technical Solutions on Adaptive Problems

An organization had a culture of working around their ERP / MRP system. If production fell behind, they extended lead times in the system (which is the worst thing you can do in this case). They would schedule “hot” orders in the past to force them to the top of the queue, driving material shortages for later orders – repeating the cycle.

They all believed that the computer system itself wasn’t up to the task of managing their “complex requirements.” (Which actually weren’t that complex at all – everyone seems to think their production portfolio is more complicated than everyone else’s.)

The new system, though, would fix all of this.

When the new system went into place, though, things got worse. Much worse. They doubled down on the same things they had done in the past, which made things worse again.

This wasn’t a problem with the computer systems. It was a problem with the way the team members worked together, a problem with their understanding of how their computer systems responded to their manipulations. It was a problem that no changes to the I.T. systems could solve.

Not surprisingly the same organization had tried kanban in the past. And not surprisingly they had worked around the system to “solve” perceived problems, and not surprisingly they had blamed the system for the failures.

It would not matter what technical system they had, their results would ultimately be shortages, expediting, scrambling to rush late shipments out the door. It was not the technical systems that produced those results, it was their behavior.

What Kind of Change Do You Have to Make?

This is adapted from material published by the Kansas Leadership Center, see more below under Further Information and Reading. The expansion, examples and explanations are my interpretation.

What kind of problem are you facing?

Is the problem clearly defined (like my torn ACL)? Or do you have to begin work to learn what actual problem(s) you are facing? If the later, you are dealing with adaptive, culture change work.

What kind of solution can be applied?

If there is a clear solution, or one can be researched, then you are dealing with a technical problem. But if the solution must be learned, then more likely it is adaptive. One key indicator – if you have put in a technical solution (like “standard work” or “5S” for example), but then seen it erode, then you are probably in adaptive territory. You have to learn what unseen factors are driving how people respond.

What kind of work is involved to apply the solution?

If you can just implement, like buying or upgrading a machine, then you are in technical territory. But if you have to diagnose, experiment, learn about things like the organizational dynamics then you are dealing with people’s behavior – an adaptive problem. Like above, I have seen many cases where a technical solution was implemented only to have that surface all kinds of adaptive and leadership issues. A new ERP system is a prime example. The software is the easy part. Beware of someone selling a “solution” by the way.

Whose Work Is It?

Even though this is a header, I bolded it, because this is The Critical Question. If technical experts or authority can just tell you what to do, then it is a technical problem.

But most meaningful change requires the stakeholders – the people responsible for the system and the results – to actually do the work themselves. This is the difference between fixing my torn ACL and the work I had to do.

In other words, if you put in “lean tools” (or complete a “black belt project”) only to see the results quickly eroding, then the technical tools, no matter how well you see them work elsewhere, are not going to help you. The organizations where you see them working have fundamentally different systems of leadership, and that is where the change must occur of the tools are going to work as promised.

What Timeline Should You Expect?

Technical solutions can be put in quickly. Anyone who has been though a classic “kaizen event” knows this. But changing people’s default thinking and behavior takes time because it takes practice and correction. And the default thinking and behavior is what created the technical systems you are trying to adjust. Eventually your kaizen blitz rocket runs out of fuel, and things fall back to Earth because gravity pulls them there.

What Are Your Expectations?

This is a tricky one. The whole reason to do any of this is to change results, change outcomes in some way. Technical solutions can do that pretty directly.

But when you are in adaptive territory, learning you way in, then you need to celebrate making progress and learn to trust the process – the results will come. Impatience does not serve us here.

Required Mindset

For technical solutions, skill and confidence are enough. You can hire someone with that. But if you are seeking to make real, meaningful change then you are better served with curiosity.

Further Information and Reading

If you want to learn more about Adaptive Leadership, here are some sources you can start with. Of course you can also leave a comment or click on “Contact Mark” in the right sidebar and ask me if any of this is interesting to you.

(Books are Amazon affiliate links, I get a small kickback at no cost to you if you buy through them.)

Best starter book: Your Leadership Edge by Ed O’Malley. This is also the text for a course by the same name taught by the Kansas Leadership Center.

Teaching Leadership by Chris Green and Julia Fabris McBride, who are also affiliated with the KLC, is more technical and more advanced. It is targeted more at people who understand the basics, and have practiced a bit, who now want to begin to coach others.

The Practice of Adaptive Leadership by Ron Heifetz, Marty Linsky and Alexander Grashow is what I would call the baseline reference. The books above are geared toward developing your practice. This book is more about the underlying principles. It is also a heavier read, just so you know.

*Note the word deliberately. This meant taking lessons specifically targeting my skill gap. Simply putting in more hours skiing would not be deliberate practice, I would simply be reinforcing the habits I already had. In other words – get a coach.

**Some of my more astute – probably younger – readers may question my judgement about not wearing a helmet. At that time, helmets were pretty uncommon for recreational skiing. Thankfully that has changed in more recent times. And yes, today I wear one.