Thoughts and Insights from the Shop Floor
A great insight from a client today.
The target condition at this point is simply to establish some degree of transparency of the current condition on a status board without having to resort to probing questions to elicit what is working, and what is not.
The observation was:
“We’ll know we are succeeding when we see a failure.”
In other words, “no problem is a big problem” but I think this says it just as well.
I was driving home today and saw a construction sign on the sidewalk. It read: “Sidewalk Closed, Use Other Side.” Ahead was a section of the sidewalk which was, indeed, closed off and impassible.
By the time a pedestrian encounters this sign, he is well into the middle of a long block.
The sign is at least implying that the pedestrian should cross the street in the middle of the block to get around the construction. The alternatives are:
This situation is actually fairly common in a lot of companies. There is a rule “Don’t cross the street in the middle of the block.” Then there is an expectation that is incompatible with following the rule.
The team member has the same alternatives as above – ignore the expectation, or ignore the rule.
This is a slightly higher level than Hirano’s observation that “the words ‘just for now’ are the origin of all waste.” Here we are putting the team member in an untenable situation because there is no action available that is clearly OK.
Take a look at the rules you have. Take a look at the actual behaviors. Remember that what people actually do is generally what they sincerely believe you expect of them.
If it is impossible to follow a rule, consider why the rule exists.
The words “Do the best you can.” are a warning that you are in this kind of situation.
This video by Charles Duhigg is promoting his book The Power of Habit
A habit is based on an urge to do something that triggers a reward (dopamine shot) in your brain. Every time it happens, the connection between the action and the reward gets stronger.
The urge itself is usually triggered by some outside condition or stimulus.
Take a look at the video, and then the flowchart beneath it (click on the flowchart for the full size version), then we will discuss what this has to do with lean thinking.
Here is the flowchart – click for the full size version:
Why this is important to lean practitioners:
When we talk about “change” we are talking about replacing one set of habitual responses with a different set of responses. Thus, it is important to understand that simply applying willpower is not enough for anyone (no matter how well intentioned) to change their fundamental behaviors.
As you may recall, I am a big fan of the book Switch by Chip and Dan Heath. One of their key points is “Build Habits” and they discuss linking the desired response to a specific trigger.
What we have to keep in mind is that the old responses also have triggers, and many of those triggers are subtle and below the level of awareness.
Duhigg’s model is replacing one habit that does not get the results you want with a different habit that does get the results you want.
The less dramatic this change, the better. That is why it is critical to “find the bright spots” (also from Switch), and even if they are not working perfectly, to structure your future state behaviors around them. For that matter, if you can find even a hint of the behavior you want, it is far easier to shape existing actions than to try to tell people they are “doing it wrong” and getting them to pick up something else.
One of the elements of Deming’s model of “profound knowledge” is “knowledge of psychology.” Take a look at these tools and see if they help you be a more effective change agent.
Coincidently my experience this week ties in nicely to the last post.
I have a couple of teams working to develop pull systems through their respective work areas.
The conventional approach (I suppose) is a lot of PowerPoint about kanban, some exercises, developing a future state value stream map, then devising an implementation plan.
An alternative approach is to have a small group of experts design the system.
Most of the time this results in a fairly arduous process of wringing out the issues once the system goes live. If the team isn’t prepared for that, it is likely the system will come apart as people bypass it out of necessity to get the work done.
What I am watching this week is more organic.
First, we covered a few fundamentals about flow and pull signals in a simple demonstration of “build and push” vs. one-piece-flow with a visual limiter on work-in-process inventory. They saw the throughput, productivity, stability, visibility all increase while lead time dropped by an order of magnitude. That took about an hour.
The team then set up a tabletop simulation of their existing work flow, and exercised it a few times to confirm that it is a fair representation of the way things actually work today. In doing so, they gain more understanding of the current condition because they have to replicate it.
They then set out to make their far more complex real-world situation work more like what they saw in the demonstration. To help them get started, they were given some suggestions about a few things to try, and some basic principles and rules.
Some of that advice included restricting changes to a single factor at a time, and predicting what would happen, then trying it. If you find yourself speculating, or discussing alternative speculations, try it and see.
Two days into it, the teams have full-blown multi-loop kanban working, and are devising experiments to learn how the system responds to things like machines going down, unpredicted shifts in product mix, and other things they normally need to respond to.
They are exploring not only the mechanics and the rules, but the dynamics of the process in operation. They are learning what “normal” looks like in the face of abnormal conditions. They are testing the boundaries – where and when does it break, and what does “broken” look like vs. something that will recover on its own.
They are figuring out how to make it more robust, without making it cumbersome or too complicated.
They are gaining confidence and a deep understanding by iterating through ever more complex scenarios.
The people doing this are the ones who will be working IN the system in the future. We are seeing who emerges as thought leaders.
What they have right now – mid week – is a crystal clear view of their target condition, and they are very confident that they can make it work in their real world. Are there unknown issues? Sure. There always are. Translating this to the real world will involve more cycles of iteration. Only now they know exactly how to do those iterations because they have practiced dozens of times already.
This is actually less about kanban than it is about learning how to gain knowledge about something previously unknown.
It is pretty cool to watch, and a lot more fun (for everyone) than just implementing a process designed by someone else. Even the skeptics get drawn in when people are working hands-on to try to make something work.
Oh – and I’m really glad this process works because that saves me from having to know the answers.
PC once again left a provocative post in the Lean Thinker’s Community, and gave us a link to this Tim Harford TED talk that drives home the point that learning and improvement is more about rapidly discovering things that don’t work than about designing things that do.
Tom Wujec makes the same point in the Marshmallow Challenge. In that video, Tom talks about how 5 year old kids out perform most adult groups in a problem solving / learning game. While the adults engage in a single cycle of “know-build-fail” the kids engage in multiple cycles of “try-fail-learn-try again.” In the improvement world, we call this process PDCA.
Harford’s key point is that learning only happens through a process of trial of large numbers of ideas, followed by the selection and further trials on the best ones.
Hmmm… that sounds a lot like the 3P process of “Seven Ideas” as well as “Set Based Design.”