Sunday, February 23, 2014

The Big Batch Theory

Don't you love those moments when you make a connection between ideas that on the surface have nothing to do with one another?    I hate the term "aha moment" but it is appropriate in this case, and it does make me think of this hilarious Eddie Murphy moment (language slightly NSFW):

Okay, so anyway, there's an aha moment insight to be gained from analyzing the batch sizes of different types of work we do and discussing how lean principles such as pull, just-in-time, one-by-one flow, etc. can help us improve our work.  The following paragraphs will dive into three different work scenarios:  1) Big-Batch Production, 2) Learning in Big Batches), and 3) Big-Batch Root Cause Analysis.  Here goes...

1) Big-Batch Production

aka the "Yeah-I-Learned-That-In-Lean 101" example

This is the good old-fashioned example of the Welding Dept. in Ohio producing 10,000 widgets in one huge batch and shipping them to the Assembly Dept. in Michigan, who finds that the whole batch is defective because of one inaccurate measurement or whatever.

The well-understood principle at play here is that we shouldn't push big batches because it obfuscates the connection between customer demand and production.  It's the waste of overproduction, which in turn leads to myriad other wastes:  whole batches of undetected defects, out-of-control inventory, etc.  Instead of this big-batch push approach, we should strive for a target condition whereby downstream processes can pull from upstream processes in pursuit of a True North of perfect one-by-one just-in-time flow that perfectly matches customer demand with production supply.

Those ideas are part of the lean canon; no need to rehash them further.  However, there are so many other scenarios to which we could apply the same logic and benefit from the same lessons learned.  Unfortunately, based on my observations in healthcare anyway, we frequently fail to apply these lean principles to other types of work.  That's what I'll explore in the next two examples...

2) Learning in Big Batches

aka the "Intuitive-When-You-Think-About-It" example

So, applying the aforementioned lean principles of "pull, don't push" or "match supply with customer demand" and so forth, we can analyze our approach to learning.  Specifically, we can look at how we PI specialists teach Lean to the people in our organizations.

The Challenge...

I've been guilty pretty much my whole career of producing large batches of lean training.  I think just about every PI specialist has designed and or delivered all-day or all-week workshops where we cover a broad range of lean tools and principles.  It's pretty much de rigueur in the healthcare world to send Green Belt candidates off for weeks of training at a time.

This "big-batch learning" approach can be quite effective at building awareness of and excitement for the lean approach in general, but I've seen little evidence in my personal practice of this leading to a change in daily habits.  And just to be clear, my belief is that if daily habits don't change then it's extremely difficult to create a culture of continuous improvement.

But why does the big-batch learning approach not lead to habit-building?  It's the same fundamental principle at-play from the previous manufacturing example:  we're obfuscating the connection between supply & demand by pushing tools and principles via classroom training.  This pushing/overproduction leads to all sorts of learning waste:  defects (not remembering how to perform a certain technique because there was too much lag time from exposure to first real-world use), excessive inventory (tools sitting on our mental shelf that may never be used), over-processing (e.g. using five types of graphs when one would do just fine), and on and on, ad nauseum.

The Idea...

Just as in the previous example, the countermeasure here is to establish a target condition of letting the learner pull* lean tools and principles in the course of their improvement work, in pursuit of a True North of just-in-time learning that perfectly matches the supply of learning with the demands of the situation.

* Actually, it's the gap between the target condition and current condition that is doing the pulling.  The learner may not have the wherewithal to know when or what to pull.  This is where having coaches with plenty of coaching cycles under their belt is critical, as they have the pattern recognition ability needed to be the "voice of the gap" so to speak.

It's interesting to think about why we so frequently resort to big-batch learning instead of the just-in-time approach.  I think a root cause might be that most of the time our PI folks don't have a systematic mechanism for delivering just-in-time learning the way we do for big-batch learning (i.e. classrooms, trainee rosters, syllabi, PowerPoint slides, group exercises, simulations, etc.).  Of course, the Toyota Kata system provides a highly-effective mechanism for just-in-time learning, but there are significant barriers that prevent us from adopting this approach universally.*

*Hint:  it seems to come down to whether senior leadership can accept that the future is unknown and unknowable, and that certainty can only come from building strong, repetitive habits that allow us to cope with whatever change comes our way (Carol Dweck's book can provide more explanation).

3) Big-Batch Root Cause Analysis

aka the "Somewhat-Controversial-But-Profound" example

The same big-batch/small-batch, push/pull, supply/demand concepts from the previous two examples apply to the work of root cause analysis (RCA).  Just to state the obvious, as any PI specialist worth their salt knows, we should always strive to properly define problems and identify root causes prior to implementing countermeasures.  This is another sacred element of the lean canon that requires little explanation to PI specialists.

However, the way we go about performing RCA can vary widely.  We have an array of RCA tools at our disposal in several categories:  statistical (linear regression, ANOVA, etc.), practical (5-Why, Ishikawa diagrams, etc.), or empirical (hypothesis testing via PDSA).  We can use any combination of these tools to identify the root causes of our problem, which gives rise to a significant amount of variation in the way RCA is done in the world.

Some interesting discussion regarding various approaches to RCA has been occurring recently on LinkedIn, including comments from the great Jeff Liker.  Here's the link to the discussion thread (you may need to be a member of the group).

The Challenge...

What this discussion thread and Professor Liker's coaching has forced me to do is think about how the RCA approach we select (the combination of statistical, practical, and empirical techniques we utilize) impacts the batch size of the RCA work.  The challenge for us is to figure out what batch size of RCA work will yield the best results for us.  To examine this question, let's look at two extreme batch sizes:

An excessively big-batch approach to RCA work might look like this:  we get a bunch of folks together for an all-day workshop during which we use the wisdom of the crowd to map the current-state process, identify opportunities for improvement, define the problems in a discrete way, and use a combination of statistical and practical RCA techniques to break those problems down to root causes.  At that point, we're ready to hand off that big batch of work from the Plan phase to the Do phase of PDSA.

This approach has the advantage of being efficient from a facilitation standpoint, but all the disadvantages of big-batch over-production as discussed above (but especially defects in the form of incorrect identification of root causes due to faulty assumptions, group-think, etc.).

An excessively small-batch approach to RCA work might look like this:  after engaging the team to do a small bit of current-state analysis, we identify a few potential root causes.  We then select the one we think is the most likely culprit and start testing countermeasures using mini-cycles of PDSA.  If the countermeasure isn't effective at removing our hypothesized root cause, then we try other countermeasures one-by-one.  If we find that a countermeasure is effective at removing our hypothesized root cause, but has no positive impact on the problem at-hand, then we select other potential root causes one-by-one.  Lather, rinse, repeat.

This approach has all the advantages of one-by-one just-in-time production as discussed above, but the significant disadvantage of being a nearly unmanageable process in the real-world due to the myriad factors that can distort, taint, delay, or otherwise invalidate our supposedly scientific experiments.

This is clearly a complicated challenge with no single answer.

The Idea...

It feels as if we will need to find the sweet-spot between these two approaches to be able to mitigate the risks of big-batch work while coping with imperfections of real-world testing.  I think in the current condition, the majority of PI specialists tend to error on the side of big-batch RCA work as described a few paragraphs ago.  Those of us practicing the Toyota Kata method in a strict way probably error on the other side.  Let's find the sweet spot in the middle and move forward, shall we?


Whether it's our process for producing widgets, teaching Lean, or performing a root cause analysis, we can benefit from understanding how the concepts of pull, just-in-time, one-by-one flow, etc. impact the waste level of our system.  In healthcare, we PI specialists tend to be good at understanding these concepts in the context of the typical clinical process (e.g. a nurse pulling meds from a Pyxis machine, triggering a replenishment from the Pharmacy, etc.), but not so good at applying them to our own work processes.  A true lean thinker is consistent in applying lean concepts to any process.

I shudder to think of how many of my own work processes are poorly aligned with lean principles. Yes, the learning continues.

Tuesday, February 18, 2014

My Top 10 Lessons Learned from Practicing the Toyota Kata Approach

On the day after Jimmy Fallon debuted as host of the Tonight Show, I'll go against the grain and do a Letterman-style Top 10.*  My topic will be the lessons I've learned from my grassroots effort to infuse the Toyota Kata methodology into the culture of an acute care hospital in the Dallas-Ft. Worth metroplex.

*I'm not a huge fan of any of the late-night shows.  I like Kimmel and Conan as comedians, but the format just doesn't do it for me.  I much prefer the format of Jerry Seinfeld's new show, "Comedians In Cars Getting Coffee" (it's as ridiculous as it sounds, and pretty hilarious).  I just wish he had Chris Rock or Don Rickles hanging out in the back-seat for every episode.


When we began testing the Toyota Kata approach we had no experience with or knowledge of it at all, outside of having read the book a few times.  We had no budget to bring in experts or send ourselves off for formal training.  But, thankfully, we did have senior leader support to try something different; they were ready to invest significant effort in building a sustainable culture of continuous improvement at our hospital.

That's how we started.  We didn't know where the path would take us, but we took a step forward anyway.  First, we selected an Advanced Team from different departments and levels of the organization.  Then, we did a tiny bit of home-grown training and quickly got to work practicing the Kata in the real-world.  Now, after about six months of real-world application including several hundred coaching cycles, I have some lessons learned that I'd like to share...

#10:  A PDSA cycle is not what I thought it was.  I always thought a PDSA cycle was when you had identified a countermeasure to a problem and wanted to test it.  Well, yes, that is one type of PDSA cycle, but there's more than one kind.  Sometimes, our PDSA cycle consists of nothing more than a quick "go & see" to confirm or deny a hypothesis, without changing/implementing anything at all.  I've come to see a PDSA cycle as simply the act of taking a step forward with the intent of learning something in the pursuit of improvement.

#9: Cues, routines, & rewards matter.  In The Power of Habit, Charles Duhigg explains that for habits to form, we must have a habit-building loop in place consisting of a cue, routine, and reward.  Since modern organizations have so many built-in impediments to organic continuous improvement (annual performance reviews, TPS reports, etc.), we must actively pursue continuous improvement through organizational habit-building.  The Toyota Kata approach provides all three elements of a habit-building loop in abundance:  1) cues via formal coaching sessions and visual signals such as the 5 Questions pocket card; 2) routines (i.e. the Improvement Kata and Coaching Kata); and 3) rewards via the intrinsic satisfaction of learning, solving problems, attaining Kata mastery, etc.

#8:  Track the metrics of habit-building.  In the early stages of Kata adoption the focus is more on building habits than producing huge process improvements with eye-catching ROI calculations.  Therefore, it's advisable to have a way to measure progress in terms of habit-building.  For example, we can track the # of Kata "practitioners", # of Kata coaches, # of PDSA cycles performed, etc.  I'll admit that this is a highly imperfect set of habit-building metrics, so I'm hoping as a community we can come up with something better.  One option might be to measure what level of mastery our people have attained using a standardized rubric, as suggested in some of Mike Rother's online material.

#7:  Clinicians and other front-line staff tend to like the Kata approach.  I think this is because it allows them the freedom to take one bite of the apple at a time.  They are free to try a small change or just go get more information, all in the pursuit of learning and iteration.  This reduces the fear of failure and the stress of trying to do too much all at once.  It's quite liberating actually.

#6:  It works on big projects too.  We've seen great success in using the four routines of the Improvement Kata as a roadmap for fairly large improvement projects.  This is where the fractal nature of the Kata approach comes into play.  In our model, the first three routines (1. Understand the Direction, 2. Grasp the Current Condition, 3. Establish the Next Target Condition) are performed in a team environment utilizing techniques such as kaizen events and work-out sessions.  While this has the downside of producing large batches of improvement work with fewer opportunities for iteration, it has the upside of allowing us to build cross-departmental consensus quickly.  The fourth routine (PDSA Toward the Target Condition) occurs via multiple "learners" pursuing their portion of the target condition in parallel, with a single coach guiding their work and connecting the dots.  It's not perfect because doing multiple tests simultaneously makes it harder to understand cause & effect, but this approach does have the advantage of allowing us to expedite the change process.

#5:  Target Conditions  Numerical Targets  List of Countermeasures.  This was one of the hardest things for me to grasp as a coach.  I almost immediately understood that a target condition is not the same as setting a numerical target or goal; yes, we actually have to describe the future mode of operation that will produce the results we seek.  This I understood.  What I didn't understand was that describing the future mode of operation does not require us to know exactly how we will achieve it.  In other words, we don't need a specific list of countermeasures to be able to describe the target condition.  In fact, it's better not to lock ourselves into pre-conceived notions of what solutions are needed before we've began testing via PDSA.

#4:  Root cause analysis is an iterative process.  I always thought of root cause analysis as a routine we performed prior to identifying potential countermeasures.  We'd use 5-Why? or whatever to identify a root cause, then come up with countermeasures to address it.  What I learned through the Kata approach is that we don't have to fully understand the root causes of a problem before we can start testing countermeasures.  In fact, the act of testing countermeasures (via PDSA) is in and of itself a fantastic way to identify root causes in an iterative and scientific manner.

#3:  Coaching is tricky.  Even though the Coaching Kata provides clear instructions on what questions to ask (the 5 Questions), novice coaches typically struggle with how to stick to the script without being too robotic and awkward about it.  It's a balancing act.  A coach must be able to sense when the learner is in need of strict structure (new learners often go off in ten directions at once and need to focus on the single next step) and when a more creative, free-flowing discussion is appropriate.

#2:  Coaching is largely about providing a safe environment to fail.  This is because mastering the Kata is mostly a learning by doing approach that relies heavily upon repetition and deliberate practice.  A coach must foster an environment that allows the learner to practice and fail (and trust me, in the early going most of the practice results in failure).  Because 'practice' in this context occurs in the real-world (not in some classroom simulation), these failures must also be done in a safe manner that causes no irreparable harm or embarrassment.

and finally...

#1:  When in doubt, take a step forward!  Fortune favors the bold.

Sunday, February 9, 2014

The Waffle House of Cards

Have you been to a Waffle House?  For any of my Southern brethren, I already know the answer is an emphatic "heck yeah!"  For those of you that haven't, go ahead and grab $10 and get there right away.  It doesn't matter if it's 2am Saturday night and you're leaving the bar, or noon on Sunday and leaving church; the Waffle House will treat you right.  And ignore those hateful monikers i.e. the "Awful House" or the "Poor Man's IHOP."  What does Vince Vaughn have to say about that?

Okay, I promise this isn't some ridiculous paean to the Waffle House.  No, it's not about how they produce tasty food, incredibly fast, at dirt cheap prices (they do).  No, I won't be celebrating how these dingy, cramped, greasy joints with skeleton staffs have somehow managed to satisfy the masses for decades (they have).  Don't believe me?  Well, any company that can claim to have served 1.8 BILLION hashbrown orders is doing something right.  For real.

But alas, that's not what this post is about.  In fact, I'm going to recount an imperfect experience I recently had at the Waffle House.  This overdone and excessive analysis is being done in an attempt to draw parallels with my own work experience and to learn from the analogy.  Let this trivial pursuit commence.

My Waffle House Experience...

So, I recently went there for a late Saturday morning breakfast with my wife.  It happened to be really busy when we arrived and there was a wait for a table, but we were in no big hurry so we decided to wait.  We actually got a table after only a few minutes, but we could tell the restaurant was super busy and our waitress, Tish, seemed to be the busiest waitress of all.  Several fairly large groups had been sat in her section at the same time, along with my wife and me, so she was slammed.  Again, we were in no big hurry so even though we waited several minutes without even being acknowledged by Tish, we never felt the need to do the whole "excuse me, miss, can I get a coffee" thing.

But then an interesting thing happened.  A different waitress, Sandy, saw that Tish was slammed and came over and asked if she could get us something while we waited.  My wife ordered a coffee.  While she was ordering it, my wife had been inadvertently pointing to the meal she wanted to order on the menu.  The waitress saw this and asked my wife if that's what she wanted to eat.  My wife said yes, even though she had not intended to place her food order yet.  I was observing, thinking that we should order only coffee from Sandy and wait for our waitress to take our full order.  But I went along with it and ordered my meal as well.  Then I sat back and waited to see if my hypothesis would prove to be valid.


Yes, I made a prediction.  You see, these types of scenarios pop up everyday at work.  In a hospital, just like any other workplace, we are always dealing with issues:  errors, delays, miscommunication, dissatisfied customers, etc.  If somebody spots the issue, they'll usually respond.  On a process improvement project, for example, a team member may get the impression that the project is is not making progress, and in response she might lobby the project's executive champion to intervene.  This act may be totally well-intentioned, yet still cause unintended consequences.

For example, the project facilitator might be intentionally reigning in/throttling progress during the early stages when we're analyzing the current-state, so as to prevent jumping to the wrong solutions (a tendency with clinicians).  If somebody like an executive champion intervenes without understanding this rationale it can cause us to proceed too quickly, select the wrong solutions, and end up having to go back to the drawing board.  This sort of thing happens all the time, but an experienced facilitator can see it coming from a mile away and preempt the situation through good communication, consensus-building, etc.

Back to the Waffle House Story...

Similarly, at the Waffle House, I could see an an unintended consequence coming from a mile away.  When we proceeded with ordering our whole meal with Sandy instead of waiting for our waitress, I predicted that we'd wait forever to get our coffees.  That was my hypothesis anyway.

My hypothesis was valid.  Sandy, who initially was just going to grab our coffees real quick, ended up handing our full order off to our waitress and completely forgot about our beverages.  Then, after the order hand-off, our waitress had to go back to Sandy twice to get missing information about our order.  Next, our waitress immediately placed our order with the cook, but she never thought to bring us our coffee.  So, yep, we did wait forever to get our coffees.


So, let's analyze some of the behaviors we saw.  First, the positive behaviors:
  1. Sandy wanted to help us (good customer focus)
  2. Sandy wanted to help our waitress (good team-oriented culture)
  3. There was a quick hand-off of the order from Sandy to our waitress (good sense of urgency)
  4. Our waitress quickly placed our order (good sense of urgency)
All those are great behaviors that we'd want in any organization.  But there were several other behaviors that had unintended consequences:
  1. Sandy, thinking she was just taking our beverage order, was just scribbling it on a napkin instead of using the standardized order template they normally use.  This resulted in errors/missing information that Tish had to go get from Sandy later.
  2. Sandy, after handing-off our order to Tish, forgot to get our coffees which was the whole reason she approached us in the first place.  This put our coffee order in limbo, with no clear owner.
  3. Tish didn't get our coffees either as she was focused on placing our food order, probably thinking we were starving because of the fact that we had hurriedly placed our order with the nearest waitress, Sandy.
As you can see, the intentions were all good but the outcomes were not.  This was predictable to me, just because of how many times I've made these mistakes on projects at work.  It all boils down to the fact that the Waffle House system of food delivery, while incredibly effective and efficient normally, is actually a house of cards (pun intended).  The whole model is predicated upon these waitresses performing the same routines over and over again.  When we "intervened" and allowed Sandy to take our full food order, these routines were circumvented and predictable unintended consequences resulted.

Back to the Waffle House Story once again...

So, our coffee order was in limbo and we waited and waited.  Eventually, we asked a third employee if he could bring us coffee, which he did promptly.  But right around the time he was delivering our coffee, Tish also brought us coffee.  So, we went from no coffee for 15 minutes to a total of 4 full cups of coffee at our table in a matter of a minute or so.

You see, Tish had been taken out of her normal routine.  She normally would have been aware of our coffee situation and responded accordingly, but because she had not even spoken to us yet she was acting on second-hand, outdated information.  This resulted in duplication of effort...and cold coffee.

This sort of thing also happens quite often at work.  We see a problem pop up on our project and want to resolve it as soon as possible, often unaware that somebody else is also working on a resolution.  Predictably, this results in duplication of effort...and probably cold coffee somehow.


So what can we do to prevent all this waste?  At the Waffle House and at work, we want people's positive behaviors (customer focus, teamwork, urgency, etc.) to result in positive outcomes.  When they don't, we need to address the system.  Here are some potential approaches to addressing the system:
  1. We can blame each other and tell the employees to do better.  This is obviuosly a really bad option, but unfortunately this continues to be the one most commonly selected.  STOP DOING THIS!
  2. We can work on the root causes of the issues.  In the case of the Waffle House, we would probably want to tackle the workload imbalance and inefficient processes causing our waitress to be so busy that Sandy needed to intervene.  Addressing root causes is always a great option, but this approach can take time and process improvement skill, which are not always abundant in organizations (more on this later).
  3. We can facilitate the process.  By this, I mean having somebody in-place whose role is to coordinate between the involved parties to prevent the unintended consequences.  In healthcare, for example, we have patient navigators, patient advocates, care coordinators, project managers, etc. whose primary function is to prevent issues from arising due to poor coordination.  In the case of the Waffle House, I could have prevented the predictable sequence of events from occurring by not allowing Sandy to take our full order, but that would have put me in the position of facilitator when I should be in the position of paying customer.  Paying customers shouldn't have to facilitate.  But with the way the Waffle House is staffed, having somebody assigned to this role is not feasible.  That makes option #3 impractical for their business model.
So, what to do?  For a system like the Waffle House that is essentially a house of cards relying heavily on repeatable, consistent routines to maintain order, it's absolutely critical that anything that takes waitresses out of their normal routines be eliminated.  This requires getting to the root causes of the issues, so option #2 is the right approach.  This is also the right approach for healthcare, even though we may sometimes have the resources to pursue option #3 as well.  But option #3 is a band-aid, not a cure.  Option #2 is the sustainable strategy.

Executing the Right Countermeasure...

So, how do we go about pursuing option #2?  Well, there's no one-size-fits-all approach to driving continuous improvement, and it can take a lot of patience and skill to execute.  Most organizations have severe shortages of patience and skill, so it's critical that we tackle both deficiencies in the most effective and efficient way possible.  We have to be better at making things better.  Here are some strategies to do that (again, there is no one-size-fits-all approach):
  1. Don't delegate process improvement work to PI specialists.  Operational managers should lead improvement efforts.  This is the only way they will get better at it.
  2. But, make sure operational managers are properly supported and coached as they lead improvement efforts.  Owning a process improvement project can be challenging and even intimidating for newcomers.  They need to be guided so they can mess up without sinking the project.
  3. Utilize PI specialists prudently to occasionally lead complex improvement efforts.  These projects can be great opportunities to demonstrate these advanced techniques to operational managers, but we don't want the specialists to become a crutch.
  4. Bend the learning curve.  Give your people a straightforward technique, such as the Plan-Do-Study-Act (PDSA) cycle and let them get started on improvement work quickly.  Batching up a bunch of improvement tools into a complex technique such as DMAIC and delivering via months of formal training delays the "learning by doing" that results in the most profound insights and behavioral changes.
  5. Treat the building of improvement capacity in your organization as a PI project in and of itself.  Measure the # of improvement practitioners, # of coaches, # of PDSA cycles, etc.  Not just to feel warm & fuzzy and report some nebulous employee engagement success to the Board, but to actually test your hypothesis of what will increase the improvement bandwidth of your organization.  It's also a great way for senior leaders to practice what they preach.
That last recommendation is critical, because the previous four may or may not work in your organization.  We have to test our hypotheses.  If you do so and stick to it, you will increase the improvement capacity of your organization, will allow you to begin addressing the root causes of problems so that you don't have to rely on band-aids (navigators, coordinators, customer service advocates, etc.).

One Last Word on the Waffle House Story...

I opened with praise for the Waffle House, and I stick by my story.  They do a great job with what they have to work with the majority of the time.  They can get better too....if they address root causes of waitress workload imbalance, inefficient processes, etc.  Ideally, the waitresses would themselves have the ability to use PDSA to test new routines, always looking to get better.

Sound unlikely that a Waffle House waitress would ever get involved like that?  Well, they used to say the same about nurses, physicians, Kentucky auto workers, Latin-American laborers, and just about anybody else that wasn't Japanese.  But we've shown over and over again that just about everybody is capable of being engaged in meaningful improvement work.  It just takes resolve and endurance.  Oh, and coffee.  Lots of coffee!