Archive for April, 2012

Tiered Meeting = Team Stand-up A3

For some time, I have searched for a metaphor to convey the meaning and delivery of a tiered meeting (a.k.a. huddle, reflection meeting, sunrise meeting, etc.).

I think that I’ve settled upon a decent (sort of) metaphor – “team stand-up A3.”

The simple explanation is that tiered meetings, a critical element of an effective lean management system, are: 1) team-based, 2) conducted in the standing position (to discourage long-winded discourse), and 3) is largely about practicing PDCA (A3 thinking).

The team stand-up A3’s agenda approximates the following. The underlined words represent traditional A3 section titles.

  • Team leader shares the meeting theme (what the team is about to talk about) and provides some background (why they’re talking about it)
  • Team leader facilitates team exploration of the current conditions and target conditions (as represented by the performance metrics on the team’s board, leader standard work insight, etc.) and identification and acknowledgement of the problem(s) (the gap between current and target)
  • Team leader facilitates team problem analysis to identify root causes
  • Team converges on countermeasures (who, what, when) or a plan to do/continue problem-solving at another time after the meeting
  • Team leader facilitates follow-up on prior action items
  • Team leader facilitates “round robin” to seek out any open issues, suggestion, and/or questions
  • Team leader verifies take-aways and closes the meeting

Related posts: How to Audit a Lean Management System, Animated Cartoon: “What’s the Problem?”, 6 Leadership Habits for Effective Tiered Meetings

Tags: ,

Simplistic Ain’t Lean

Leonardo da Vinci’s quote, “Simplicity is the ultimate sophistication,” could easily serve as a lean tagline.

Surely, lean tools, like standard work, visual controls, and mistake proofing devices, are only truly effective if they are easily explained, understood, deployed, maintained, and adjusted. Heck, lean principles are simple too, just hard to implement.

This whole simplicity stuff is consistent with the Shigeo Shingo-identified first objective of continuous improvement – easier (followed immediately by better, faster, and cheaper).

But, some folks in their rush to keep things simple, careen into “simplism.”

Simplism, defined by thefreedictionary.com, is, “[t]he tendency to oversimplify an issue or a problem by ignoring complexities or complications.”

I think a lot of simplism is driven by a type of unthinking lean just-do-it machismo, detachment from the gemba, and/or ignorance of lean principles, systems, and tools.

Simplism begets simplistic directives. Like, within the next quarter, team leaders need to facilitate problem-solving like their counterparts at Toyota.

Except, there just might be some “complications” that need to be addressed first, such as the fact that Toyota team leader span of controls is in the 5-8 associate range, and our team leaders have 15 to 20 associates… not to mention the profound training and mentorship that is required to develop effective team leaders.

Simplism begets simplistic countermeasures.

Countermeasures must address root causes – real root causes. And, the countermeasures must work in the real world.

For example, when a given process is irreducibly complex (for now), the standard work might have to be more than 1 page.

The simplistic practitioner (and I have encountered such folks) might maintain that standard work can’t be more than a page. “It’s too hard for my (well-educated) folks to absorb…”

Simplism shouldn’t be allowed to trump lean principles.

If the one page standard work is insufficient, then the steps, sequence, cycle times, standard WIP, etc. may not be appropriately defined. What then? Is it OK for the operators to improvise?

Ignoring complexity and complications. It’s just magical, non-lean thinking.

Lean leaders can’t be simplistic.

Related posts: Guest Post: “Magical Thinking”, Working Smarter, or Just Harder? Thoughts on Standard Work., Kaizen Principle: Bias for Action

Tags:

Tattoos, Lean, and Regrets

A friend and colleague provided me with this tattoo parlor photo. He was passing by and just couldn’t resist the irony of it all.

The lack of permanence around the sign construction makes the whole thing even more entertaining.

My friend and I share the same passion for lean as well as an often bizarre brand of humor. He thought the photo was blog worthy, although he wasn’t quite sure of the exact subject.

Well, I’m not one to waste a good picture.

______________________________________

Lean, by it’s very nature, is not permanent. Certainly, if a transformation is not progressing, then it’s not transforming.

If it’s stagnant, it is decaying.

But, I digress.

I’m no expert on tattoos. In fact, I don’t have any.  Although, there were several “near misses” in my younger days.

Other than the stick on variety or henna types, there is very little PDCA around them. Sure there is “plan”, which sometimes doesn’t get the proper rigor before it quickly turns into “do.” Note that tattoo plan and do is best done without the assistance of alcohol and peer pressure.

The “check” part, other than the review of the stencil before the needle, seems to happen largely after the artwork is complete. By then, “act” or “adjust” options are pretty limited.

Lean is a lot more forgiving. Real PDCA, especially within the proper culture, is freeing. Renewable in may ways.

But, as I think through my modest career thus far, I have to ask myself whether I have any lean regrets.

Unlike in the song My Way, my regrets are not too few to mention. So, here are some of my own, along with regrets that I think others should have (based upon my observations over the years).

  • Bending or compromising on one or more lean principles
  • Being too rigid on a lean tool and missing the point (a.k.a. the principle)
  • Not using open-ended questions enough
  • Making technical changes without corresponding management system changes (i.e., leader standard work)…and seeing improvement gains evaporate over time
  • Getting into useless arguments about whether folks need to adhere to standard work. Sure we need to understand the why, but following standard work is a condition of employment. End of story. Improve it if the standard work is not sufficient.
  • Assuming (a.k.a. not validating) that folks understand key lean concepts
  • Not aligning leadership at the very beginning of the lean transformation
  • Not acting quickly enough to remove the saboteurs (after a genuine effort to convert them)
  • Forgetting that people development is as important as business results
  • Giving someone a fish because it’s more expedient than teaching them how to fish
  • Basing leadership assignments more on technical skills than core competencies/behavioral skills
  • Not fixing (or at least containing) problems immediately
  • Prematurely moving from pilot to full scale deployment
  • Ruminating about stuff while sitting in a conference room rather than going to the gemba and personally conducting direct observations
  • Short-cutting problem-solving

The list could go on and on and on.

Of course, unlike in a tattoo scenario, we can reflect and adjust. We can turn our regrets, assuming that we can grasp the root cause(s) and apply effective countermeasures, into strengths.

And, in a form of yokoten, we can share our hard-earned learnings, so that others may better avoid some of our mistakes.

What “lean regrets” do you have?

Related posts: Want a Kaizen Culture? Take Your Vitamin C!, Lean Listening, 12 Narrow Lean Gates

Tags: ,

Reading Backwards – Proofreading Causal Relationships

Problem-solving tools are powerful things.

But, not so powerful that they are immune to human error. Few things are.

Analogously, this is one reason why our school teachers strongly encouraged proofreading (clearly, something that I do not do too effectively at Gemba Tales).

You know, critically reading what you just wrote to ensure that it is clear, well-organized, flows logically, without misspelled words…so that no one thinks you’re a total idiot.

Well, the same type of proofreading reasoning applies to problem-solving.

Two tools come to mind. One is 5 Whys and the other cause-effect diagrams (a.k.a. fishbone diagrams or Ishikawa diagrams).

5 Whys

Many folks are familiar with Taiichi Ohno’s “famous” 5 why example. It can be found on page 17 of his classic book, Toyota Production System: Beyond Large-Scale Production, published by Productivity Press.

In response to a downed machine –

  1. Q: Why did the machine stop? A: There was an overload and the fuse blew.
  2. Q: Why was there an overload? A: The bearing was not sufficiently lubricated.
  3. Q: Why was it not lubricated sufficiently? A: The lubrication pump was not pumping sufficiently?
  4. Q: Why was it not pumping sufficiently? A: The shaft was worn and rattling.
  5. Q: Why was the shaft worn out? A: There was no strainer attached and metal scrap got in.

[I must admit, to me it seems like Mr. Ohno’s example should have reflected 6 whys. The fifth answer would have been metal scraps wore the shaft down. The sixth why would have queried why metals scraps ended up contacting the shaft, with an answer pointing to the missing strainer.  But, who am I?]

So, how can you check the 5 Why analysis for soundness?

Read it backwards, with the word “therefore” or “so” between each response. For example (and pardon the run-on sentence), the strainer was missing, therefore metal scraps contacted the shaft, therefore, the shaft wore out, therefore, the pump did not pump sufficiently, therefore…you get the point.

This simple practice will help the problem-solvers identify if they are perhaps missing something and/or if their “train” of causal relationships does not make sense somewhere. The practitioner needs to sufficiently understand the root cause(s) in order to identify effective countermeasures.

Consider it 5 Why proofreading.

Fishbone Diagrams

Fishbone diagrams require a logic check as well. The diagram is an effective means of organizing and displaying theories of potential root causes.

Often the diagram has a number of primary, secondary and tertiary “bones” leading into the “head.” The bones represent (potential) causes and the head represents the effect.

Because the diagram can have a lot visually going on, it makes sense to proofread it – not just at the end of the diagramming, but as it is being constructed as well. This will reinforce the cause and effect discipline of the folks creating the fishbone.

One effective way to proof is to read the diagram from most minor bone(s) to more major bone(s), all the way to the head – for each causal “thread.” Just like the 5 why example above, you can throw the word “therefore” or “so” in between to make sure that it makes sense.

An example, the driver was inattentive, therefore he was tired, therefore, he had the accident. Oops, looks like the most minor bone (secondary bone) and the major bone (primary) are reversed.

(Yes, inattentiveness is probably a major bone, with fatigue, texting, and eating as discrete secondary causes.)

Fishbone diagrams “tell” a story of potential causes. Reading them aloud helps people to hear the story and then see it among the many bones (sometimes a challenge for the newly indoctrinated) and is an excellent way to make sure the causal relationships make sense.

So, while I didn’t quite appreciate my 5th grade English teacher, Ms. Cahill’s request to more rigorously  proofread my own work, I can appreciate it within a lean context. I hope that you do as well.

Related posts: Show Your Work, Animated Cartoon: “What’s the Problem?”, When You Want to Ask Why 5X, Just Because You’re Curious…

Tags: